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
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
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
