commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [dbcp] 1.3 release packaging - take two
Date Fri, 27 Nov 2009 16:03:42 GMT
Niall Pemberton wrote:
> On Fri, Nov 27, 2009 at 10:45 AM, Jörg Schaible <> wrote:
>> Hi Grzegorz,
>> Grzegorz Słowikowski wrote at Freitag, 27. November 2009 10:45:
>>> Hi Jorg
>>> Jörg Schaible wrote:
>>>> Hi Grzegorz,
>>>> Grzegorz Słowikowski wrote at Freitag, 27. November 2009 09:04:
>> [snip]
>>> 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.
>> For sure, but the causing problem cannot be solved by any build tool. Look
>> at the following situation:
>> X - your project
>> X depends on A and B
>> A depends on dbcp-jdbc3
>> B depends on dbcp-jdbc4
>> Result: Your app is simply broken. It does not matter whether the build tool
>> will place both dbcp jars into a shared library or only one of the jars and
>> this is completely independent of the dbcp jar's names.
> I don't agree its not broken - its a normal situation. In this
> scenario you use DBCP 1.4 and that should work just fine with both
> dependency A and B. In maven terms it will do its normal dependency
> resolution and pick the later DBCP version.

I don't follow this - either the assertion that it will "work" or
that maven will only include 1.4.  IIUC, the "later version"
resolution will only happen if we stick with the same groupId.
Secondly, given the incompatibilities, the A part could blow up if
dbcp 1.4 is used (of course, Jorg's point is that A and B are
already incompatible in this case).


> Niall
>>> 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.
>> The example above *is* the practice and is not Maven specific.
>> [snip]
>>> 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.
>> As explained - it does not matter for the resulting app - it is broken,
>> because it tries to use JDBC3 and JDBC4 at the same time.
>>> 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.
>> If you have both jars in the shared folder you get at least a hint, that
>> something's wrong with your application. The current proposal with:
>> org.apache.commons:commons-dbcp:1.4
>> commons-dbcp:commons-dbcp:1.3
>> will have the effect (at least for Maven builds) that you end up with
>> commons-dbcp-1.3.jar and commons-dbcp-1.4.jar in your classpath and you
>> should realize that this is a no-no.
>> As said, the tool can not resolve the causing problem itself - all it can do
>> is give you a hint. Using a tool is no excuse from thinking yourself. And
>> two jars with same name (except version) is IMHO a better hint, that having
>> simply one without recognizing that A or B is implicitly broken and failing
>> your app.
>> [snip]
>>>>> 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.
>> And - as explained - the groupId will be prepended to the name if
>> {artifactId}-{version} is not unique.
>> [snip]
>>>> 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.
>> Relocation will make it worse, since then you will tell Maven that it is the
>> same artifact in different version - which it is not.
>>>>> 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.
>> Yes, it is an upgrade, but you have to deal with more than just dbcp and a
>> user should realize that his upgrade from JDBC3 to JDBC4 is something that
>> is not backward compatible and has to be supported by all (transitive) deps.
>> [snip]
>>> 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.
>> Actually we have to deal with a situation, where every move will cause a
>> problem for someone. A developer must be aware that switching from Java 5 to
>> Jave 6 also means an (incompatible) upgrade from JDBC 3 to JDBC 4 - at least
>> if he uses JDBC. Either he knows or he must learn - I do not see a way out,
>> unfortunately. And this is completely unrelated with the build tool.
>> - Jörg
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message