Around what? there is no problem to have multiple packages in multiple modules depending on each other (if you decide to ship modules at all). Only split packages is a problem (but this is also a problem for OSGi or code signing so nobody should really use that anyway)
Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: Ralph Goers <ralph.go...@dslextreme.com> Sent: Friday, April 21, 2017 10:34:36 PM To: Commons Developers List Subject: Re: [all] Java 9 module names I am having a hard time figuring out how Log4j is going to be able to support this. The API itself is in org.apache.logging.log4j and some packages under that. All the main implementation is under org.apache.logging.log4j.core. These obviously overlap. Most of our other jars have packages that are in org.apache.logging.log4j.xxx where xxx matches the jar name. We aren’t going to change the API to support modules. Is there some reasonable way around this? Ralph > On Apr 21, 2017, at 6:16 AM, Stephen Colebourne <scolebou...@joda.org> wrote: > > On 21 April 2017 at 13:59, sebb <seb...@gmail.com> wrote: >> What happens when there is a API break which necessitates a package name >> change? >> I assume that the module name will also need to change to the new >> super-package. >> e.g. >> >> Commons-Lang4 >> -> super-package org.apache.commons.lang4 >> -> module org.apache.commons.lang4 > > Yes, thats right. > >> AFAICT Commons generally has obvious and unique super-packages for >> each component. >> This should make it easier than for larger projects with lots of jars >> and potentially overlapping package names. >> >> However even Commons has some code that uses a different package structure. >> e.g. NET uses examples as the super-package. >> This includes working examples that are included in the release. >> I guess that will have to change (which is probably a good idea anyway). > > Yes, as it stands, [net] would be a bad modular citizen, because it > exposes the "examples" package, and thus prevents any other module > from using that package. Just move it to > org.apache.commons.net.examples. > > Stephen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
