On Wed, Nov 25, 2009 at 11:31 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > Niall Pemberton wrote: >> On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict <pbened...@apache.org> wrote: >>> Phil, >>> >>> I don't think you should be modifying the version (and groups, really) >>> here. All the artifacts belong to version 1.3. >>> >>> Maven does have a concept of a qualifier, but according to Sonatype, >>> it's only to capture milestone builds: >>> http://www.sonatype.com/books/maven-book/reference/pom-relationships-sect-pom-syntax.html >> >> I don't think this is true maven has used "classifier" to distribute >> various artifacts that are attached to the project - such as >> "sources", "javadocs", test jar and it talks about them here in the >> same book >> >> http://www.sonatype.com/books/maven-book/reference/assemblies-sect-output-algorithm.html#assemblies-sect-transitive >> >> Also its been a fairly common pratice with many projects using a maven >> build to provide JDK 1.4 compatible jars after the project moved to >> JDK 1.5 using some kind of classifier - this is pretty much the same >> situation. >> >> If you use a different artifactId for the different jars then its >> going to be a bigger PITA for the release - since you'll need a pom >> and have to update maven-metadata.xml - probably anually. This is what >> happened in BeanUtils and doing a release is much more painful and >> prone to errors. > > Stupid question. Assuming we go the classifier route, how can I use > just one pom? I was assuming I would have to hack a second pom in > either case.
AFAIK you don't have to do anything - just produce the additional jars with the classifier in the name - its people who consume it who specifiy the classifier - for example say you produce an additional jar called commons-dbcp-1.3-jdbc3.jar then if someone wanted to use that rather than the standard commons-dbcp-1.3.jar then they would specify the dependency as follows: <dependency> <groupId>commons-dbcp</groupId> <artifactId>commons-dbcp</artifactId> <version>1.3</version> <classifier>jdbc3</classifier> </dependency> Haven't read it, but also found this: http://www.sonatype.com/books/maven-book/reference/profiles-sect-platform-classifier.html Niall > Phil >> >> I would go down the classifer route. >> >> Niall >> >>> What you have, simply, is, different artifacts. Keep the same groupId >>> and version, just alter the artifact names. >>> >>> JDBC 4 version (JDK 1.6) >>> groupId = org.apache.commons >>> artifactId = commons-dbcp >>> version = 1.3 >>> >>> JDBC 3 version (JDK 1.4-1.5) >>> groupId = org.apache.commons >>> artifactId = commons-dbcp-jdbc3 >>> version = 1.3 >>> >>> Paul >>> >>> On Wed, Nov 25, 2009 at 4:14 PM, Phil Steitz <phil.ste...@gmail.com> wrote: >>>> Phil Steitz wrote: >>>>> I am about to roll an RC and I need to make sure all are OK with the >>>>> artifact names and repo placement >>>>> >>>>> JDBC 4 version (JDK 1.6) >>>>> groupId org.apache.maven >>>> Oops! I obviously mean commons above :) >>>>> artifactID commons-dbcp >>>>> version 1.3 >>>>> >>>>> JDBC 3 version (JDK 1.4-1.5) >>>>> groupId commons-dbcp >>>>> artifactId commons-dbcp >>>>> version 1.3-jdbc3 >>>>> >>>>> Giving the 1.3 name to the 1.6 version makes sense as this is the >>>>> main development version. Moving it gets it into compliance with >>>>> the maven standard and avoids unintended consequences of upgrading >>>>> for 1.4-1.5 users by requiring a bigger change. >>>>> >>>>> Alternatively, we could put descriptors on both and leave placement >>>>> as is. Opinions please. >>>>> >>>>> Phil >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org