2015-12-13 12:05 GMT+01:00 Robert Scholte <[email protected]>: > 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 < > [email protected]>: > > > 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: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
