The code for the project formerly known as Aether is being migrated to Maven as the Eclipse Aether project has been retired.
Ideally we do not want to expose the code known as Aether to plugins, so we will probably expose APIs targeted for the use-cases of Maven plugins... We were somewhat hampered until we got guidance from the Eclipse Foundation as to some issues around the transition of the code. Most of those seem to be being resolved, so hopefully we can get some momentum going again. -Stephen On 19 July 2016 at 07:36, Christofer Dutz <christofer.d...@c-ware.de> wrote: > Hi Guys, > > > thanks for that feedback ... I know my implementation was sort of ugly, > but I tried to keep it as simple as possilbe as it seemed that the Eclipse > Aether project didn't work on Aether for quite some time (Don't know if > it's simply "finished" or if it's now maintained elsewhere). My option was > a simple way to be able to extend this without having to change anything in > Aether. But if there's a better, simpler, cleaner way ... I'd be more than > happy to use that. > > > I have to admit that I'm still getting used to the internals of mavens DI > mechanisms, so please forgive a mabe stupid question: > > - I can see the DependencyGraphTransformer interface in Aether-API, can I > already use this in Maven? I didn't quite understand if you said "it's > coming" or "it's new but you can use it" ;-) > > - If it's already there, how can I use it? Do I only have to provide an > implementation of that? How do I tell Maven to use it (I'd really like to > know if there is a way to inject custom versions of default services and > have them used instead of the "Default" versions). > > - If it's not there, what can I do to make it happen as soon as possible? > > > And Robert, I haven't forgotten about MPLUGIN-302 ... I'm still on it ... > but for me it is very tightly coupled with this thing here ;-) > > > Chris > > > > ________________________________ > Von: Robert Scholte <rfscho...@apache.org> > Gesendet: Montag, 18. Juli 2016 20:39:58 > An: Maven Developers List > Betreff: Re: Extending Maven to allow scope resolutions for other > languages than Java > > On Mon, 18 Jul 2016 15:54:24 +0200, Christian Schulte <c...@schulte.it> > wrote: > > > Am 07/18/16 um 15:02 schrieb Christofer Dutz: > >> Hi, > >> > >> > >> Unfortuantely I wrote this down as a Jira ticket, but it seems it > >> wasn't created in the end so I'll post this via Email ;-) > >> > >> > >> I am currently working on clean support for Apache Flex build with > >> Maven. Prior to 3.3.1 non-java builds were sort of relying on a > >> scope-resolution bug that was fixed in newer version. Now non-default > >> scopes can no longer have transitive dependencies. In order to fix > >> this, I did a little refactoring of the scope resolution code in > >> MavenRepositorySystemUtils.newSession(). > >> > >> > >> The idea is to wrap together the language-dependent parts of the scope > >> resolution and have these automatically injected into > >> DefaultRepositorySystemFactory. Per default there would only be one > >> instance (JavaLanguageSupport) available. But I could provide other > >> LanguageSupport implementations for other languages via Maven > >> extensions. > >> > >> > >> I implemented this as a POC. I didn't find my changes breaking anything > >> in the maven test-suite and I was able to add my FlexJsLanguageSupport > >> to maven and have it called for scope resolution requests. > >> > >> > >> I just pushed a commit to my maven fork: > >> > >> > https://github.com/chrisdutz/maven/commit/cd205837540c3df74ad4a8eb8b6c710a93cff156 > >> > >> And here ist the FlexJS counterpart: > >> > >> > https://git1-us-west.apache.org/repos/asf?p=flex-falcon.git;a=commit;h=aea14be67db2b28b766d274d900ce076fdb8522b > >> > >> > >> Does it make sense to invest more time into this feature, or is this > >> road a dead-end? > >> > > > > Instead of adding that 'LanguageSupport' interface, I would go for > > injecting the 'DependencyGraphTransformer' to use directly. No need for > > a new interface. So that a customized 'ConflictResolver' can be injected > > you can setup the way you want. Makes things like your > > 'MultiLanguageScopeDeriver' part of your extension instead of Maven > > core. I think some kind of 'DependencyGraphTransformer' extension point > > will be provided in 3.5. Maybe there will be more than just one > > transformer for the various classpaths. We currently resolve the project > > artifacts once and then make Maven build the classpaths based on those > > artifacts. In 3.5 this may be enhanced to provide various artifact > > resolution strategies based on the classpath to build. So that > > 'MavenProject.getCompileClasspathElements' may provide different > > artifacts than 'MavenProject.getTestClasspathElements'. Nothing concrete > > yet. > > > > Regards, > > I'd like to deprecate both MavenProject.getClasspathElements and > MavenProject.getTestClasspathElements. These are too tightly bound to > Java, whereas Maven should be language independent. > Yes, I thought of language extensions too, but with the new visions > regarding scopes it might not be necessary anymore. > > Robert > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
