maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject AW: Making Maven extendable for non standard scopes
Date Wed, 14 Sep 2016 07:11:37 GMT
Hi Robert,


Well I guess MPLUGIN-302 is about extending Maven to allow easy injection of dependencies
of a given scope into a plugin. This would help use scopes in plugins. But I didn't interpret
it as dealing with extending Maven to support other scopes in general. The way I understood
it, it wouldn't help me get "rsl" scoped libraries as Maven doesn't know how to resolve these.
If however I used scope "compile" I would get all compile scoped dependencies.


So for me MPLUGIN-302 is a very useful utility goodie, if Maven supported custom scopes.


I was thinking that from my point of view custom scope resolution would sort of be tightly
coupled to the packaging of an artifact. So wouldn't the plugin-descriptor be a good place
to declare such an extension?


I double checked and noticed that I am currently running my Builds with 3.4-SNAPSHOT and I
couldn't confirm the non-default scopes causing errors. So I guess this was a misunderstanding
on my side.


Chris

________________________________
Von: Robert Scholte <rfscholte@apache.org>
Gesendet: Dienstag, 13. September 2016 22:15:22
An: Maven Developers List
Betreff: Re: Making Maven extendable for non standard scopes

On Tue, 13 Sep 2016 09:34:38 +0200, Christofer Dutz
<christofer.dutz@c-ware.de> wrote:

> Hi,
>
>
> I know there are several discussions underway in the context of pom 4.1
> and alike. The problem with this is however that it was impossible for
> me to follow those threads without putting my paid-work on hold ... a
> short summary of the current state would probably be a good Idea to get
> people back on board ;-)
>
>
> Last week I had a personal chat with Karl Heinz Marbaise at the
> Solutions.Hamburg conference.
>
> The thing is that in Maven a lot of things have been "fixed" recently. I
> put this in double quotes, because they have been fixed from a pure Java
> point of view, but have broken things for non Java projects. For example
> the Flex project had been relying on a "bug" in the resolver that used
> to treat the scopes of unknown types as "compile", for a while they have
> been treated as "runtime" (which strips out transitive dependencies).
> After that injecting project dependencies at runtime by a plugin seem to
> have been prohibited. Karl Heinz even mentioned non default scopes no
> longer producing warnings, but hard errors now (I can't confirm this as
> the new FlexJS Maven build is using these and I have been building this
> using Maven 3.4-SNAPSHOT for quite some time). If this is a future plan,
> this would break even more ... actually this would completely kill the
> ability to build anything with Flex.

Non-default scopes will cause errors? If that's true, I really need to
have a look at this. I would like to drop strict scopes and give plugins
the freedom to select their own scopes from the pom. Maybe the scopes must
be defined by the packaging plugin, that's something worth investigating.

You've already responded to MPLUGIN-302, what's the difference in this
story?

thanks,
Robert


>
>
> Now my suggestion was, as soon as Aether is fully integrated into
> Apache, to create some sort of extension point, in which projects could
> inject some sort of "ScopeProvider". So Maven would work with the normal
> scopes and break with any non-default ones, but using a plugin or a
> maven extension I could add additional scopes to Maven, where each new
> scope would probably need some sort of "ScopeResolver", which would then
> handle the resolving for that particular scope.
>
>
> I guess this would not only help the Flex project, but could help get a
> lot of the JS projects back, which seem to be moving to other build
> systems such as NPM, SBT, ... more and more.
>
>
> If there is anything I could do to help make this happen, please just
> guide me in the right direction and I'll get to it.
>
>
> Chris

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message