Niclas Hedhman <[EMAIL PROTECTED]> writes:
>On Wednesday 20 October 2004 18:07, Henning P. Schmiedehausen wrote:
>> 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?
><snip content="elaboration" />
>This is probably a very interesting observation, which has to do about the
>purpose of Gump.
>Gump does not exist to make sure your system/project work. That is your own
>responsibility.
>Gump's purpose is to ensure that a source code change YOU (in anonymous sense)
>make doesn't aversely affect someone else, and if it does it should be
>captured and everyone involved should be notified about it ASAP, before any
>releases are being made.
>That means that building against the declared versions are not an option. That
>doesn't provide a solution to the purpose. We need to build against either
>the latest known sources, and for generational shifts (i.e. compatibility is
>not maintained) we have to introduce separate projects for them, and in many
>cases both generations will be maintained by those projects over a limited
>period of time, e.g. tomcat.
>I hope this clarifies why it is not in Gump's interest to use the versions
>(generations, yes, not versions) that you declare for your project, but the
>"latest/greatest" non-released stuff.
Hi,
thanks for clarification. It still makes no sense to me. This assumes
that every project is always interested to be able to build against
the latest and greatest sources of every dependency.
Or did I get your explanation wrong?
Why should building against latest and greatest sources be of any
interest to a project?
Most important IMHO is that a project builds vs. its defined set of
dependencies. If we need a method from "foo-1.0" to build "bar" which
gets deprecated in "foo-1.1" and removed in "foo-2.0"; building "bar"
in Gump will suddently no longer work. Which would for me (as a "bar"
author) not important, because we told our users that "if you want to
use bar, use "foo-1.0"". Who would you blame? The "foo" author for
doing changes in his project or the "bar" for not tracking the latest
and greatest "foo"? What if the "bar" author does not agree to changes
in "foo"?
That "build against latest and greatest" led to the -SNAPSHOT mess in
current maven.
I think that Gump sets a policy here that at least I do feel
uncomfortable with.
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]
