Paul Benedict wrote: > 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.
I was planning to use Ant to generate the jdbc3 release jar anyway, since the Ant build has the filtering set up and I am not dying to wrestle maven into doing this. So here is a slightly kludgy solution that IIUC would be maven-tolerable: 1. Run the Ant build under 1.5 to filter the sources into /build/src 2. Copy the pom to /build 3. cd /build and execute mvn source:jar mvn javadoc:jar mvn package there (from the filtered sources) 4. cd back to basedir and execute the release build using the pom modified to attach the artifacts in /build with jdbc3 classifiers (as in subetha example, though using two levels in the classifiers for the sources and javadoc jars - jdbc3-sources, jdbc3-javadoc) This seems to work. If there are no objections, I will cut an RC between veggie turkey bites tomorrow using this approach. Phil > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
