Transitive deps was: Jigsaw prototype, take 2

[Jaroslav Tulach]

Dne St 4. září 2013 19:50:34, David M. Lloyd napsal(a):
> * Transitive-by-default causes problems in mid to large projects due to
> extensive conflicts [can't find the discussion...]; 

We run into this all the time. Just recently I was trying to use maven-antrun-
plugin which depends on (and exposes) Ant 1.7.1 while using features of Ant 
1.8. Conflicts everywhere. Resolution fragile. But it seems to run at the end.

> fix is to use and
> verify exclusions, specify "provided" scope, 

Provided scope is good for "compile only dependency" - e.g. one that is not 
used during runtime. I use it for APIs with annotation processors that just 
generate something and are no longer needed during runtime.

However I've noticed that grizzly used the "provided" scope for optional 
runtime dependency. E.g. I could use grizzly-http-server, and add in optional 
support for websockets - but it was a nightmare to find out all the JARs that 
were needed (like javax.servlet-3.0 API) and I got a lot for 
NoClassDefFoundErrors before I collected them all. I double this is a practice 
to follow.

> and use
> maven-enforcer-plugin [5] to ban transitive dependencies

That might work. Explicitly specify what you compile against is a good idea. 
NetBeans Platform (Ant based) build system is using it for a decade (after 
switching from the previously transitive mode) and there are no problems with 
it as far as I can tell.

> * range dependencies can cause resolution
> to be NP-complete; best practice is to use ranges in a more restricted
> manner [6]

Thanks for the quote. Btw. the article's final suggestion is somewhat similar 
to what the maven-enforcer-plugin does. The write up suggest to record the 
exact versions of libraries we compile against - either specified directly as a 
compile dependency, or inferred by the compiler for the (hidden) transitive 
ones.
-jt

> [6] http://wiki.apidesign.org/wiki/RangeDependenciesAnalysed