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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
