commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Benedict <pbened...@apache.org>
Subject Re: [dbcp] 1.3 release packaging - take two
Date Thu, 26 Nov 2009 04:03:09 GMT
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
<niall.pemberton@gmail.com> wrote:
> On Thu, Nov 26, 2009 at 12:46 AM, Paul Benedict <pbenedict@apache.org> wrote:
>> Does adding a classifier like "jdbc3" affect the creation of the
>> -source and -javadoc classifiers?
>
> I don't believe it should - those are produced by the sources and
> javadoc plugins respectively. In the commons build those plugins are
> configured to produce the source/javadoc jars only in the "rc" profile
> - so running mvn -Prc package should see them produced.
>
> Niall
>
>> On Wed, Nov 25, 2009 at 6:06 PM, Phil Steitz <phil.steitz@gmail.com> wrote:
>>> Niall Pemberton wrote:
>>>> On Wed, Nov 25, 2009 at 11:39 PM, Niall Pemberton
>>>> <niall.pemberton@gmail.com> wrote:
>>>>> 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
>>>>
>>>> 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.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
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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