Re: Violation??: MySQL JDBC driver - GPL license not adhered to.
On Tue, 7 May 2002, Daniel Rall wrote: Heya Dirk. The MM.MySQL driver was recently LGPL'd by the author, Mark Matthews. If the documentation which comes with it still states that it is GPL'd, that documentation is out of date -- contacting Mark ought to resolve the issue (and yes I tried to make the case for a BSD/Apache license ;). That reopens the old 'what licences are allowed' - I keep asking this every few months ( last time when we discussed the Sun licenced code that we include ). At this moment it seems there are some agreements with various parties (Sun in particular ) that nobody knows about, subscribing to 'licensing' list is closed for non-ASF members, and the PMC is supposed to enforce something without knowing what ( but at least I hope some PMC members have access to this information - I don't ). My opinion is that until ASF publishes an official list of licences/software products it has agreements that allow distribution and eventually redistribution - we can't include anything but ASF software. I like LGPL - but is it compatible with APL ? That's what ASF must decide, since ASF will go to court if FSF disagrees. This is unfortunately difficult given that most jakarta projects depend already on non-ASF software. While Sun agreed to allow open source implementation of some specs sometimes in the future - JMX is still not legal, and we'll soon have a release of tomcat with important features based on jmx. ( and probably with mx4j included - even if it is still unclear if this is legal or not ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: License issue (the come back)
On Thu, 14 Mar 2002, Peter Donald wrote: They still include the jaxp source code, in xml-commons. But it's a clean-room implementation, made directly from the spec. The directly from the spec is where the problem lies. It uses suns IP and thus must the TCK. We don't and thus we are in violation of the license and thus Apache and every user is open to being sued if sun chooses to do so. This is getting intersting... To be honest, I allways believed that Jaxp, and all are 'open standards'. ( i.e. they allow clean room implementation ) Again, we need a lawyer here - but if this is the case I think we should do something. There are plenty of open standards ( too many even :-), and if a spec is not open, it shouldn't be used - but an alternative ( or a new open standard ). I hear many java APIs are cloned to .net, and that a lot of .net is 'open standard' - I'm pretty sure it has a lot of APIs that could do the same thing as the non-open ones, and we can clone them in java. An open API/standard should be used whenever possible. nope - if you use the IP then it needs to pass TCK - to do otherwise is not legal. Unless we have another license agreement concerning jaxp with Sun that is unpublished (as alluded to before) then we are not legal. It may be thrown out in court but it is still expensive to fight it. That's why we need the list of software/licenses that we can use and redistribute, and what's not on the list shouldn't be used. Especially software that implements non-open standards. We also use a clean room implementation of JMX in tomcat, same thing probably applies there. JMX has always been under a different license and I didn't think you had a clean room impl you just had some MBeans. We use openjmx ( now called mx4j ), that's a clean-room impl of the spec ( AFAIK ) AFAIK ( and again don't take my word for it, call your lawyer :-), clean room implementations based on a published spec are perfectly legal. Probably the name/logo is protected, but saying that your code implements/is based on jaxp/jmx/etc ( but is not 'certified' or 'compatible' ) should be ok. Wrong - at least as I understand the licensing issue. To implement the spec(s) in many cases you must pass the TCK. It can cost a fair chunk of $ to run against the TCK which pretty much excludes all opensource projects from ever legally implementing different specs (ie the XML ones we do at apache). Ok, I didn't know that - and I bet many other people are in the same situation. If anyone can confirm this with a professional, then I think it should be displayed pretty clearly on a visible page, and we should find alternative open standards to use. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: License issue (the come back)
The BCL states that you cannot make a distribution of the .jar file outside of your product. In other words, if you want to distribute the single .jar file, you can't do that. (i) distribute the Software complete and unmodified and only bundled as part of your Programs What about a dummy program - say Linux java installer - with minimal code ? If this is not acceptable, you can probably just redistribute ant or tomcat4, which make use of almost all those packages. Ant is the best vehicle, and very usefull to have it installed anyway. BTW, the clause 'complete and unmodified' is very interesting - does it refers to the jar or the whole binary package ( most people refer to the whole downloaded package as 'software', and the jar is a piece of it ). If so, tomcat and most other packages that include it are breaking the licences, since they repackage and include only the jar. 'Software' is previously defined as 'accompanying software and documentation and any error corrections provided by Sun (collectively Software) Even more fun is the restriction on creating 'java., javax., or sun.' packages. Does it mean that you're not allowed to include open source ( and clean room ) implementations of javax. pacakges if you include one of those licences ? The only possible conclusion is that software shouldn't be redistributed without a lawyer checking and aproving every included license, and we need a list of licenses that are acceptable for inclusion on packages we distribute ( from jakarta, xml, etc ), verified by a lawyer. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: The Complete Server Platform?
On 23 Feb 2002, Pete Chown wrote: The other thing I would like to push is gcj. It doesn't seem to be very well known. For people who haven't come across it, it is part of gcc and it is an ahead-of-time compiler for Java. It also includes a bytecode interpreter so it can deal with dynamically generated code, and a free implementation of the Java class libraries. And many jakarta projects compile and work fine ( and fast ) using gcj. I've got similar results with IBM's JDK1.3 for linux, which is one of the fastest ( when testing tomcat ), except the startup time which is much better. In addition there is an ant task to compile java to native using gcj ( it's part of j-t-c build process, the jkant package ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
'write-only' subscriptions ?
Does anyone knows how to subscribe to a mailing list to 'write-only' mode ( and if it is possible ) ? Some lists have web-based archives, and the trafic is quite big ( too big for a yahoo account anyway ). However posting is not possible if you are not subscribed. Thanks, Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 'write-only' subscriptions ?
Thanks Sam, If this mail will reach general@ without going to moderator, then the trick worked :-) If anyone else is interested: I sent a mail to: [EMAIL PROTECTED] Costin On Wed, 10 Oct 2001, Sam Ruby wrote: Costin Manolache wrote: Does anyone knows how to subscribe to a mailing list to 'write-only' mode ( and if it is possible ) ? See http://www.ezmlm.org/ezman-0.32/ezman1.html#ss1.3 Search for Posting from an alternative address when post are allowed only to subscribers.. This is also something that the people at [EMAIL PROTECTED] can help with. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BCEL @ apache
On Mon, 1 Oct 2001, Sam Ruby wrote: Updates: 1) xsltc and velocity appear to be compatible with the latest BCEL. 2) BCEL's build.xml has minor errors - I'll post details to BCEL's mailing list. 3) BCEL includes and depends on gnu regexp. The dependency does not appear to be deep. It isn't, I was able to make it work without gnu regexp. I am very interested in BCEL ( to generate bytecode directly for 'pure' jsp pages ), it would be great to have it hosted on jakarta. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Vacation - Sam Ruby
On Fri, 11 May 2001, Sam Ruby wrote: It would be nice if the tomcat3 and ant communities could look into getting tomcat to be buildable again using a dist build of ant from cvs. And if tomcat3 build works fine - Gump reports a failure that was fixed 2 weeks ago. ( the report is on a line that is commented out in build.xml ). If anyone can do a cvs update - I'm sure the failure will go away. Costin the taglibs community can figure out why the build fails complaining that I didn't specify servletapi.jar, when as near as I can tell, I *DID*. And if the xalan smoketest could be made to pass again. And if turbine could actually produce something that jetspeed would be willing to step up to... ;-) But most of all, it would be nice if [EMAIL PROTECTED] could look into what is causing CVS to be abysmally slow these past few weeks. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binaries in CVS
On Thu, 12 Apr 2001, Sam Ruby wrote: Costin Manolache wrote: One compromise may be to use a separate CVS only for binaries, with the latest "released" version of each product. This is not a solution for all versioning or cvs/binaries problems. Xerces, Xalan, Ant are used and checked in almost all projects. If a project depends on an un-released version of ant - that's fine, it can check it in as before ( but at least this will raise the "awarness" about dependencies on specific versions ). For some projects that are tightly coupled to unreleased versions - this is clearly not a solution. IMHO this should cover XX% of the jar problems with minimal pain. ( and if we agree it's a good idea - maybe it doesn't even have to be a CVS - maybe a jakarta-stable-binaries.tar.gz that you have to download and get the latest ant/xalan/stableFoo will be enough ). Costin - all projects will be forced to use the latest stable release ( but this can be a big benefit ! ) That's actually a serious concern. There are projects like Turbine and Avalon that are in a continual state of flux. At least now the Avalon consumers are now marching in lock step, but in general one can not mix and match just yet. That's the real problem that we need to solve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] The Commons - web connector
On Wed, 14 Mar 2001, GOMEZ Henri wrote: Still no response for this sub-project proposal. A big +1 This will also reduce the pressure on making changes in the "stable" code. If a bug is found in the connector - we can just make a new release of the connector ( both sides ), without a need to make a dot.dot release of tomcat. ( tomcat 3.3 should still include the current mod_jk, with some of the fixes that are "safe" and/or proven in the new potential module ) BTW, if the "commons" project is aproved, than this can be a part of the "sandbox"/"agora" - and it doesn't require any special aproval from PMC or other projects ( only a vote on tomcat-dev). I saw at least 4 potentials commiters working on it : - Dan Milstein, our resident hacker/expert of mod_jk. - Keith Wannamaker, webdav specialist - Pier P. Fumagalli, mod_jserv and mod_webapp father - I, Henri Gomez, mod_jk and adaptation to Apache 2.0 I can help with some performance and a bit in the C side. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] The Commons - web connector
On Fri, 9 Mar 2001, Nael Mohammad wrote: I for one would like to see mod_webapp Same for me - the automatic configuration is great for most users. Having this "common" project would be great because it'll allow the development of a connector that combines the best features of mod_jk and mod_webapp. Of course, this depends on having the "commons" aproved and started in a reasonable time, and on aproval from tomcat-dev people to share the connector, and of course on interest from Pier ( who is the main author of mod_webapp ) and Dan and the other people who maintain mod_jk. BTW, the protocol could be used for other projects that need to connect to apache ( and in many ways it belongs more to httpd then tomcat ). ( I would guess mod_perl and mod_php could also benefit from the load balancing features ) Costin -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Friday, March 09, 2001 4:11 PM To: [EMAIL PROTECTED] Subject: [PROPOSAL] The Commons - web connector Hi to all, What about a new sub-project, web connector, where all the developpement on mod_jserv and mod_jk (and why not mod_webapp) could live. Apache 1.3 and 2.0 are allready supported by mod_jk but also IIS, AOL, and NES (iPlanet) even JNI. Tomcat's 3.x and 4.x provide interfaces (modules, interceptor or whatever) that these connectors will implement :) A project which could be in The Commons even if there is still C code inside but also many java part (TC mod/interceptor). We could (must) see Tomcat 4.x use mod_jk or Tomcat 3.x use mod_webapp from Apache 2.0... Comments ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
Say I'd propose to move the org.apache.tools.tar and
org.apache.tools.mail packages from Ant to the commons repository -
which I'll probably do - these are very small thingies that don't
really need separate mailing lists at all.
+1 !!
And maybe parts of ProjectHelper ( turned into a introspection. package ),
and the ${var} stuff. It's great code, very useful.
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nominations for the Jakata PMC
Remy Maucherat wrote: I'm a bit disappointed by that list, which doesn't include Costin. Before questioning the people that came up with this list, perhaps first you should ask Costin if this is an opportunity he would be interested in. And my answer would be no, I am not. But I am also disappointed with the way this list was created, and that gives me one more reason not to be on the list or the PMC ! ( I think most of the proposed names are great, but that doesn't mean the process is right ! ). IMHO, the best election process would be to let the committers submit a ballot containing the list of committers they want to have in the PMC. Then, just choose the 10 - 15 committers who got the most votes. That suggestion has some merit. However, I am concerned that the resulting list would end up with a number of people interested in some of the larger subprojects and not many people interested in some of the smaller ones. Getting coverage over the entire code base was the primary motivation for this round of elections. And again, I agree with you. Tomcat is a reasonable stable and mature project, with enough commiters - I don't think it needs too much PMC attention. Smaller projects need that - and people who are involved in cross-project would help much more. But that doesn't change the fact that jakarta commiters should make the proposals and vote. Neither the fact that this should have been discussed on the general list before. Yes - it would have been controversial and probably it would have taken a long time to get an agreement. ( sorry, I'm not sure about this whole "have been" thing, it's not a simple past tense :-). To voice my disapproval with the current process, I won't participate in the current ballot. +1 ( doesn't matter anyway - in the current rules only PMC members can vote to add new PMC members anyway ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
My hope is that the "library" project will be organized in a way that allows multiple "books" in each collection. I agree, it's important to allow different ideas to flower rather than impose a "one true way" philosophy. But I also think it's important to keep strong quality control on anything that goes out under the Apache/Jakarta names. Except that we should act as librarians or even critics for the code, not censors. The books that are going to go in library are written by Apache authors, part of apache projects. Sometimes is too easy to say something is "not good" because we don't understand it. The project should _host_ and maintain code that is shared by projects, not _develop_ utils that may be needed ( like CPAN, or alexandria ). -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
My own hope is that each component be treated like a book, with it's own publication date, edition count, and set of authors and editors. And again - we'll act as librarians and make sure the book is available, not as censors or authors of competing books. For this branch, we probably need a relevance criteria -- that the component is something that * could be * shared among other ASF subprojects. Though, I would think whether a product actually uses a component, or whether products use different flavors of similar components, is something the subproject committers have to decide for themselves. We can lead the subprojects to water, but we can't make them drink. I believe we are trying to solve the wrong problem. I think the problem is not "reuse", but "sharing". It's not "making them drink", but making sure the water is clean. If someone chooses to duplicate a piece of code, maybe the problem is with the way the code is written and shared. That's why I think a library would be very good - not because it'll force people to read, but because it'll make authors to make their code more reusable and deal with the sharing problems. It may eliminate all the ugly dependencies between a suposedly "shared" component and the project that hosts it. Or eliminate the claim that the component is shared. CPAN is great because it makes Perl writters to follow some conventions ( make the code modular, etc ) - it helps sharing the code. It doesn't even try to choose or judge or create code... Nor to force people to reuse. -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
The project should _host_ and maintain code that is shared by projects, not _develop_ utils that may be needed ( like CPAN, or alexandria ). How can that work in the current "project committer" model? I agree that it should be open to accept projects from the 'outside', but I think that to do that, it is required that it convert to the regular development model going forwards. Not code from outside - we don't know what to do with our own code... Each jakarta project already has lots of code that could be shared - that's what we need to resolve first. I want to participate in a Jakarta Tools project, as I see a need (personal, communal, and global) for high-quality tools for building server based applications in Java. I know people who will go looking at application servers because they want a good connection pool, and that doesn't make sense to me. I'm not sure I agree with that. My view of Jakarta Tools is not a project where connection pools are developed - but a project where connection pools developed in other projects or used by multiple projects are shared. If 2 apache projects are using a similar piece of code, and at least one wants to share it - rupert/alexandria/tools should be the place where the shared code should be hosted ( or both - if both projects want to share). The development should be done by the people who are using the code. I believe the problem we need to solve is sharing - it doesn't mean "I have a connection pool, you can use it", it also mean designing the connection pool in a modular way ( not "you can use it, but you need the whole project to use it"), and sharing the future development and control over that component ( including interface stability and giving -1 power to the people we share it with ). As for commiters - each component will have a set of commiters ( but "share" means the set is not formed only from original authors, but other commiters from jakarta projects the component is shared with ) Jakarta is rich in general-use tools. We just need to get them out into the light of day, documented, and supported directly, not incidentally as part of larger projects. +1. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
If someone chooses to duplicate a piece of code, maybe the problem is with the way the code is written and shared. I think in some cases, its bacause people aren't aware that the stuff exists. Go through the Jakarta project sites, and find the number of places that offer a separate, clean FOO tool that supports BAR. (Choose your tool and it's expected functionality). That's also a sharing problem - the code is too deep inside a project. BTW, blaming the users ( for using the wrong OS for example ) is not working. Changing the code and placing it where it can be found may help. -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nightly builds
Hi Sam, I (think ) I got gump to work, it's not updating/building. There are few issues/sugestions. I tried to find the alexandria list ( I assume the discussion on gump happens on alexandria ), I'm sure it is somewhere and I'll keep searching :-) Anyway - it would be possible to switch tomcat3.x nightly builds to use gump, with few small changes in the project definition. The main issue is that (IMHO) you should relax a bit the dependencies: a number of projects had releases, and I think other projects should depend on the (stable) release of those projects. For example, tomcat, servletapi, etc should depend on released-ant-1.2, not jakarta-ant, etc. Whenever a project has a major release - we should of course update the scripts to make all projects depend on the latest "stable" and fix all projects that are in development mode to match the latest "stable". Given that each project has independent release cycle, I don't think it's normal for a stable release of a project to depend on a development release of another project ( for example, tomcat 3.3 shouldn't depend on the dev. release of ant - but on the latest "stable" ant. If ant1.3 will be released before 3.3 is "frozen", then tomcat3.3 should be fixed to make sure it works with ant 1.3 - if not, it should stay dependent on the released ant 1.2 ). This can be resolved by adding "project/released-ant-12.xml", etc. Another issue - wouldn't be better to generate build.xml instead of build.sh and build.bat ? Most of the code inside build.sh can be done easily in a "super" build.xml that calls ant. It is even possible to use java tags to start different VMs. I think this would be easier to maintain and enhance. Another think - one planned feature for tc3.x build was a mechanism to triger a build from a web page ( so if someone does a change, he doesn't have to wait until the next night to find out if it brakes something ). My plan was to use the ant taglib ( that is also used to run the tests from a web page ) and write a simple build.war that will allow runs of the build from the web. That would also allow a lot of simplification ( since wars are self contained and have a stable environment/structure ). It would also modularize a bit the build ( a page to update a repository, a page to build, no more "echo \foo\", etc ) Finally: it would be nice if the build scripts would get the sources using http-get instead of cvs. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nightly builds
Others can run builds with stable dependencies. They are permitted, and even encouraged to do so using Gump. The runs I have been making are to determine the impact of changes - something that I think that has not received enough attention, and so that's why I have been and will continue to focus the runs that I make on that. That's a valid configuration, I'm not saying to drop it - I just want to be sure that both "styles" are supported. My interest is in using gump for tomcat3.x builds - maintaining the scripts for testing is enough effort, if I can use gump for building I'll save time. The tomcat nightly should include the latest tomcat and the stable dependencies - whenever it'll be released, it can't depend on the "latest" ant but on the "latest release". Since you gave the specific example of ant, I do not like the idea of ant-1.3 being released without some assessment of the impact of changes on other projects. There was a change that would have gone into 1.3 that True - I will probably start using/testing ant-1.3, since it'll probably be released before tc3.3. Given the number of projects we have here, each project binding too closely to exactly one version of each of their prereqs means that someone who desires to compose a system out of these components is likely to run into Assuming an change happens in ant-1.3 ( or ant-1.4 or 2.0 ), should tomcat/xalan/etc be updated to use the latest ant or the stable ant ? Yes, in theory all API/DTD changes should be backward compatible - but in reality we are talking about projects that are in development mode, not about "standard" APIs. And if a project has a dependency on another project, it is expected to track the changes ( and we did changed the build.xml several times already ), but with certain granularity. IMHO relaxing the requirement to "latest released version" is a very good idea. Maybe when a project enters "feature freeze" or "beta" we can update the builds and make sure all other projects work with the freezed APIs/DTDs, and roll back/fix what is broken. problems. So, in fact, I would be greatly pleased if there were multiple nightly builds going on out there with different combinations. And A tomcat3.x nightly build will happen soon. Making ant build.xml files as a target of gump would be a valuable addition. It has been often discussed, but never contributed. Getting using http as an alternative to cvs would also make a great addition. My time is as limited as anyone else, but I'll try to do at least (1). ( if you remember the nightly builds of tomcat used to be ant-based and used to use get, so most of the code is there, it just need to be geenralized to gump ) P.S. What does it mean to have gump "working", but not "updating/building"? It means: spell error, I meant "is no_w_ updating" (instead of "not"). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
Ted Husted wrote: may we please have a interim Jakarta "libary" mailing list for the purpose of formaling the details of a proposal for this subproject. Are you sure that you want to call it that. ;-) Beyond the typo...the name of the mailing list should match the name of the subproject. I'm willing to create the mailing list in anticipation of the project being created, but it like to be sure that the name is what everybody wants. Well, if it's a library - why not calling it "alexandria" - it would be a nice name for that :-) Ops, the name is taken - but maybe we can re-use it - after all alexandria is already a project that is shared by all other projects ( since it contains tools that put togheter everything, etc). Seriously speaking - I am very concerned with the content of the library - I have a feeling that some people would like one book for each subject. I think that would be a very big step backwards. My hope is that the "library" project will be organized in a way that allows multiple "books" in each collection. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta-tools ? Re: Code Sharing Concepts
I'll try again: 1. As someone said, "community is more important than code" 2. I think the real problem here is not "code sharing" - the fact that people are reticent to reuse code developed in other projects is just an effect 3. I think the real problem is that each project has it's own community and commiters, instead of a shared "jakarta community". 4. I think the only way to solve the reuse problem is to make sure that all jakarta commiters are part of the "tools/utils" project. That's my point - I'm not proposing to create ( now ) a repository open to everyone in the world, just to all interested jakarta commiters. Beeing a commiter in one of the projects means more than the fact that you have CVS access and the right to vote - it means you feel part of the project community. If you are commiter in one of the jakarta projects and you are interested in working on any "shared" code, you should automatically be a commiter for the shared piece. My proposal is to create a place where all jakarta commiters have a common interest - the shared tools. If we can't manage this - that means something is broken in the concept of "jakarta community" - and a different solution is needed. But it's worth trying ( starting with few small tools ), and see if we can manage to work togheter. We can have 10 different Pools or StringManagers - in time they'll converge or specialize and cover different niche. There is nothing wrong with having 4 solutions for a test suite, as long as all people working on this are sharing a common repository and community, and the community is open to new code ( even if it's duplicated ) as long as the code is shared. I think all "tools" should be shared - but the code is less important in this case, we should share the community ( by making all jakarta commiters members of the tools project ). Costin [EMAIL PROTECTED] wrote: Again, I don't like the idea of "framework" - i.e. a team managing all tools and releasing them as a whole. It seems what works is the idea of modules ( like CPAN modules ). And the modules should have independent life and evolution. We can tag individual packages for each project that includes it. I don't think anyone has meant to propose that. I have suggested that we create a Jakarta Components Library as a microcosm of the greater project. There would be a core group of Committers (like the PMC) who would act as the overall gatekeepers of the library. Each component in the library would have its own set of Committers, which would usually be the person or persons who wrote the original code, and who has a vested interest in the component. Each component would have its own release schedule and versioning, stable versions and latest builds. Of course, as a convenience, there might be a full library JAR of all the stable versions. If we can get this library to work for our own tools, then, of course, we should look at creating a greater CJAN library. Something like this would be more like CPAN or SourceForge, and be open to all comers. But we should weed our own garden first. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 425-0252; Fax 716 223-2506. -- http://www.husted.com/about/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Backing out...(was: Re: What is Jakarta?)
And Tomcat 3.3 probably wouldn't have a ratified release plan or nearly as many volunteers to support it. +1. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta-tools ? Re: Code Sharing Concepts
What about starting the "reuse" quest by reusing the jakarta-tools
repository ?
Wouldn't that break the "old" version of Watchdog ("jakarta-watchdog") that still
has dependencies here?
In what way ? By adding new directories and tools the old one shouldn't be
affected. Watchdog is using moo.jar ( which is also used by tomcat3.3 to
run the watchdog from a web application ).
At any rate, the process questions need to be settled now (before any of us get
any more entrenched in our attitudes :-) -- IMHO it is premature to start checking
in code.
I don't expect too much code to be checked in in the close future, but I
hope this will move us from "talk" state into "do" state, and maybe at
least 1-2 tools will be checked in to jumpstart the process and to allow
us to test the concepts.
It's hard to know if something will work you don't try.
--
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
