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.pember...@gmail.com> wrote:
On Thu, Nov 26, 2009 at 12:46 AM, Paul Benedict <pbened...@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.ste...@gmail.com> wrote:
Niall Pemberton wrote:
On Wed, Nov 25, 2009 at 11:39 PM, Niall Pemberton
<niall.pember...@gmail.com> wrote:
On Wed, Nov 25, 2009 at 11:31 PM, Phil Steitz <phil.ste...@gmail.com> wrote:
Niall Pemberton wrote:
On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict <pbened...@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.ste...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
