Am 07/18/16 um 20:39 schrieb Robert Scholte: > On Mon, 18 Jul 2016 15:54:24 +0200, Christian Schulte <[email protected]> > 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: [email protected] For additional commands, e-mail: [email protected]
