Hi Robert,
On 10/16/2016 08:52 PM, Robert Scholte wrote:
Hi,
with the introduction of the module-info something interesting is
happening. Up until now the scope of a Java project was limited to the
compilation of the classes. In case of Maven the end-user was in full
control regarding the classpath and the order of entries. With the
order of the dependencies you can control the order of classpath
entries. You could add your own dependencies but could also exclude
them. The exclude is especially powerful in those cases where library
builders have made mistakes (e.g. junit without test-scope) or simply
forgot to remove dependencies when refactoring code.
The first project poms are often quite clean, but it requires
discipline to keep cleaning up your pom, e.g. removing unused
dependencies. However, you're not really punished if you don't do this.
With the shift to module-info, suddenly every library-builder gets
control. If the module-info of that library "requires A.B", it means
that every project using this library MUST have A.B on its
module-path. As end-user you cannot exclude A.B, nor can you say "B.A
replaces A.B for x.y.z" in case of duplicate classes as allowed on the
classpath. In short: the end-users must rely on the discipline of
library builders.
This loss of control for the end-user will have huge impact. Maven has
a analyze-goal in the maven-dependency-plugin which show both unused
declared dependencies and used undeclared dependencies (which means
pulled in as transitive dependency, even though the code directly uses
it). Almost every time I run this goal on any project it detects
dependencies in one of both groups.
To enforce the discipline, the java compiler should IMHO at least
check if all required modules are indeed required and if the
transitive required modules are indeed transitive. The role of the
module-info is way too important to simply allow all content. The
scope is not just about the classes anymore; the complete module tree
is now locked into the jar. Any mis-configured module-info down the
tree can never be fixed by the end-user, which could block the
end-user to use the modulepath.
just sharing my concerns,
Robert
I think this is a real concern.
Do we need an --exclude-modules (in addition to --add-modules) option on
javac, java and jlink commands?
--exclude-modules would be different to --limit-modules. If some module
requires module M and there is no module M on the module path or it is
not observable because it was not mentioned in the --limit-modules
option, then an exception is raised. OTOH if some module X requires
module M and module M is mentioned in the --exclude-modules option, then
such requires is silently ignored in hope that module X will not
actually need types from module M.
Would that satisfy your concerns?
Regards, Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
