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]
