maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: [RANT] This Maven thing is killing us....
Date Mon, 03 Jul 2006 12:22:22 GMT
Edwin Punzalan wrote:
> May I add, that when maven already downloaded a poor/invalid pom, even 
> after fixing the pom in the repository, maven won't know that it's 
> changed (unless the version changed) and it will not download it.  So 
> you end up still using your local repo copy.
> To re-download a pom, you have to delete your local copy first.
> This is a good solution though:

A complete forced rebuild is a bit of an opt out, but if you are using 
http then you can do  if-modified-since. Stuff in ftp and filesystems 
are different, but you could always do a checksum poll. After all, the 
stuff in the local cache is just that, a cache.

Maybe you need a revocation mechanism, in which repositories can not 
only publish stuff, they can revoke things. I'm not so sure about this, 
as it would complicate stuff.

The big issue is just pom quality. I've heard the blame put on projects 
that dont actually use maven, but I dont think that is the real problem. 
Its more that the artifact set needed to build something and the 
artifact set needed to use something are often different. Developers 
seem to stop after creating a pom that can build, even if that includes 
stuff that isnt needed. Possibly this is just ignorance; unless they see 
the complete list of dependencies, it isnt obvious what really is being 
pulled in. It can also be that if you explicitly ask for something like 
junit3.8.1 in test scope, you dont notice that something else is pushing 
junit3.7 in the runtime scope, but someone downstream who uses your 
stuff may find out that junit3.7 is creeping in via accidental 
transitive dependencies.

It would be very interesting to do a post-mortem of how well the 
transitive development stuff is working. Really. This is not an critique 
of what's been done, but a proposal to do reviews/interviews and a paper 
that would be of a grade you could present at any tier-1 software 
engineering conference, something like "Dependency management in 
community software development, lessons from the field"

-review of design goals of M1 and M2 repos, intro concepts of 
projects/artifacts, dependency lists, snapshots and version logic.
-interview people who worked with m2 as end user projects (cocoon, geronimo)
-open up the debate on whether transitive dependency is a good thing or not
-worry about security implications and explore vulnerabilities

-look at other users  of the repository (ivy, smartfrog) and what they 
do differently.
-look at alternatives and see whether they are better or worse
	-.NET strong versions that use MD5 hashes to bind; (secure, good in 
production, not in dev, no way to tell which version is older)
  	-GGF application repository service (hasnt really realised what the 
problems are yet)
	-Java repository stuff in that JCP w.g
	-RPM/APT repositories, esp, JPackage packaged java artifacts
Make some serious suggestions about how to fix it, both process-wise and 

I'm kind of busy right now, so am not offering to do this, not until, 
say, September. But otherwise, it would be a really interesting thing to 
work on.  Anyone interesting in co-authoring?


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

View raw message