Hm, I don't think a bridge implementation needs to fake a (API) module. Your client code requires the API module and no specific implementation. The implementations (including the bridge) export their specific packages to the API module (optionally with service provider for discovery).
This is basically the same as with OSGi (only that modules allow friends easier). The runtime scope in maven would be for those modules which are not explicitely required but needed at runtime. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: jodastep...@gmail.com <jodastep...@gmail.com> on behalf of Stephen Colebourne <scolebou...@joda.org> Sent: Monday, April 24, 2017 1:42:33 PM To: Commons Developers List Subject: Re: [all] Java 9 module names On 24 April 2017 at 11:08, Jörg Schaible <joerg.schai...@bpm-inspire.com> wrote: > Stephen Colebourne wrote: > >> Sounds like you could use --add-modules to add the module separately >> from the command line, or add the module to the application's >> module-info rather than the libraries. >> >> In general, I suspect a library module-info.java should depend only on >> the other modules it really needs (eg. the API of slf4j), while >> something else, such as the application, adds the implementation >> module (eg. the SLF4J implementation). > > Which will create another chaos. Currently I can use the the xx-over-yy > artifacts to replace a hard coded dependency of an artifact if it is > required to embed it in a larger system. You still can. See my latest blog for the mental model you need: http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.html TL;DR, modules != artifacts. Depending on a module does not imply depending on exactly the same artifact that was used at compile time. Thus, the xx-over-yy jar files are still useful, provided they have the same module name as the module they are faking. See https://jira.qos.ch/browse/SLF4J-408 for how slf4j needs tweaking. Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
