Niclas Hedhman <[EMAIL PROTECTED]> writes:
>That means that we will be able to declare in the Gump descriptor that abc.jar
>is used for an def-x.y.z.jar by Maven (and others), so that in the overrides
>file,
>maven.jar.override = on
>maven.jar.abc = /usr/local/...../javamail/mail.jar
Could you please explain what this means exactly for a project?
Does it that mean, that I cannot rely whether the projects are run by
the Gump with the jar versions that have been specified in
project.xml?
How does that scale? Consider changes like commons-collections 3.0
vs. 3.1 or commons-lang changes? Or commons-configuration rc1 vs. rc2
What significance has a continous integration test if it does not test
the environment specified for the application?
>is generated. This will solve all projects with a similar situation and
>allowing all the existing ant-wrappers for Maven projects to go away.
This introduces just another layer of "gotchas" The whole override
shebang was a really bad idea when Jason introduced it into maven and
it hasn't improved a bit yet. Sort of "bolted on to scratch an itch".
If I want to test vs. javamail-1.3.1.jar or torque-3.1.1-rc3.jar then
I do want against this jar. Not against some dependency that Gump
decide to swap for "javamail-1.3.jar" or "torque-3.1.jar". This simply
makes no sense to me.
One of the few really good things that Jason did when building the
artifact code is, that he forced jars to have a version. It was a
really stupid idea from Sun to release "mail.jar". Even mail-1.3.1.jar
would have been better. Renaming sthese jars is IMHO a good thing that
maven has enforced.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
"Fighting for one's political stand is an honorable action, but re-
fusing to acknowledge that there might be weaknesses in one's
position - in order to identify them so that they can be remedied -
is a large enough problem with the Open Source movement that it
deserves to be on this list of the top five problems."
-- Michelle Levesque, "Fundamental Issues with
Open Source Software Development"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
