As I was the one that checked in the latest beanutils that started this can I ask what was broken? You say it was because it used commons-logging but I updated that as well. I did check that it did not break stratum, torque, fulcrum and t3. And the reason I updated was that I knew at that point that the head of beanutils would work for these packages, I did not know whether any other revision would work.
Since there several versions of beanutils, it makes sense to me that the commons-beanutils.jar filename would refer to the latest code. Are you saying an unversioned filename should always refer to the latest released version of a library? If so I propose we use the convention commons-beanutils-HEAD.jar or commons-beanutils-dev.jar to mean the library built from the latest cvs. I guess I did not follow the decision process on unversioned filenames, what was the conclusion (if it is a simple one liner)? The solution above is simpler than going to cvs, though that might be a good idea. In my proposal, if a project chooses to use the c-b-dev.jar (or c-b.jar whichever is decided means HEAD code), then it is that projects' responsibility to fix any breakage due to someone else updating the repo. It is a good idea to email the list noting that a dev jar has been updated, though with all the lists and the fact that it could be breaking an outside app, I do not see how a developer updating the dev jar can be expected to know exactly where to note the change. john mcnally Jason van Zyl wrote: > > On Fri, 2002-04-05 at 09:25, Humberto Hernandez Torres wrote: > > I cannot point exaclty why but I have the feeling that there are some > > advantages on the way the modules are managed in CPAN. Somehow you don't > > have to worry much about versions or CVS. > > > > This are some of the CPAN features from the top of my head. > > - The number of packages available is way bigger. I presume they are also > > smaller and every module has an owner. > > Hopefully we'll have a large number of packages too :-) > > > - Modules are better organized on categories. > > It would definitely be a good idea to make a set of categories and allow > the specification of cateogies in the POM. Then we could make an > indexing tool to help people search for software easily. > > > - All the Makefiles work exactly the same. > > This what I would like to see with the use of maven. I'm hoping that > people will want to use Maven because it provides some real value and > just becomes the de facto method for building projects. Optimistic I > know, but if it works well I'm hoping developers will be attracted to > it. > > > - Mirroring. > > This is something to work out, but we definitely have the good CPAN > model and there are a number of sites that mirror the apache httpd > project so maybe we could leverage those mirror sites for a CJAN type > repository. > > > - You can automagically search, download, build, test and install. > > Maven will do this. > > > - The installer (CPAN::Shell?) can upgrade itself. > > Maven will do this too eventually. > > > - Automatic upgrading of dependencies. > > Maven does this. > > > -- > > Humberto > > > > > > -----Original Message----- > > From: Eric Dobbs [mailto:[EMAIL PROTECTED]] > > Sent: Friday, April 05, 2002 12:10 AM > > To: Turbine Developers List > > Subject: Re: Updating the repository > > > > > > > > On Thursday, April 4, 2002, at 03:52 PM, Jason van Zyl wrote: > > > > > I am trying to get in touch > > > with some of the CPAN fellows and ask why they chose to setup CPAN they > > > way they did. They are not using CVS for their distribution mechanism > > > and I would be curious as to know why as they obviously have a model > > > that works. > > > > One of the salient features of CPAN is the mirroring. CPAN > > grew up when the network was generally slow and it was much > > better to get things from a local mirror than to haul stuff > > all over the network. I'll bet mirroring was a design goal. > > Another feature of CPAN is the multiple indexes. There's a > > ton of stuff in CPAN. > > > > It might also be worth talking with the creators of various > > package managers from Debian and RedHat, etc. Seems like > > they are playing a similar game. > > > > There's one thing I have to agree with Jon about. The > > problem with jar files is a version management problem. It > > just makes sense to use a version control system. It's the > > right tool for that particular problem. You could even > > lean completely on cvs tags and remove the need for versions > > in the jar names (not that I want to start the whole argument > > about versions in jar names). > > > > -Eric > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- > jvz. > > Jason van Zyl > [EMAIL PROTECTED] > > http://tambora.zenplex.org > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
