Transitive deps was: Jigsaw prototype, take 2

[Neil Bartlett]

On Thu, Sep 5, 2013 at 8:26 AM, Jaroslav Tulach
<jaroslav.tulach at oracle.com> wrote:
> 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.

I continue to believe that the root of this problem is that the Maven
dependency model cannot work for runtime dependencies. "Whole module"
dependencies such as used in Maven, in previous Jigsaw/JSR277
prototypes, and in OSGi's discouraged Require-Bundle instruction
always lead to excessive fanout and version clashes.

>
>> * 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.

Although David quoted you in the context of OSGi resolution, your
article is not really considered OSGi best practice. In fact we do use
wide ranges according to the rules of Semantic Versioning[1]. While
NP-complete resolutions can technically occur, the problem rarely
arises in realistic scenarios -- if they do ever occur then the
solution is to narrow the search space and/or pre-resolve and persist
the resolution state.

However, I really feel there is no point in rehashing all these
arguments yet again, since we don't have a clue about the requirements
of the rebooted Jigsaw project other than Mark's vague implication
that it will be "simpler". Oracle needs to clarify the purpose and
goals of the project before any progress can be made.

[1] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf

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