commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [dbcp] 1.3 release packaging - take two
Date Thu, 26 Nov 2009 06:21:27 GMT
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
> <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
> 


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


Mime
View raw message