On Thu, Nov 26, 2009 at 12:46 AM, Paul Benedict <[email protected]> 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 <[email protected]> wrote: >> Niall Pemberton wrote: >>> On Wed, Nov 25, 2009 at 11:39 PM, Niall Pemberton >>> <[email protected]> wrote: >>>> On Wed, Nov 25, 2009 at 11:31 PM, Phil Steitz <[email protected]> >>>> wrote: >>>>> Niall Pemberton wrote: >>>>>> On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict <[email protected]> >>>>>> 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 <[email protected]> >>>>>>> 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: [email protected] >>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>> >>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
