maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: I wish we had a way to declare a dependency that wouldn't participate in the classpath
Date Sun, 13 Dec 2015 21:53:45 GMT
On Sun, Dec 13, 2015 at 3:59 PM, Robert Scholte <rfscholte@apache.org> wrote:
> Op Sun, 13 Dec 2015 21:23:16 +0100 schreef Andreas Gudian
> <andreas.gudian@gmail.com>:
>
>
>> 2015-12-13 12:05 GMT+01:00 Robert Scholte <rfscholte@apache.org>:
>>
>>> The first time I heard about JDK9s Jigsaw having a classpath and a
>>> modulepath, which can be used at the same time AND both containing jars,
>>> I
>>> had a big "OH NO....!". We can't change the pom, so the first thing that
>>> came to my mind was indeed using the scope for this. But that'll have a
>>> huge impact: if jars need to be used at compile time but don't have that
>>> scope, what will happen with transitive resolution for example?
>>> I had a small talk with Alan, Mark and Alexander of the Jigsaw team about
>>> this. You could say that this is a new specification of a jar which asks
>>> for a different file-extension. They said that the jar file specification
>>> was extended. I said that we can't expect from users to know what kind of
>>> jar it is. Also, buildtools shouldn't pay the price for analyzing the jar
>>> to discover if it has a module-info or not. Mark immediately answered
>>> that
>>> they should take care of it.
>>> Now that I'm working on the maven-compiler-plugin it looks like it won't
>>> be a compile time issue. However, depending on our approach it might be
>>> an
>>> issue for Surefire.
>>> So yes: I recognize the situation. Dependencies are all very classpath
>>> oriented assuming that a specific type is always used in the same way.
>>>
>>> That's why I want to drop the strict scopes for plugins. Best example is
>>> the maven-javadoc-plugin where you can add jars for bootclasspath,
>>> doclets,
>>> resources, taglets. My idea: don't add these dependencies as
>>> configuration
>>> elements, but as standard plugin dependencies with there own scope. And
>>> since there dependencies are specific for this plugin, it can choose any
>>> scope it likes and select them within its own Mojo code.
>>>
>>
>> But I would guess such specially scoped dependencies still show up on the
>> classpath of the plugin itself, right? For example, right now I'm looking
>> into MCOMPILE-203 which is about configuring the -processorpath option of
>> javac. Right now I have it working locally with a new
>> configuration-element. Using a special scope in the plugin-dependency
>> would, currently, mean polluting the plugins classpath - which wouldn't be
>> that ideal.
>>
>> Or are plugin-dependencies with funky scopes already filtered out right
>> now?
>>
>
> I would expect that for plugins only the compile and runtime scoped
> dependencies are used as their whitelist.
> Not sure what will happen with unknown scopes, but it it works then it is
> quite hard to get those dependencies (maybe including their transitive ones)
> IMO it is Maven which is responsible for resolving dependencies, and not the
> plugin with its own configuration.

The idea that I would write in a JIRA, if it passed a certain level of
plausibility-testing here, is this:

When the compile plugin and the surefire plugin (main examples) are
building classpaths, they should prune at type!=jar. No change to the
dependency tree, only to the management of classpaths by the plugins
that, well, manage classpaths. They could have options to change this
behavior in case someone really wants a war file in the classpath for
some reason, but that should not be default behavior. No need, in this
schema, to add a scope.


>
> Robert
>
>
>>>
>>> For plugins such a change is easy, but within the scope of the pom that's
>>> hard.
>>>
>>> Robert
>>>
>>>
>>> Op Sat, 12 Dec 2015 22:04:47 +0100 schreef Benson Margulies <
>>> bimargulies@gmail.com>:
>>>
>>>
>>> Sometimes, we want to declare a dependency without changing a classpath.
>>>>
>>>>
>>>> Project A builds an OSGi bundle and a Karaf feature (classifier
>>>> 'feature', type 'xml').
>>>>
>>>> Project B wants to consume the feature. it wants to declare the
>>>> feature descriptor as a dependency, to (a) ensure reactor order, and
>>>> (b) make the dependency information available to plugins.
>>>>
>>>> But it does _not_ want A's OSGi bundle and it's dependencies in the
>>>> classpath.
>>>>
>>>> The only way out is to exclude them, one-by-one. And when someone adds
>>>> a dependency to A, you have to maintain the exclusion list.
>>>>
>>>> Another example is the tomcat plugin: it needs wars as dependencies,
>>>> and similarly it needs to avoid having their dependencies in the
>>>> classpath.
>>>>
>>>> To me, this calls out for another scope.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

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


Mime
View raw message