On Mon, 18 Jul 2016 15:54:24 +0200, Christian Schulte <c...@schulte.it>
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
