Jörg Schaible wrote:
Hi Grzegorz,
Grzegorz Słowikowski wrote at Donnerstag, 26. November 2009 10:59:
[snip]
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.
You will always have an Ant task to perform the source generation of the
"conditional" compilation. The trunk builds only with JDBC4, the Ant task
has to run before building against JDBC3.
So I wrote about splitting the codebase into two modules. Lately I'm
creating some library
with jdbc wrappers so I have the same problem. I wrote it against jdbc3 API.
Yesterday I have tested it against jdbc4. My solution it to create
second module for jdbc4
with classes extending the ones in jdbc3 module with additional methods
from jdbc4.
I've made two test modules: for java 1.5 and for Java 1.6 (enforced with
maven-enforcer-plugin).
Both test modules test both base modules and it works.
My modules:
jdbc3 - jdbc3 wrappers, module compiled with Java 1.5
jdbc4 - jdbc4 wrappers extending jdbc3 wrappers compiled with Java 1.6
java15-tests - tests for jdbc3 and jdbc4 modules compiled and run on
Java 1.5
java16-tests - tests for jdbc3 and jdbc4 modules compiled and run on
Java 1.6
Both java15-tests and java16-tests work so
it is possible to follow this way.
I made some simple tests. I could upload it somewhere
for you.
You might use the -source artifact as dependency in the second module and
unpack it with the dependency plugin and use then the Ant task to prepare
the sources.
I don't like it, but technically it's trivial. You will have problems
how to marriage it with IDE
developing.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
