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 11:05:17 GMT
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.

For plugins such a change is easy, but within the scope of the pom that's  


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:

View raw message