When I was patching Hibernate, they needed different sources because of JDBC3/4 incompatibility. It just wasn't possible to compile for both dependencies.
I just checked with Brett Porter of Maven. He says that if the sources are identical, you can use qualifiers; otherwise it would conflict when you generate sources/javadocs/tests. You couldn't publish different sources/etc. once the qualifier is used -- makes sense you can't append more than one qualifier. Based on this advice, I revert to my previous advice and say they should be separate artifactIds with no qualifiers. Paul On Wed, Nov 25, 2009 at 6:51 PM, Niall Pemberton <niall.pember...@gmail.com> wrote: > On Thu, Nov 26, 2009 at 12:46 AM, Paul Benedict <pbened...@apache.org> wrote: >> Does adding a classifier like "jdbc3" affect the creation of the >> -source and -javadoc classifiers? > > I don't believe it should - those are produced by the sources and > javadoc plugins respectively. In the commons build those plugins are > configured to produce the source/javadoc jars only in the "rc" profile > - so running mvn -Prc package should see them produced. > > Niall > >> On Wed, Nov 25, 2009 at 6:06 PM, Phil Steitz <phil.ste...@gmail.com> wrote: >>> Niall Pemberton wrote: >>>> On Wed, Nov 25, 2009 at 11:39 PM, Niall Pemberton >>>> <niall.pember...@gmail.com> wrote: >>>>> 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 >>>> >>>> Found an example subethasmtp-smtp has a JDK 1.4 jar: >>>> >>>> http://repo2.maven.org/maven2/org/subethamail/subethasmtp-smtp/1.2/ >>>> >>>> And Commons Email 1.2 depends on the JDK 1.4 jar: >>>> >>>> http://repo2.maven.org/maven2/org/apache/commons/commons-email/1.2/commons-email-1.2.pom >>> >>> Thanks, Niall! >>>> >>>> Niall >>>> >>>>> 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 >>>> >>> >>> >>> --------------------------------------------------------------------- >>> 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
