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