maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte" <>
Subject Re: I wish we had a way to declare a dependency that wouldn't participate in the classpath
Date Sun, 13 Dec 2015 20:59:26 GMT
Op Sun, 13 Dec 2015 21:23:16 +0100 schreef Andreas Gudian  

> 2015-12-13 12:05 GMT+01:00 Robert Scholte <>:
>> 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  
IMO it is Maven which is responsible for resolving dependencies, and not  
the plugin with its own configuration.


>> 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 <
>> 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:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message