[dbcp] 1.3 release packaging - take two

classic Classic list List threaded Threaded
68 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

[dbcp] 1.3 release packaging - take two

Phil Steitz
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
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Phil Steitz
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Paul Benedict
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

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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Brent Worden-2
On Wed, Nov 25, 2009 at 4:23 PM, Paul Benedict <[hidden email]> 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
>
> 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
>

I do not agree with the artifact/version statements.  In my mind,
different artifactId's imply the jars are companion or supplementary
artifacts.  The JDBC 3 and 4 version of commons-dbcp are drop in
replacements of each other.  To me, this implies different artifact
versions.

I do agree, that the groupId should be constant.

Also, if the multiple version approach is taken, I would explicitly
call out the JDBC version in all artifacts in order to be consistent
and eliminate user ambiguity.

Brent

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Phil Steitz
In reply to this post by Paul Benedict
Paul Benedict 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
>
> What you have, simply, is, different artifacts.

Makes sense.  Thanks.

 Keep the same groupId
> and version, just alter the artifact names.

What I was trying to avoid by moving the groupId to
org.apache.commons for the JDBC 4 artifact was 1.4-1.5 users
unwittingly upgrading to 1.3 and blowing up.  This is also a change
we need to make at some point.

Phil

>
> 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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Paul Benedict
In reply to this post by Brent Worden-2
Brent,

If you haven't read the Sonatype link, it tells some important things
about how the version number is interpreted by Maven. The standard is
using 3 numbers, and it allows Maven to know that, for example, 1.3 <
1.4. But what happens if you version as "1.3-jdbc3"? Is anyone going
to confident in that 1.3 < 1.3-jdbc3? It's not a version number, but
clearly a different artifact. As the link says, Maven treats
non-standard version numbers as straight lexical comparisons.

For users who use employ version ranges in their POMs like "[1,3,)"
they are telling Maven they want >= 1.3. It is misleading -- I
actually believe wrong -- to say that the "1.3-jdbc3" version is less
than version "1.3".

I think it's clear you have separate artifacts because the "1.3-jdbc3"
incorrectly fit on the range of version numbers.

Paul

On Wed, Nov 25, 2009 at 4:56 PM, Brent Worden <[hidden email]> wrote:

> On Wed, Nov 25, 2009 at 4:23 PM, Paul Benedict <[hidden email]> 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
>>
>> 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
>>
>
> I do not agree with the artifact/version statements.  In my mind,
> different artifactId's imply the jars are companion or supplementary
> artifacts.  The JDBC 3 and 4 version of commons-dbcp are drop in
> replacements of each other.  To me, this implies different artifact
> versions.
>
> I do agree, that the groupId should be constant.
>
> Also, if the multiple version approach is taken, I would explicitly
> call out the JDBC version in all artifacts in order to be consistent
> and eliminate user ambiguity.
>
> Brent
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Olivier Lamy
In reply to this post by Phil Steitz
Hi Folks,
If you change groupId could you please provide a relocation pom in the
old groupId
commons-dbcp:commons-dbcp:1.3 -> org.apache.commons:commons-dbcp-jdbc3:1.3

--
Olivier

2009/11/26 Phil Steitz <[hidden email]>:

> Paul Benedict 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
>>
>> What you have, simply, is, different artifacts.
>
> Makes sense.  Thanks.
>
>  Keep the same groupId
>> and version, just alter the artifact names.
>
> What I was trying to avoid by moving the groupId to
> org.apache.commons for the JDBC 4 artifact was 1.4-1.5 users
> unwittingly upgrading to 1.3 and blowing up.  This is also a change
> we need to make at some point.
>
> Phil
>>
>> 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 <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



--
Olivier

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Paul Benedict
In reply to this post by Paul Benedict
Correction:

For users who use employ version ranges in their POMs like "[1.3,)"
they are telling Maven they want >= 1.3. It is misleading -- I
actually believe wrong -- to say that the "1.3-jdbc3" version is a
greater version than
than version "1.3".

Paul

On Wed, Nov 25, 2009 at 5:05 PM, Paul Benedict <[hidden email]> wrote:

> Brent,
>
> If you haven't read the Sonatype link, it tells some important things
> about how the version number is interpreted by Maven. The standard is
> using 3 numbers, and it allows Maven to know that, for example, 1.3 <
> 1.4. But what happens if you version as "1.3-jdbc3"? Is anyone going
> to confident in that 1.3 < 1.3-jdbc3? It's not a version number, but
> clearly a different artifact. As the link says, Maven treats
> non-standard version numbers as straight lexical comparisons.
>
> For users who use employ version ranges in their POMs like "[1,3,)"
> they are telling Maven they want >= 1.3. It is misleading -- I
> actually believe wrong -- to say that the "1.3-jdbc3" version is less
> than version "1.3".
>
> I think it's clear you have separate artifacts because the "1.3-jdbc3"
> incorrectly fit on the range of version numbers.
>
> Paul
>
> On Wed, Nov 25, 2009 at 4:56 PM, Brent Worden <[hidden email]> wrote:
>> On Wed, Nov 25, 2009 at 4:23 PM, Paul Benedict <[hidden email]> 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
>>>
>>> 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
>>>
>>
>> I do not agree with the artifact/version statements.  In my mind,
>> different artifactId's imply the jars are companion or supplementary
>> artifacts.  The JDBC 3 and 4 version of commons-dbcp are drop in
>> replacements of each other.  To me, this implies different artifact
>> versions.
>>
>> I do agree, that the groupId should be constant.
>>
>> Also, if the multiple version approach is taken, I would explicitly
>> call out the JDBC version in all artifacts in order to be consistent
>> and eliminate user ambiguity.
>>
>> Brent
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Phil Steitz
In reply to this post by Olivier Lamy
Olivier Lamy wrote:
> Hi Folks,
> If you change groupId could you please provide a relocation pom in the
> old groupId
> commons-dbcp:commons-dbcp:1.3 -> org.apache.commons:commons-dbcp-jdbc3:1.3

Will do if we decide to go that route.

Phil

>
> --
> Olivier
>
> 2009/11/26 Phil Steitz <[hidden email]>:
>> Paul Benedict 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
>>>
>>> What you have, simply, is, different artifacts.
>> Makes sense.  Thanks.
>>
>>  Keep the same groupId
>>> and version, just alter the artifact names.
>> What I was trying to avoid by moving the groupId to
>> org.apache.commons for the JDBC 4 artifact was 1.4-1.5 users
>> unwittingly upgrading to 1.3 and blowing up.  This is also a change
>> we need to make at some point.
>>
>> Phil
>>> 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 <[hidden email]> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Niall Pemberton
In reply to this post by Paul Benedict
On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict <[hidden email]> 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.

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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Phil Steitz
Niall Pemberton wrote:

> On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict <[hidden email]> 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.

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 <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Paul Benedict
In reply to this post by Niall Pemberton
I think Niall has good counterpoints. I think his point is summed up with:

* Keep same groupId
* Keep same artifactId
* Keep same version
* Different classifiers are appropriate.

If so, I am +1 with it.

Paul

On Wed, Nov 25, 2009 at 5:25 PM, Niall Pemberton
<[hidden email]> wrote:

> On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict <[hidden email]> 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.
>
> 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 <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Niall Pemberton
In reply to this post by Phil Steitz
On Wed, Nov 25, 2009 at 11:31 PM, Phil Steitz <[hidden email]> wrote:

> Niall Pemberton wrote:
>> On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict <[hidden email]> 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 <[hidden email]> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Niall Pemberton
On Wed, Nov 25, 2009 at 11:39 PM, Niall Pemberton
<[hidden email]> wrote:

> On Wed, Nov 25, 2009 at 11:31 PM, Phil Steitz <[hidden email]> wrote:
>> Niall Pemberton wrote:
>>> On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict <[hidden email]> 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

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 <[hidden email]> 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: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Phil Steitz
Niall Pemberton wrote:

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


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Paul Benedict
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 <[hidden email]> wrote:

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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Paul Benedict
Niall,

Since the "sources" and "javadocs" are qualifiers, I am concerned
there is an incompatibility here. I can't prove it, but I suspect
there might be.

Paul

On Wed, Nov 25, 2009 at 6:51 PM, Niall Pemberton
<[hidden email]> wrote:

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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Paul Benedict
In reply to this post by Niall Pemberton
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
<[hidden email]> wrote:

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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

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


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

1234