Does adding a classifier like "jdbc3" affect the creation of the -source and -javadoc classifiers?
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
