You're actually asking for details about the JPMS specification.
I advice you to read the thread "Proposal: #AutomaticModuleNames
(revised)"[1]
This has been one of the crucial changes to accept the JPMS specification.
Before this thread started, there was only bottom up and top down, and no
I see your point. But wouldn't it result in a kind of modularization
deadlock if all will wait for their dependencies to have a module name?
Lets say I develop a library, which has 10 dependencies. I own most of
those and have them modularised except for one or two. I want to add early
testing sup
Here you hit the nail on the head! This is exactly my concern and I've
spoken about this on several conferences.
TLDR: Don't publish libraries to Maven Central that depend on at least one
filename-based automatic module. You must wait until all your dependencies
are explicit modules.
In the
I guess you are right. I wasn't sure if it is a good idea to include a name
for a module in my descriptor for a dependency which is actually not named
(automatic) and release with such descriptor. But given this dependency is
fixed version, it will not get any other name than I am referencing and i
But that means that the dependency is actually required at runtime.
Looks to me there are 2 options:
- make that dependency a requirement
- restructure your code so it can be a static requirement
One of the benefits I do like about the modularization is that it forces
you to do clean coding. I
Hi Robert,
I don't think my case is suitable for requires static / optional. Runtime
will fail with ClassNotFound exception if classes are neither on CP or MP.
Roman
On Thu, Apr 12, 2018 at 12:46 PM, Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:
> Hello Robert
>
> Le 11/04/201
Hello Robert
Le 11/04/2018 à 18:45, Robert Scholte a écrit :
> I am not aware of such problem. Did you create a Jira[1] issue for it?
>
Done: https://issues.apache.org/jira/browse/MCOMPILER-336
Thanks
Martin
-
To
Hello Robert
Le 11/04/2018 à 18:45, Robert Scholte a écrit :
> I am not aware of such problem. Did you create a Jira[1] issue for it?
>
> There should be no reason to have a workaround, all the information is
> there so Maven is capable to divide jars properly over both paths. If
> you can add a
Hi Martin,
I am not aware of such problem. Did you create a Jira[1] issue for it?
There should be no reason to have a workaround, all the information is
there so Maven is capable to divide jars properly over both paths. If you
can add a project so I can reproduce the issue, I can have a look
Hi Roman,
seems like you want to mark your dependency as true
and define the depending module as requires static some.module;
thanks,
Robert
On Wed, 11 Apr 2018 13:14:24 +0200, Roman Grigoriadi
wrote:
Thanks Robert,
I tried to add requires for name which is resolved by JPMS for my
non
I also have the case where maven-compiler-plugin puts a dependency in
classpath while it should be in modulepath. Strangely, the plugin does
the correct thing when executed with "mvn _clean_ install" but not when
executing "mvn install" without clean. This issue happen only when the
useIncrementalC
Thanks Robert,
I tried to add requires for name which is resolved by JPMS for my
non-modularised jar, and it *somehow* made compiler-plugin to put this jar
on module-path.
However if I don't want to reference this jar in my module descriptor, so I
let decision up to user if to put this dependency
Hi
every jar that matches a "requires"-entry of your projects module
descriptor and all jars that matches the indirect requirements will be
added to the module-path. The rest will stay on the classpath.
If you want to do more, you need to verify the JPMS options available for
java/javac[1]
Hi,
I would like to place some of the project dependencies to --module-path to
make them automatic "derived name" modules during project compilation. I
can see that maven-compiler-plugin:3.7.0 tries to find module-info.class
and Automatic-Module-Name entry in MANIFEST. If found it uses those jars
14 matches
Mail list logo
