FWIW, I've started writing up some thoughts on how to rework the
artifact/repository APIs in a proposal on the wiki:
https://cwiki.apache.org/confluence/display/MAVEN/Artifact+APIs+Rewrite+4
Currently, I'm planning to request two new Git repositories:
maven-artifact-apis
maven-artifact-impls
Each will contain multiple subprojects, but I think they represent
categories of things that would be released together. The challenge here
is to avoid having a million tiny Git repositories, I think. It's a
scenario I find hard to avoid in the code I've got out on Github...
On 4/9/12 5:27 PM, John Casey wrote:
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'
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.
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. 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.
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.
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).
I invite your criticism, ideas, etc.
--
John Casey
Developer, PMC Chair - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
