Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aether-dev] Pluggable ScopeResolver?

And I mixed up the name … I was talking about the ScopeDeriver, so it should have been a PluggableScopeDeriver

 

Chris

 

Von: aether-dev-bounces@xxxxxxxxxxx [mailto:aether-dev-bounces@xxxxxxxxxxx] Im Auftrag von Christofer Dutz
Gesendet: Sonntag, 19. Oktober 2014 13:06
An: Maven Developers List; aether-dev@xxxxxxxxxxx
Betreff: [aether-dev] Pluggable ScopeResolver?

 

Hi,

 

sorry for cross posting this to the maven and the aether dev-list, but my question is sort of cross-cutting and I don’t quite know where it fits best.

 

I maintain the Flexmojos plugin, a maven plugin for building Apache Flex applications. In this we allways have had some custom scopes for managing how the dependencies are linked.

Ths has worked fine until Maven 3.1. Since then it seems that a ScopeResolver tries to handle out the transitive scopes of transitive artifacts. Now something has changed here. In Flex we have a scope called „rsl“ which tells the compiler to use a runtime-shared-library (sort of dynamic linking against a dll, in contrast to the default that does static linking). While with maven 3.0 my transitive scopes were all „compile“ they are now „runtime“.

 

While tracking down my problem, I noticed all is related to the JavaScopeResolver which seems to be the only implementation of ScopeResolver. Having a look at the code, I think it should be easy to create some sort of PluggableScopeResolver, which defaults to the JavaScopeResolver. This Pluggable version could be used by plugins in need of custom scopes to define the logic for resolving their scope related issues themselves. With a feature like this, Flexmojos could provide a FlexScopeResolver in which I could explicitly define how the different types of scopes should be resolved and I would no longer have to sort of find workarounds to make Maven think this is actually a Java project.

 

I know of several Projects that would probably benefit a great deal of a feature like this (Flexmojos – for building Flex Applications, NPanday – for building C, C++, C#) and to me it wouldn’t look that invasive to Maven.

 

I would gladly contirbute and work on this, if you guys think this would be a good thing to do. Perhaps someone on one of the lists has a reason for this using magic of the dark side of the force, but to me it looks like a sensible Idea … after all, even if Maven is built in Java, I have allways understood it as a not only java tool.

 

Chris


Back to the top