commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niall Pemberton <niall.pember...@gmail.com>
Subject Re: [dbcp] 1.3 release packaging - take two
Date Wed, 25 Nov 2009 23:39:48 GMT
On Wed, Nov 25, 2009 at 11:31 PM, Phil Steitz <phil.steitz@gmail.com> wrote:
> Niall Pemberton wrote:
>> On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict <pbenedict@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.steitz@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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message