maven-dev mailing list archives

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

On 4 Jul 06, at 1:45 PM 4 Jul 06, Steve Loughran wrote:
> In a way, many of the stuff in M2 is experimental; a build tool  
> that effectively encodes beliefs about how a project should be  
> structured and delivered, focusing on component-based development  
> instead of application dev. I also think its time to look at how  
> well some of the experiment is working.

You make it sound like we're some sort of cult :-)

The phrase "encoding beliefs" is an inaccurate description. It's is  
simply the pursuit of best practices for software development and  
those practices are very much mutable, this thread being very good  
evidence of that. We also not only focused on component-oriented  
development, we ourselves develop applications ourselves and we're  
trying to make that coherent as well.

> Personally, I always experience a bit of fear when adding a new  
> dependency to a project. the repository stuff, and estimate a  
> couple of hours to get every addition stable, primarily by building  
> up a good exclusion list.

This is the place to talk about that as people shouldn't be fearful  
adding dependencies. But people who have an ideal setup here they  
completely control the repository they use internally don't have many  
of the problems that people are experiencing in this thread. Having a  
public repository of high quality is not a trivial task.

> Is it worse than before? Better? Or just, well, different? and if  
> things are either worse or not as good as they could be, what can  
> be changed?

The process is absolutely better. The process couple with the public  
infrastructure we have now is problematic. Two very different things.

> One underlying cause seems to be pom quality. Open source software  
> dev is a vast collection of loosely coupled projects, and what we  
> get in the repository in terms of metadata matches this model. Each  
> project produces artifacts that match their immediate needs, with  
> POM files that appear to work at the time of publishing. Maven then  
> caches those and freezes that metadata forever, even if it turns  
> out that the metadata was wrong.  There's far better coherence  
> within Gump, where the metadata is effectively maintained more by  
> the gump team themselves than by the individual projects.

There is absolutely no way this is scalable over time. You are saying  
that a small group of people can maintain metadata for projects that  
they are not intimately involved with? That's like saying that people  
who live outside your community have a better chance at describing  
your community. I really just don't think that's possible. How many  
problems has Gump had over the years trying to maintain the metadata?  
Huge problems, almost never in sync with projects. You basically find  
out when it breaks and go back track most of the time. There is no  
doubt that the same process will happen with Maven where users of  
Maven will eventually make their metadata better but that will take  
time. Gump has been around for 5-6 years now. People are really only  
starting to use Maven 2.x which is closing in on being out for a  
year. I am will to bet in another year a great number of the problems  
seen in this thread will be gone. I would argue that Gump will not  
work precisely because it is not the projects themselves maintaining  
the metadata. Projects using Maven will eventually get it right  
because it provides some value to them to get it right.

> Question is, what to do about it? And if the m2 repository was an  
> attempt to leave the problems of the M1 repository behind, has it  
> worked?

To a large extent I would say we have fixed many of the problems on a  
technical level. Correctly the metadata and educating projects as to  
how best maintain is it is a social problem and a matter of  
education. Couple that with some automated integrity checks that will  
be performed by the repository manager.

> -steve
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Jason van Zyl

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message