commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <joerg.schai...@gmx.de>
Subject Re: [dbcp] 1.3 release packaging - take two
Date Fri, 27 Nov 2009 10:45:51 GMT
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 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message