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: [email protected] For additional commands, e-mail: [email protected]
