Hello, Great idea(s), I can try help and work with you on that regarding api etc..
Regarding scm buzzing/trolling stuff :-), why not asking a git repo only for that ? (Yup due to poor submodules handling in git moving to git can/will be a management nightmare IMHO) 2012/4/9 John Casey <[email protected]>: > 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] > -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
