Naming things with too many dots can confuse some of the containers, so, personally, I follow the XML conventions and use underscores, e.g.
struts_1_1_b1.jar One question would be what to do about the nightly builds. These are unreleased products and do not really get a version number until they are released. So we might have struts_nb.jar or stuts_nb_20020710.jar We can unilaterally change our own JARS, and probably most of the Commons JARs, since we have members on those teams. As a volunteer organization, it's not actually possible for the ASF to "enforce" conventions like this. None of are paid and so it can be hard to tell us what to do =:0). The ASF has only one stick: pull the product from distribution by the Apache web sites -- which is not something they would do over a packaging convention. And making the change unilaterally, without committer involvement, would be a violation of trust. Since we do the work, the ASF lets us make the decisions. What would make the biggest difference would be to submit enhancements to the products through Bugzilla, and include a patch for each of their build.xml's, and also post patch to the Jakarta guidelines to the General list reflecting how you'd like this done. Since this is a volunteer organization, the best way to get the attention of the other volunteers is to do the actual work for them =:0) -T. David Mulligan wrote: > > I'm wondering the same! > > Would it be possible to name the jar files like so > > commons-beanutils-1.4.jar > commons-collections-2.0.jar > commons-digester-1.3.jar > commons-logging-1.0.1.jar > commons-pool-1.0.jar > struts-1.1-b1.jar > etc? > > I know this isn't a struts problem and it would be a bad idea for the struts > > team to start renaming the jar files from other Jakarta projects. But would > it be possible for all Jakarta projects to follow this standard? That would > make my and I'm sure a lot of other people's lives easier. > > Is this a bad idea, if so why? > I know it would make the creation of build scripts a little harder, but it > would still be possible to create them. > > The other option is the META-INF/MANIFEST.MF file. > Most jar files contain there version number in them but not all. > For example Version 2.0 of commons-collections.jar manifest file contains > 'Implementation-Version: 1.1-dev' and not 'Implementation-Version: 2.0' > > While struts.jar version 1.1-b1 contains 'Implementation-Vendor: Apache > Software Foundation' > Would it be possible to enforce this a bit more? > > Just me 2 (euro) cents. > > -----Original Message----- > From: Arnaud HERITIER [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 10, 2002 12:33 PM > To: Struts-Dev (E-mail); Struts Users Mailing List (E-mail) > Subject: Struts dependencies > > Hi guys. > > I downloaded the last nighty build of struts. > > I would like to know which releases of external libraries are packaged with > it. > > I already uses some libraries of jakarta commons and I would like to know > which one I need to upgrade. > > After studying the manifest of jars I listed this : > > commons-beanutils : 1.4 dev > commons-collections : 2.0 > commons-dbcp : unknown (last dev I suppose) > commons-digester : 1.3 dev > commons-logging : 1.0.1 dev > commons-pool : 1.0 > commons-services : 1.0 dev (can't find it on the jakarta site. What it is > ??) > commons-validator : unknown (last dev) > jakarta-oro : unknown > > Can you confirm my assumptions. > > Are all jars usefull for struts or are there some of them used by some > extensions like tiles, .. ??? > > Thanks a lot. > Arnaud HERITIER > EAI Consulting > Sopra Group > Tél. : +33 (0)1 53 33 44 74 > email : [EMAIL PROTECTED] > > Ce message est exclusivement destiné aux personnes dont le nom figure > ci-dessus. Il peut contenir des informations confidentielles dont la > divulgation est à ce titre rigoureusement interdite. Dans l'hypothèse où > vous avez reçu ce message par erreur, merci de le renvoyer à l'adresse > e-mail ci-dessus et de détruire toute copie. > > This message may contain confidential and proprietary material for the > sole use of the intended recipient. Any review or distribution by others is > strictly prohibited. If you are not the intended recipient, please contact > the sender and delete all copies. > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- Ted Husted, Husted dot Com, Fairport NY US -- Java Web Development with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
