maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Casey <>
Subject Re: [RFC] Reimagining the artifact and repository-interaction APIs
Date Fri, 13 Apr 2012 19:39:10 GMT
FWIW, I've started writing up some thoughts on how to rework the 
artifact/repository APIs in a proposal on the wiki:

Currently, I'm planning to request two new Git repositories:


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
>'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 (

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

View raw message