On Sat, 30 Jun 2018 17:57:50 +0200, Václav Haisman <vhais...@gmail.com>
wrote:
On 28 June 2018 at 20:54, Robert Scholte <rfscho...@apache.org> wrote:
Please see https://issues.apache.org/jira/browse/MPLUGIN-341 for the
full
story:
TLDR; No, Maven can't be (Java) modularized, otherwise all plugins
become
useless.
I am no expert but it seems to me Java 9 services deal with this. Or
don't
they?
Java 9 is about 2 things: reliable configuration (all required
dependencies are there) and strong encapsulation (hide internal packages).
When looking at Maven, poms already provide reliable configuration, but
this is build time only. If you use Maven to distribute your applications
as well, then the configuration is reliable too, i.e. all required
dependencies are there.
Java 9 and beyond have there own independent way of modularization, but
this came with new rules. One of the most aggressive rule is that classes
in jars must have unique packages.
Evolution of Maven resulted in the current set of jars, where classes are
placed together if they have a logical shared goal. To stay compatible we
didn't rename the packages, and there was never a need to do so: classes
are unique, in other words no class collisions.
There's also a jar called maven-compat, which contains classes from Maven2
and which are there to keep all plugins working. Especially this jar will
always cause split packages.
So what we could do is create a monolith jar of Maven to ensure there's no
split packages. But what does this mean:
- you'll get a huge jar, you should only need probably less than 1%
- the jar gets one module name to please consumers, however Maven won't
run on the module path, so this will only be a false assumption they're
safe.
For your interest, there's still a general issue with containers: how to
handle dynamic loaded plugins/wars/...
If we want Maven to become Java modularized, we need to repackage classes.
That will imply that all current Maven plugins become useless.
I'm not sure what you think what services will fix, but it won't solve the
critical issue of split packages.
Saying it very simple: Services (already available in Java 6) is like
JSR330 (@Inject + @Named) but without CDI container. Maven uses a CDI
container, so services won't help here.
If you still think there's a reliable solution to let Maven use Java
Modules, I'd like to see your solution, there are probably more people
interested.
thanks,
Robert
It is hard to believe that there would be no way forward for Maven in
some
fashion.
On Thu, 28 Jun 2018 12:59:13 +0200, Václav Haisman <vhais...@gmail.com>
wrote:
Hi.
Is there any effort to make Maven Java 9 friendly and provide modules?
I
have hit some issues when I was trying to compile a 3rd party Maven
plugin
(nashorn-maven-plugin) as Java 9. When I tried to provide it with
module-info.java I got stuck on errors like this:
[ERROR] error: the unnamed module reads package org.apache.maven.plugin
from both maven.core and maven.plugin.api
[ERROR] error: module maven.plugin.annotations reads package
org.apache.maven.plugin from both maven.plugin.api and maven.core
[ERROR] error: module maven.plugin.api reads package
org.apache.maven.plugin from both maven.plugin.api and maven.core
[ERROR] error: module maven.model reads package org.apache.maven.plugin
from both maven.plugin.api and maven.core
[ERROR] error: module maven.core reads package org.apache.maven.plugin
from
both maven.plugin.api and maven.core
It seems to me that Maven would need some refactoring and Java package
namespace splitting to get it to play nicely with Java 9 modules.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
