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
hard.
Robert
Op Sat, 12 Dec 2015 22:04:47 +0100 schreef Benson Margulies
<bimargul...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
