I'm a little late, but needed time to think more on my comments :)
Le lundi 9 avril 2012 17:27:09 John Casey a écrit :
Hi all,
I finally have some cycles free to work on Maven, and I'd like to spend
some time thinking about how we might tackle some of the bigger-picture
things.
Personally, the first thing I'd like to see tackled is Maven's
relationship to both Artifacts and the Repository system. IMO, these
should be separate API artifacts with each having its own release cycle.
The reasoning is that the APIs should be a contract with third parties
(plugin devs, repository connector devs, etc.). The reasoning for
separating them is that I believe what we do with Artifacts in Maven is
largely orthogonal to the ways in which we interact with the repository
system.
I think we need to reimagine the way Maven interacts with the repository
system (currently, I'm thinking of calling this the
maven-artifact-portal system, unless something less lame comes
along...it's bidirectional, so -fetcher, -retriever, etc. are out).
I'd like to go all the way to refactoring the verbs given to these
interactions:
- 'resolve' -> 'resolve' (Ok, that one's intuitive IMO)
- 'deploy' -> 'publish'
- 'install' -> 'cache'
+1 for the verbs
and perhaps we should not have separate install and deploy plugins but a
unique "artifact" plugin with these verbs: the plugin name probably needs more
ideas
Then, I'd like to turn the notion of a LocalRepository into an on-disk
cache, whose storage format doesn't matter to the user, and which is
manageable as such (flushing the cache, both in targeted and global
fashion for instance). I'd also like to refactor the design to allow
wholesale swapping of the repository system to a completely different
architecture, or just swapping out parts (like the caching component),
or even just adding in new connectors the way we can now.
That's one consequence of the new verbs: we won't "install to a local
repository", which is misleading but "cache on disk". The "repository" term
for the local cache has always been something misleading.
This urge to refactor of the repository system is something I haven't
been able to get out of my head since the last time I gave up working on
the decentralized maven repository code. That routing code would work
fine, EXCEPT there's no place to plug it in. Part of the reason is that
Maven resolves from locations that are specified on the scale of entire
repositories, not on the scale of individual artifacts. Switching to an
artifact-centric routing mechanism requires modification of dozens of
classes.
We could change all this, EXCEPT the most of those classes now reside in
Aether, and that means convincing the powers that be over there that
this is a worthwhile effort...probably not an easy thing. This exercise
has convinced me that Maven needs to insulate itself in order to remain
flexible and able to adapt to its evolving needs.
Beyond the issues related to resolving artifacts, I'd like to make the
depgraph more of a first-class citizen, so Maven components can query it
for paths to a given artifact, along with other information.
+1
what about updating shared/maven-dependency-tree to have a Maven 3 compatible
version?
I'd also
like to build better support for pluggable versioning schemes (even if
it's just for sorting versions), then make sure those schemes are
actually selectable in some way.
I'm skeptical, even twice skeptical:
1. is it useful? what verison numbers comparison is not good actually? Do you
have an example?
2. can it be usable? I can't imagine a place to configure the choice of scheme
that would be usable. Something at groupId level? But certainly not at
artifact level, which is the only place that we could do at the moment AFAIK.
Sure, this is a lot of work. I don't expect it to be done anytime soon,
particularly if I'm the only one working on it, and only when I'm not
working $dayjob or tending to Henry. But these problems are part of
what's been depressing my enthusiasm for Maven in recent months, and I'd
like to see them fixed.
+1 to try and fix things, and +1000 to not work alone
I'm looking into the SCM stuff for this work; currently, I'm tentatively
planning to work out on GitHub, but maybe there's a way to use Git @ASF
for this, since it'll be a few new subprojects in Maven. I'm not sure
yet. I'm going to try like hell to avoid having to work with SVN
(directly, at least).
Git support at ASF should be sufficient by now to ask for it instead of using
not connected github
I invite your criticism, ideas, etc.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
