The rationale for runtime modularization

[Rafael Winterhalter]

Dependency exlcusion in Maven implies that the a dependency is excluded
from any created artifact, for example a war file that stores all
dependencies in its lib folder. This would cause the application to
malfunction at runtime because the used library internally depends on the
now excluded code. As far as I know, Maven has no means of excluding a
transitive dependency only at compile time. Dependency exclusion is mainly
used to avoid that the transitive code breaks a project; for example when a
dependency includes a specific implementation of slf4j which is substituted
by a different version. (
https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
)

Best regards, Rafael

2015-12-04 11:43 GMT+01:00 Jochen Theodorou <blackdrag at gmx.org>:

>
>
> > Gesendet: Freitag, 04. Dezember 2015 um 10:43 Uhr
> [...]
> > Here is however one point I disagree with: Maven does not offer
> > compile-time moduarization. Maven only assures that all dependencies are
> in
> > scope but it does not offer any means to cut down this dependency tree to
> > the set of classes that a user intends to include.
>
> Now I am not a maven guy at all and I could be wrong here, but on a
> dependency level there would be excludes. It is of course not as
> comfortable as what jigsaw has in stock for your scenario and the usage to
> do what you wants would I think be a bit non-intentional... but "does not
> offer any means" seems not to be right to me. Since maven 3.2.1 there is
> also the option to exclude all transitive dependencies. I personally find
> that being the best version at compile time.
>
> > Just as an example: my
> > current work assignment declares a dependency on a framework that defines
> > 107 classes. This framework declares (transitive) dependencies that
> result
> > in a total of 7681 classes becoming visible by including this library as
> a
> > dependency. Relevant for the project (the "non-internal API") are however
> > only six classes. Without Jigsaw, this results in a 1200% overhead of
> > visible classes that can now accidentally be used in my project (via this
> > single dependency out of many).
>
> so normally you would make two jars out of this, one as the main jar, the
> other as transitive dependency. But this will most likely not work in
> jigsaw, because of the split package problem.
>
> [...]
> > Despite, if I wanted to offer modularization for my library which is
> > currently compiled to Java 6, I would still be in trouble.
>
> If I think of split packages again, you can be in trouble even if you do
> intend to ignore modularization.
>
> bye Jochen
>