commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz SÅ‚owikowski <gslowikow...@gmail.com>
Subject Re: [dbcp] 1.3 release packaging - take two
Date Thu, 26 Nov 2009 09:59:36 GMT


Phil Steitz wrote:
> 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)
>
>   
If you want to go it this way, then "jdbc3" is not a classifier, it is a 
name suffix.
> This seems to work. If there are no objections, I will cut an RC
> between veggie turkey bites tomorrow using this approach.
>
> Phil
>
>   
Hi

I want to add something from myself, I think I'm experienced Maven user.

1. As Paul said, when you have two different sources you should not try 
to use classifiers
(I think technically it could be possible, but it is wrong way). There 
are projects generating
two artifacts: base one and  jdk 1.4 compatible one. As i know, the 
second one is generated from
the same classes as the first one using retrotranslator or retroweaver 
plugin in the build process.
Subethasmtp is a good example:
http://repo2.maven.org/maven2/org/subethamail/subethasmtp-smtp/1.2/subethasmtp-smtp-1.2.pom

2. I agree with Jorg that the JDBC3 version should be the natural 
continuation of previous
versions, so commons-dbcp:commons-dbcp:1.3 would be for JDBC3, not JDBC4.
I know that Tomcat developers are waiting for new version of 
commons-dbcp because of some leaks
in current commons-pool version (if I remember). Tomcat6 has Java5 as a 
minimum. I thing, they
will not use jdbc4 version of commons-dbcp. If jdbc3 compatible version 
will have different name
("-jdbc3" suffix) you will have to answer millions of questions about it.

3. The build process described here by Paul should work, but I don't 
like the Maven+Ant hybrid.
Tomcat developers (again) will have problems, because they are 
generating their "tomcat-dbcp.jar"
from commons-pool and commons-dbcp sources. They download these two 
sources bundle,
change package names and merge them into one archive. If commons-dbcp 
sources will be
jdbc4 compatible, they will have to repeat your 1. step above.
I wonder if it is possible to split commons-dbcp code base into two 
modules and build them
entirely in Maven. I made some simple tests. I could upload it somewhere 
for you.

Sorry for my English

Greetings

Grzegorz Slowikowski
>> 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
>
>
>   

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


Mime
View raw message