Hi Jorg
Jörg Schaible wrote:
Hi Grzegorz,
Grzegorz Słowikowski wrote at Freitag, 27. November 2009 09:04:
Phil Steitz wrote:
Niall Pemberton wrote:
...
Good points - so what is your recommendation?
org.apache.commons:commons-dbcp4:1.3
commons-dbcp:commons-dbcp:1.3
or
org.apache.commons:commons-dbcp:1.3
commons-dbcp:commons-dbcp:1.3
or
org.apache.commons:commons-dbcp:1.4
commons-dbcp:commons-dbcp:1.3
or?
Phil
...
Think about war files, what you will have in WEB-INF/lib. You CANNOT
have (accidentally,
from transitive dependencies) commons-dbcp and commond-dbcp4 together in
the class path,
so the first proposal is not good.
This can happen for all three proposals. Since the groupId is different
Maven handles the two artifacts in all three cases as unrelated. If the
artifact name for two distinct artifacts clash, it will automatically
prepend the groupId for such cases like the war plugin.
I didn't thought about Maven in this sentence. For me generally it's not
good practice to create
two different artifacts (different artifactId) which cannot be present
in the classpath together.
I narrow differency definition to artifactId only because after you
prepare your distribution
(as zip or war file for example) your users don't see groupids of
contained artifacts.
This comes from my practice, not Maven documentations.
If you release jdbc3 and jdbc4 artifacts from the same release process
(some code commented for
jdbc3 version) - this is one release for me, so the version numbers
should be identical.
Actually we have two incompatible versions. If someone depends (by
transitive deps or directly) on both versions, he has always a problem.
Changing the groupId for one will simply expose the problem more obviously,
because both jars will end up in the dependencies - otherwise Maven version
resolution will silently chose one of them and drop the other one.
If you decide to branch your codebase and separate the release processes
of trunk and branch versions
(1.4 and 1.3) then tis is THE SAME artifact for me. The 1.4 version is
not backward compatible,
but this does not change the fact that this is the same artifact (the
same functionality, the same classes
in the same packages). Don't let Maven (or any other build tool) to
treat them separately and potentially
place both in the classpath.
The situation where both jars will be in the classpath is the case I'm
aware most!!! It's not important
who (Maven, Ant, ?) is responsible for that.
But I see you will probably prefer releasing separately and creating
branch for 1.3.x patch releases.
I would prefer this way too. In this situation we have version 1.3
backward compatible and version
1.4 not compatible. Because incompatibility comes not from your API
changes but from changes
inside Java API, then I say you don't have to change version numbering
to 2.x.x (change on the
first position).
I don't remember what's going on inside Maven build of war artifact if
you have two dependencies
with different group ids and the same artifact ids. They are different
artifacts and there is no
version resolution between them. Maven war plugin prepares war content
in "target/{artifactId}-{version}" directory before creating war file,
so one of these files will
overwrite the other I think.
As explained - no.
You are right. I forget about varsions in file names.
If some other build tool would create war archive on the fly, both files
could be packaged
because there are no constraints on unique file names inside jars/wars
and this would be very bad!
Therefore we want to change the version for the JDBC version4, so we end up
for those tools with two distinguishable names: commons-dbcp-1.3.jar and
commons-dbcp-1.4.jar
The same as above.
Additionally I remember some discussions on Maven lists against
relocations (some Apache
Commons project changed its groupId to "org.apache.commons", and
reverted this change very
soon), but I don't remember the exact problem. Maybe you could ask Brett
Porter or Jason val Zyl.
No relocations involved here.
OK, but it would be good to know what problems may occur if we user
relocation
from commons:commons:commons-dbcp:1.4 to
org.apache.commons:commons-dbcp4:1.4.
I saw such proposals somewhere in this thread.
IMHO the safest and most conservative naming convention would be:
commons-dbcp:commons-dbcp:1.4
commons-dbcp:commons-dbcp:1.3
No, because this would actually make the JDBC4 version available as an
upgrade for the JDBC3 one. This is the scenario we have to avoid.
After a lot of thinking about it, it IS an upgrade for me. If you
upgrade Java to 1.6, you can upgrade
commons-jdbc. If you don't want to upgrade, you can always specify a
version (in your pom or whereever)
you want.
I know you see it differently, but I disagree with you. Sorry.
In this situation JDBC4 version always wins. It means you know what
version will land in your
war file if you have both dependencies in your project and don't specify
your preferred version
in the pom.xml file.
No, if you know what you need, you can adjust the groupId for the JDBC4
version. If your dependencies still contains the other one, you have a
problem anyway.
I'm talking about developers who don't know Maven well, don't know
comons-dbcp version naming
conventions well too, and who will make a lot of errors, wrong
assumptions, and will ask a lot of questions
why something does not work.
This is again from my practice. Everything must be deadly simple.
I don't know commons-dbcp project internals, I'm only using it in my
projects (testing with Spring) and in Tomcat
(production). I think I can see things differently from you - developers
of commons-dbcp project.
Greetings
Grzegorz
- Jörg
---------------------------------------------------------------------
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
