maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Casey <jdca...@commonjava.org>
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:

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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message