You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Christofer Dutz <ch...@c-ware.de> on 2016/07/18 13:02:19 UTC
Extending Maven to allow scope resolutions for other languages than
Java
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?
Chris
Re: Extending Maven to allow scope resolutions for other languages
than Java
Posted by Christian Schulte <cs...@schulte.it>.
Am 07/18/16 um 15:54 schrieb Christian Schulte:
> 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,
>
'DependencyGraphTransformer' is declared in 'aether-api'.
'ConflictResolver.ScopeDeriver' etc. are declared in 'aether-util'.
Either we want the extension point based on 'aether-api', or we will add
a new interface to Maven core for delegation. That interface could be
named 'DependencyGraphTransformer' as well but declared somewhere Maven.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Extending Maven to allow scope resolutions for other languages
than Java
Posted by Stephen Connolly <st...@gmail.com>.
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 <ch...@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 <rf...@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 <cs...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
AW: Extending Maven to allow scope resolutions for other languages
than Java
Posted by Christofer Dutz <ch...@c-ware.de>.
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 <rf...@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 <cs...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
AW: Extending Maven to allow scope resolutions for other languages
than Java
Posted by Christofer Dutz <ch...@c-ware.de>.
So am I correct, that in order to do what I would like to, I simply have to wait for a while?
If not I'd be happy for some pointers.
Chris
________________________________
Von: Christian Schulte <cs...@schulte.it>
Gesendet: Dienstag, 19. Juli 2016 23:48:04
An: Maven Developers List
Betreff: Re: Extending Maven to allow scope resolutions for other languages than Java
Am 07/18/16 um 20:39 schrieb Robert Scholte:
> On Mon, 18 Jul 2016 15:54:24 +0200, Christian Schulte <cs...@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.
+1
And I am all for adding an interface allowing to resolve artifacts based
on something I currently don't now how to name.
Set|Tree|Node|what?<Artifact> resolveArtifacts(Object|String|what?
classpath|identifier|target|main|test|app|what?);
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Extending Maven to allow scope resolutions for other languages
than Java
Posted by Christian Schulte <cs...@schulte.it>.
Am 07/18/16 um 20:39 schrieb Robert Scholte:
> On Mon, 18 Jul 2016 15:54:24 +0200, Christian Schulte <cs...@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.
+1
And I am all for adding an interface allowing to resolve artifacts based
on something I currently don't now how to name.
Set|Tree|Node|what?<Artifact> resolveArtifacts(Object|String|what?
classpath|identifier|target|main|test|app|what?);
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Extending Maven to allow scope resolutions for other languages
than Java
Posted by Robert Scholte <rf...@apache.org>.
On Mon, 18 Jul 2016 15:54:24 +0200, Christian Schulte <cs...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Extending Maven to allow scope resolutions for other languages
than Java
Posted by Christian Schulte <cs...@schulte.it>.
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,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org