On Fri, Nov 27, 2009 at 10:45 AM, Jörg Schaible <joerg.schai...@gmx.de> 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.
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: 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
