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: http://jira.codehaus.org/browse/MNG-1258
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
-CPAN
-RPM/APT repositories, esp, JPackage packaged java artifacts
Make some serious suggestions about how to fix it, both process-wise and
technologically.
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?
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
