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 support for native JPMS so users may start experimenting. So I want to release a binary distribution with dependencies packed inside: mylib/libs/*.jar (not modularized yet) mylib/mods/*.jar (with module descriptor) What I am thinking about is to require all from mylib/mods in the descriptor of the main jar and let up to users to decide how to make available jars from mylib/lib to the runtime. During compilation of the project I still want to force maven-compiler-plugin to reference them on module path so I can see if there are any JPMS issues. Thank you, Roman On Fri, Apr 13, 2018 at 4:07 PM, Robert Scholte <rfscho...@apache.org> wrote: > 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 meantime you can add the following entry to your MANIFEST.MF so the > library consumers can refer to it as if it already a module: > Automatic-Module-Name: module.name.of.the.library > > thanks, > Robert > > > On Fri, 13 Apr 2018 11:43:22 +0200, Roman Grigoriadi < > roman.grigori...@gmail.com> wrote: > > 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 it >> is more convenient for users than to additionally decide where to put and >> how to reference it. >> >> Thank you. >> Roman >> >> On Fri, Apr 13, 2018 at 10:17 AM, Robert Scholte <rfscho...@apache.org> >> wrote: >> >> 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. It is a new way of thinking and it looks like >>> your >>> project has potential to be optimized for that. >>> >>> thanks, >>> Robert >>> >>> >>> On Thu, 12 Apr 2018 13:19:34 +0200, Roman Grigoriadi < >>> roman.grigori...@gmail.com> wrote: >>> >>> 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/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 unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: users-h...@maven.apache.org >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
