maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Gudian <>
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:23:16 GMT
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?

> 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:

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