maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: [RANT] This Maven thing is killing us....
Date Thu, 06 Jul 2006 09:18:05 GMT
jerome lacoste wrote:
> On 7/5/06, Steve Loughran <stevel@apache.org> wrote:
>> Ralph Goers wrote:
>> >
>> >
>> > Carlos Sanchez wrote:
>> >>
>> >> Yes you can, it's not the best way to do it but you can, by adding
>> >> explicitly the dependency with the versoin you want to your pom. In
>> >> the very worst case you have to add all transitive deendencies to your
>> >> pom, like in Maven 1.
> 
> 
> [..]
> 
> I've been following this thread with interest.

Its an interesting discussion. Although the topic is how maven builds, 
the underlying issue is how to do late binding to library versions 
without things breaking...its one aspect of the whole 
configuration-management problem.

> It makes me think of the various problems Linux distribution have to
> deal with when making their own repositories. It took 10 years for
> these solutions to be what they are today. I really think some ideas
> should be reused, even though the goals are slightly different.

I need to research these more. One issue I have with the linux world is 
that they tend to require that a system only has a single version of a 
package installed on a machine; they dont really support side-by-side 
stuff. So if you install jdk-1.4.2 and lib-gtk-2.0.4 then you are 
expected to uninstall jdk-1.4.0 and lib-gtk-2.0.3. In java, excluding 
stuff in the JVM/JRE itself, and that endorsed directory mistake, you 
can have any number of JARs around and each process gets to choose the 
entire set of libraries to depend on.

Except of course if you use the sun manifest.mf way of specifying 
dependencies, that just sucks, because you have to hard code in a 
relative/absolute path to every JAR in the JAR file itself.


> Some features/ways of working that may or may not be applicable:
> 
> - they typically use a versionning similar to x.y.z-n sometimes
> adding. -n can be used to fix packaging issues (POM in the case of
> maven). Vendor fixes are also accepted and version names reflect the
> vendor name.
> 
> - the distributions with the best repositories typically require the
> package to be buildable from source. The build is tested in a separate
> environment where all the required build dependencies are listed, to
> make sure that the dependency list is accepted. Something similar
> should maybe be done before accepting a project on a POM, setting up a
> build environment based on the given pom.
> 
> - number of versions of a particular package in a repo is reduced to a
> minimum. users are adviced to upgrade to the latest & greatest to make
> sure that fixes are always present in the last released versions

I could make some negative comments about linux backwards compatibility 
here.

One person's bug fix is another person's "unexpected change in system 
behaviour". This is why on qualified systems, you dont change 
*anything*, if you can help it, even OS security patches are carefully 
assessed before rollout.

> 
> - responsibilities of preparing packages is spread around 10s of
> people. Packages are orphaned when no one is taking care of them.
> People can reuse tricks/scripts learned by former packagers to go on
> with the job.

yes, there is a good spread of participants. and the distros take on the 
job of integrating everything.

-steve

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message