Re: [RFC] Reimagining the artifact and repository-interaction APIs

[Lukas Theussl <lt...@apache.org>]

Hervé BOUTEMY wrote:
> 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

This may not be relevant at all but it just struck me that this is 
actually how it used to be in the maven 1 artifact plugin [1]. Not sure 
what the reason was to separate the two, but there probably was a 
reason, maybe someone remembers.

Otherwise I find this whole discussion pretty useful and forward going, 
thanks in advance to all those who contribute!

-Lukas


[1] http://maven.apache.org/maven-1.x/plugins/artifact/tags.html



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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org