maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <ja...@maven.org>
Subject Re: [RANT] This Maven thing is killing us....
Date Tue, 04 Jul 2006 17:33:46 GMT

On 4 Jul 06, at 2:37 PM 4 Jul 06, Steve Loughran wrote:

> Carlos Sanchez wrote:
>> The repository is as good as the users/projects make it. There's no
>> difference at all with using ant and including the wrong jars, maybe
>> the problem is that how to fix it in maven is not as easy as in ant.
>> If project A says it depends on B 1.0 and C says it depends on B 1.1,
>> there's a conflict in Maven, Ant and anything you want to use, the
>> difference is that Maven tries to do it for you, but you still can
>> override that behaviour.
>
>
> It seems to me that the difference in ant, the duty to set up your  
> classpath belongs to the project alone, so you, the build.xml  
> author are the only one who can make a mess of your CP.

This also means that you are the only one who can help create a  
correct classpath.

>
> However, on any system with transitive dependencies, you are ceding  
> control of your classpath to other programs out there.

No, you are ceding control of the dependency chain to the projects  
which you are depending on.

> Even if you think you know exactly what the dependency graph of  
> your app is, an update to a new version of any your dependencies  
> can pull in new metadata, with a new set of dependencies, and  
> potentially a new classpath.

So how is that different then with Ant when you try a new version of  
a dependency? You're going to have to go hunt down the dependencies  
or copy in a new set of dependencies provided by that project. It  
doesn't matter what you use to build if you change a dependency you  
are subject to change.

>
> This is not a maven-specific problem; anything that supports  
> transitive dependency logic can suffer from it. Gump and Ivy could,  
> though in both cases the descriptors tend to be hand-written tuned  
> to not exhibit the problem. (in gump most projects dont export  
> dependencies, as the default is compile-time-only).
>

Ok, I agree this is not a Maven specific problem.

You cannot maintain metadata for a growing number of projects and you  
can't stay on top of projects changing all the time except in  
reaction of problems. The projects themselves must provide useful  
metadata and it is of value to them to do so.

> > Right now we are in a good position with a huge number of users  
> trying
> > and testing the metadata in the repository, and forcing projects to
> > support maven by providing good data.
>
> That still assumes that transitive dependencies are a good thing,  
> and that perfect metadata is achievable. I'm not sure about either  
> of those. I also think they're straying dangerously close to one of  
> the big software engineering tar-pits: versioning.
>

Transitive dependencies in the state they are in now can be  
problematic. What can be done to fix this? The repository manager  
running integrity checks, some visualization tools to help people see  
the chains easily, and visualization tools to help detect conflicts.  
For both of these things IDE integration will be key to making this  
easy for users. Big challenges, and not trivial but certainly not  
untenable. The metadata will never be perfect but right now I still  
think it's far from being ideal because we have no real active  
process of improving it on a large scale. Carlos puts in a _lot_ of  
time trying to correct things and absorb changes submitted for  
improvement but as mentioned in the previous message it's a matter of  
education and automated tools running to point people in the right  
direction.

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

Jason van Zyl
jason@maven.org




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


Mime
View raw message