You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Jacob Barrett <jb...@pivotal.io> on 2018/12/03 21:31:42 UTC
Third Iteration of Java Modules Support
All,
I’ll start with yuck! I took a stab at adding module-info.java files to core and cq and it isn’t pretty. So all the work done in he second iteration, internal package refactoring, etc., also has to be done for real modules. To achieve this we basically have to compile the sources in a Java 9+ compiler using the new ‘—release X’ argument, where primary sources get ‘—release 8’ and module-info.java gets ‘—release 9’. If only it was that easy though as the compiler validates the module-info.java when compiling so all the packages and classes mention in it must exist in the source input to javac. Blah blah smoke and mirrors later it is doable, such that a jar is produced with Java 8 compatible (binary and API) classes and a Java 9+ module info file.
When all is done here is the module file for the core, cq and an application.
geode-core:
module org.apache.geode.core {
exports org.apache.geode;
exports org.apache.geode.cache;
exports org.apache.geode.cache.client;
exports org.apache.geode.cache.query;
exports org.apache.geode.pdx;
requires org.apache.geode.common;
requires org.apache.geode.json;
requires java.desktop;
requires java.naming;
requires java.management;
requires java.rmi;
requires java.sql;
requires org.apache.logging.log4j;
requires org.apache.logging.log4j.core;
requires antlr;
opens org.apache.geode.internal.logging.log4j to org.apache.logging.log4j.core;
opens org.apache.geode.cache.query.internal.parse to antlr;
uses org.apache.geode.distributed.internal.DistributedSystemService;
uses org.apache.geode.cache.query.internal.cq.spi.CqServiceFactory;
uses org.apache.geode.internal.cache.CacheService;
// TODO Internal exports are bad
exports org.apache.geode.cache.client.internal to org.apache.geode.cq;
exports org.apache.geode.cache.query.internal to org.apache.geode.cq;
exports org.apache.geode.cache.query.internal.cq to org.apache.geode.cq;
exports org.apache.geode.cache.query.internal.cq.spi to org.apache.geode.cq;
exports org.apache.geode.distributed.internal to org.apache.geode.cq;
exports org.apache.geode.internal to org.apache.geode.cq;
exports org.apache.geode.internal.cache to org.apache.geode.cq;
exports org.apache.geode.internal.cache.tier.sockets to org.apache.geode.cq;
exports org.apache.geode.internal.logging to org.apache.geode.cq;
exports org.apache.geode.internal.statistics to org.apache.geode.cq;
}
geode-cq:
module org.apache.geode.cq {
requires org.apache.geode.core;
provides org.apache.geode.cache.query.internal.cq.spi.CqServiceFactory
with org.apache.geode.cq.internal.cache.query.CqServiceFactoryImpl;
provides org.apache.geode.distributed.internal.DistributedSystemService
with org.apache.geode.cq.internal.CQDistributedSystemService;
requires org.apache.logging.log4j;
}
application:
module com.example.java11example {
exports com.example;
// for PDX auto serialization
opens com.example to org.apache.geode.core;
requires org.apache.geode.core;
requires org.apache.geode.cq;
}
Thoughts?
-Jake
Re: Third Iteration of Java Modules Support
Posted by Jacob Barrett <jb...@pivotal.io>.
Like our our jars today a module is effectively part of your contract. That doesn’t mean we can’t create new modules/jars in the future that provide overlapping access to APIs. The uber jar in the first iteration was an example of this. Care just needs to be taken when defining dependencies on new modules and deprecating old ones.
-Jake
> On Dec 4, 2018, at 9:35 AM, Galen O'Sullivan <go...@pivotal.io> wrote:
>
> Jake,
>
> This is awesome! I do have a question, though: would releasing such a
> module info make it hard to improve upon later by giving the expectation of
> one set of modules?
>
> Thanks,
> Galen
>
> On Mon, Dec 3, 2018 at 4:44 PM Jacob Barrett <jb...@pivotal.io> wrote:
>
>> Yeah that would fix one of a dozen “leaked” internal packages. Baby steps!
>>
>> -Jake
>>
>>
>>> On Dec 3, 2018, at 4:32 PM, Kirk Lund <kl...@apache.org> wrote:
>>>
>>> Moving internal.logging to geode-logging would involve moving some
>>> internal.logging classes to org.apache.geode.logging. I think that would
>>> help with the logging portion of what you're doing.
>>>
>>>> On Mon, Dec 3, 2018 at 4:30 PM Kirk Lund <kl...@apache.org> wrote:
>>>>
>>>> I'm iteratively cleaning up geode's internal logging (specifically our
>>>> dependency on log4j core) so that log4j core can be optional and a user
>>>> could switch it out for logback or do further customization of our
>> logging.
>>>>
>>>> Even without the modules work you're doing, moving our logging internals
>>>> to a new geode-logging module would make my work easier so that I could
>>>> hide the Geode log4j2 appenders behind a ServiceLoader -- would that
>> make
>>>> your work easier or more difficult?
>>>>
>>>>> On Mon, Dec 3, 2018 at 1:31 PM Jacob Barrett <jb...@pivotal.io>
>> wrote:
>>>>>
>>>>> All,
>>>>>
>>>>> I’ll start with yuck! I took a stab at adding module-info.java files to
>>>>> core and cq and it isn’t pretty. So all the work done in he second
>>>>> iteration, internal package refactoring, etc., also has to be done for
>> real
>>>>> modules. To achieve this we basically have to compile the sources in a
>> Java
>>>>> 9+ compiler using the new ‘—release X’ argument, where primary sources
>> get
>>>>> ‘—release 8’ and module-info.java gets ‘—release 9’. If only it was
>> that
>>>>> easy though as the compiler validates the module-info.java when
>> compiling
>>>>> so all the packages and classes mention in it must exist in the source
>>>>> input to javac. Blah blah smoke and mirrors later it is doable, such
>> that a
>>>>> jar is produced with Java 8 compatible (binary and API) classes and a
>> Java
>>>>> 9+ module info file.
>>>>>
>>>>> When all is done here is the module file for the core, cq and an
>>>>> application.
>>>>>
>>>>> geode-core:
>>>>> module org.apache.geode.core {
>>>>> exports org.apache.geode;
>>>>> exports org.apache.geode.cache;
>>>>> exports org.apache.geode.cache.client;
>>>>> exports org.apache.geode.cache.query;
>>>>> exports org.apache.geode.pdx;
>>>>>
>>>>> requires org.apache.geode.common;
>>>>> requires org.apache.geode.json;
>>>>>
>>>>> requires java.desktop;
>>>>> requires java.naming;
>>>>> requires java.management;
>>>>> requires java.rmi;
>>>>> requires java.sql;
>>>>>
>>>>> requires org.apache.logging.log4j;
>>>>> requires org.apache.logging.log4j.core;
>>>>> requires antlr;
>>>>>
>>>>> opens org.apache.geode.internal.logging.log4j to
>>>>> org.apache.logging.log4j.core;
>>>>> opens org.apache.geode.cache.query.internal.parse to antlr;
>>>>>
>>>>> uses org.apache.geode.distributed.internal.DistributedSystemService;
>>>>> uses org.apache.geode.cache.query.internal.cq.spi.CqServiceFactory;
>>>>> uses org.apache.geode.internal.cache.CacheService;
>>>>>
>>>>> // TODO Internal exports are bad
>>>>> exports org.apache.geode.cache.client.internal to org.apache.geode.cq;
>>>>> exports org.apache.geode.cache.query.internal to org.apache.geode.cq;
>>>>> exports org.apache.geode.cache.query.internal.cq to
>> org.apache.geode.cq;
>>>>> exports org.apache.geode.cache.query.internal.cq.spi to
>>>>> org.apache.geode.cq;
>>>>> exports org.apache.geode.distributed.internal to org.apache.geode.cq;
>>>>> exports org.apache.geode.internal to org.apache.geode.cq;
>>>>> exports org.apache.geode.internal.cache to org.apache.geode.cq;
>>>>> exports org.apache.geode.internal.cache.tier.sockets to
>>>>> org.apache.geode.cq;
>>>>> exports org.apache.geode.internal.logging to org.apache.geode.cq;
>>>>> exports org.apache.geode.internal.statistics to org.apache.geode.cq;
>>>>> }
>>>>>
>>>>> geode-cq:
>>>>> module org.apache.geode.cq {
>>>>> requires org.apache.geode.core;
>>>>>
>>>>> provides org.apache.geode.cache.query.internal.cq.spi.CqServiceFactory
>>>>> with
>> org.apache.geode.cq.internal.cache.query.CqServiceFactoryImpl;
>>>>> provides
>> org.apache.geode.distributed.internal.DistributedSystemService
>>>>> with org.apache.geode.cq.internal.CQDistributedSystemService;
>>>>>
>>>>> requires org.apache.logging.log4j;
>>>>> }
>>>>>
>>>>> application:
>>>>> module com.example.java11example {
>>>>> exports com.example;
>>>>>
>>>>> // for PDX auto serialization
>>>>> opens com.example to org.apache.geode.core;
>>>>>
>>>>> requires org.apache.geode.core;
>>>>> requires org.apache.geode.cq;
>>>>> }
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> -Jake
>>>>>
>>>>>
>>
Re: Third Iteration of Java Modules Support
Posted by Galen O'Sullivan <go...@pivotal.io>.
Jake,
This is awesome! I do have a question, though: would releasing such a
module info make it hard to improve upon later by giving the expectation of
one set of modules?
Thanks,
Galen
On Mon, Dec 3, 2018 at 4:44 PM Jacob Barrett <jb...@pivotal.io> wrote:
> Yeah that would fix one of a dozen “leaked” internal packages. Baby steps!
>
> -Jake
>
>
> > On Dec 3, 2018, at 4:32 PM, Kirk Lund <kl...@apache.org> wrote:
> >
> > Moving internal.logging to geode-logging would involve moving some
> > internal.logging classes to org.apache.geode.logging. I think that would
> > help with the logging portion of what you're doing.
> >
> >> On Mon, Dec 3, 2018 at 4:30 PM Kirk Lund <kl...@apache.org> wrote:
> >>
> >> I'm iteratively cleaning up geode's internal logging (specifically our
> >> dependency on log4j core) so that log4j core can be optional and a user
> >> could switch it out for logback or do further customization of our
> logging.
> >>
> >> Even without the modules work you're doing, moving our logging internals
> >> to a new geode-logging module would make my work easier so that I could
> >> hide the Geode log4j2 appenders behind a ServiceLoader -- would that
> make
> >> your work easier or more difficult?
> >>
> >>> On Mon, Dec 3, 2018 at 1:31 PM Jacob Barrett <jb...@pivotal.io>
> wrote:
> >>>
> >>> All,
> >>>
> >>> I’ll start with yuck! I took a stab at adding module-info.java files to
> >>> core and cq and it isn’t pretty. So all the work done in he second
> >>> iteration, internal package refactoring, etc., also has to be done for
> real
> >>> modules. To achieve this we basically have to compile the sources in a
> Java
> >>> 9+ compiler using the new ‘—release X’ argument, where primary sources
> get
> >>> ‘—release 8’ and module-info.java gets ‘—release 9’. If only it was
> that
> >>> easy though as the compiler validates the module-info.java when
> compiling
> >>> so all the packages and classes mention in it must exist in the source
> >>> input to javac. Blah blah smoke and mirrors later it is doable, such
> that a
> >>> jar is produced with Java 8 compatible (binary and API) classes and a
> Java
> >>> 9+ module info file.
> >>>
> >>> When all is done here is the module file for the core, cq and an
> >>> application.
> >>>
> >>> geode-core:
> >>> module org.apache.geode.core {
> >>> exports org.apache.geode;
> >>> exports org.apache.geode.cache;
> >>> exports org.apache.geode.cache.client;
> >>> exports org.apache.geode.cache.query;
> >>> exports org.apache.geode.pdx;
> >>>
> >>> requires org.apache.geode.common;
> >>> requires org.apache.geode.json;
> >>>
> >>> requires java.desktop;
> >>> requires java.naming;
> >>> requires java.management;
> >>> requires java.rmi;
> >>> requires java.sql;
> >>>
> >>> requires org.apache.logging.log4j;
> >>> requires org.apache.logging.log4j.core;
> >>> requires antlr;
> >>>
> >>> opens org.apache.geode.internal.logging.log4j to
> >>> org.apache.logging.log4j.core;
> >>> opens org.apache.geode.cache.query.internal.parse to antlr;
> >>>
> >>> uses org.apache.geode.distributed.internal.DistributedSystemService;
> >>> uses org.apache.geode.cache.query.internal.cq.spi.CqServiceFactory;
> >>> uses org.apache.geode.internal.cache.CacheService;
> >>>
> >>> // TODO Internal exports are bad
> >>> exports org.apache.geode.cache.client.internal to org.apache.geode.cq;
> >>> exports org.apache.geode.cache.query.internal to org.apache.geode.cq;
> >>> exports org.apache.geode.cache.query.internal.cq to
> org.apache.geode.cq;
> >>> exports org.apache.geode.cache.query.internal.cq.spi to
> >>> org.apache.geode.cq;
> >>> exports org.apache.geode.distributed.internal to org.apache.geode.cq;
> >>> exports org.apache.geode.internal to org.apache.geode.cq;
> >>> exports org.apache.geode.internal.cache to org.apache.geode.cq;
> >>> exports org.apache.geode.internal.cache.tier.sockets to
> >>> org.apache.geode.cq;
> >>> exports org.apache.geode.internal.logging to org.apache.geode.cq;
> >>> exports org.apache.geode.internal.statistics to org.apache.geode.cq;
> >>> }
> >>>
> >>> geode-cq:
> >>> module org.apache.geode.cq {
> >>> requires org.apache.geode.core;
> >>>
> >>> provides org.apache.geode.cache.query.internal.cq.spi.CqServiceFactory
> >>> with
> org.apache.geode.cq.internal.cache.query.CqServiceFactoryImpl;
> >>> provides
> org.apache.geode.distributed.internal.DistributedSystemService
> >>> with org.apache.geode.cq.internal.CQDistributedSystemService;
> >>>
> >>> requires org.apache.logging.log4j;
> >>> }
> >>>
> >>> application:
> >>> module com.example.java11example {
> >>> exports com.example;
> >>>
> >>> // for PDX auto serialization
> >>> opens com.example to org.apache.geode.core;
> >>>
> >>> requires org.apache.geode.core;
> >>> requires org.apache.geode.cq;
> >>> }
> >>>
> >>> Thoughts?
> >>>
> >>> -Jake
> >>>
> >>>
>
Re: Third Iteration of Java Modules Support
Posted by Jacob Barrett <jb...@pivotal.io>.
Yeah that would fix one of a dozen “leaked” internal packages. Baby steps!
-Jake
> On Dec 3, 2018, at 4:32 PM, Kirk Lund <kl...@apache.org> wrote:
>
> Moving internal.logging to geode-logging would involve moving some
> internal.logging classes to org.apache.geode.logging. I think that would
> help with the logging portion of what you're doing.
>
>> On Mon, Dec 3, 2018 at 4:30 PM Kirk Lund <kl...@apache.org> wrote:
>>
>> I'm iteratively cleaning up geode's internal logging (specifically our
>> dependency on log4j core) so that log4j core can be optional and a user
>> could switch it out for logback or do further customization of our logging.
>>
>> Even without the modules work you're doing, moving our logging internals
>> to a new geode-logging module would make my work easier so that I could
>> hide the Geode log4j2 appenders behind a ServiceLoader -- would that make
>> your work easier or more difficult?
>>
>>> On Mon, Dec 3, 2018 at 1:31 PM Jacob Barrett <jb...@pivotal.io> wrote:
>>>
>>> All,
>>>
>>> I’ll start with yuck! I took a stab at adding module-info.java files to
>>> core and cq and it isn’t pretty. So all the work done in he second
>>> iteration, internal package refactoring, etc., also has to be done for real
>>> modules. To achieve this we basically have to compile the sources in a Java
>>> 9+ compiler using the new ‘—release X’ argument, where primary sources get
>>> ‘—release 8’ and module-info.java gets ‘—release 9’. If only it was that
>>> easy though as the compiler validates the module-info.java when compiling
>>> so all the packages and classes mention in it must exist in the source
>>> input to javac. Blah blah smoke and mirrors later it is doable, such that a
>>> jar is produced with Java 8 compatible (binary and API) classes and a Java
>>> 9+ module info file.
>>>
>>> When all is done here is the module file for the core, cq and an
>>> application.
>>>
>>> geode-core:
>>> module org.apache.geode.core {
>>> exports org.apache.geode;
>>> exports org.apache.geode.cache;
>>> exports org.apache.geode.cache.client;
>>> exports org.apache.geode.cache.query;
>>> exports org.apache.geode.pdx;
>>>
>>> requires org.apache.geode.common;
>>> requires org.apache.geode.json;
>>>
>>> requires java.desktop;
>>> requires java.naming;
>>> requires java.management;
>>> requires java.rmi;
>>> requires java.sql;
>>>
>>> requires org.apache.logging.log4j;
>>> requires org.apache.logging.log4j.core;
>>> requires antlr;
>>>
>>> opens org.apache.geode.internal.logging.log4j to
>>> org.apache.logging.log4j.core;
>>> opens org.apache.geode.cache.query.internal.parse to antlr;
>>>
>>> uses org.apache.geode.distributed.internal.DistributedSystemService;
>>> uses org.apache.geode.cache.query.internal.cq.spi.CqServiceFactory;
>>> uses org.apache.geode.internal.cache.CacheService;
>>>
>>> // TODO Internal exports are bad
>>> exports org.apache.geode.cache.client.internal to org.apache.geode.cq;
>>> exports org.apache.geode.cache.query.internal to org.apache.geode.cq;
>>> exports org.apache.geode.cache.query.internal.cq to org.apache.geode.cq;
>>> exports org.apache.geode.cache.query.internal.cq.spi to
>>> org.apache.geode.cq;
>>> exports org.apache.geode.distributed.internal to org.apache.geode.cq;
>>> exports org.apache.geode.internal to org.apache.geode.cq;
>>> exports org.apache.geode.internal.cache to org.apache.geode.cq;
>>> exports org.apache.geode.internal.cache.tier.sockets to
>>> org.apache.geode.cq;
>>> exports org.apache.geode.internal.logging to org.apache.geode.cq;
>>> exports org.apache.geode.internal.statistics to org.apache.geode.cq;
>>> }
>>>
>>> geode-cq:
>>> module org.apache.geode.cq {
>>> requires org.apache.geode.core;
>>>
>>> provides org.apache.geode.cache.query.internal.cq.spi.CqServiceFactory
>>> with org.apache.geode.cq.internal.cache.query.CqServiceFactoryImpl;
>>> provides org.apache.geode.distributed.internal.DistributedSystemService
>>> with org.apache.geode.cq.internal.CQDistributedSystemService;
>>>
>>> requires org.apache.logging.log4j;
>>> }
>>>
>>> application:
>>> module com.example.java11example {
>>> exports com.example;
>>>
>>> // for PDX auto serialization
>>> opens com.example to org.apache.geode.core;
>>>
>>> requires org.apache.geode.core;
>>> requires org.apache.geode.cq;
>>> }
>>>
>>> Thoughts?
>>>
>>> -Jake
>>>
>>>
Re: Third Iteration of Java Modules Support
Posted by Kirk Lund <kl...@apache.org>.
Moving internal.logging to geode-logging would involve moving some
internal.logging classes to org.apache.geode.logging. I think that would
help with the logging portion of what you're doing.
On Mon, Dec 3, 2018 at 4:30 PM Kirk Lund <kl...@apache.org> wrote:
> I'm iteratively cleaning up geode's internal logging (specifically our
> dependency on log4j core) so that log4j core can be optional and a user
> could switch it out for logback or do further customization of our logging.
>
> Even without the modules work you're doing, moving our logging internals
> to a new geode-logging module would make my work easier so that I could
> hide the Geode log4j2 appenders behind a ServiceLoader -- would that make
> your work easier or more difficult?
>
> On Mon, Dec 3, 2018 at 1:31 PM Jacob Barrett <jb...@pivotal.io> wrote:
>
>> All,
>>
>> I’ll start with yuck! I took a stab at adding module-info.java files to
>> core and cq and it isn’t pretty. So all the work done in he second
>> iteration, internal package refactoring, etc., also has to be done for real
>> modules. To achieve this we basically have to compile the sources in a Java
>> 9+ compiler using the new ‘—release X’ argument, where primary sources get
>> ‘—release 8’ and module-info.java gets ‘—release 9’. If only it was that
>> easy though as the compiler validates the module-info.java when compiling
>> so all the packages and classes mention in it must exist in the source
>> input to javac. Blah blah smoke and mirrors later it is doable, such that a
>> jar is produced with Java 8 compatible (binary and API) classes and a Java
>> 9+ module info file.
>>
>> When all is done here is the module file for the core, cq and an
>> application.
>>
>> geode-core:
>> module org.apache.geode.core {
>> exports org.apache.geode;
>> exports org.apache.geode.cache;
>> exports org.apache.geode.cache.client;
>> exports org.apache.geode.cache.query;
>> exports org.apache.geode.pdx;
>>
>> requires org.apache.geode.common;
>> requires org.apache.geode.json;
>>
>> requires java.desktop;
>> requires java.naming;
>> requires java.management;
>> requires java.rmi;
>> requires java.sql;
>>
>> requires org.apache.logging.log4j;
>> requires org.apache.logging.log4j.core;
>> requires antlr;
>>
>> opens org.apache.geode.internal.logging.log4j to
>> org.apache.logging.log4j.core;
>> opens org.apache.geode.cache.query.internal.parse to antlr;
>>
>> uses org.apache.geode.distributed.internal.DistributedSystemService;
>> uses org.apache.geode.cache.query.internal.cq.spi.CqServiceFactory;
>> uses org.apache.geode.internal.cache.CacheService;
>>
>> // TODO Internal exports are bad
>> exports org.apache.geode.cache.client.internal to org.apache.geode.cq;
>> exports org.apache.geode.cache.query.internal to org.apache.geode.cq;
>> exports org.apache.geode.cache.query.internal.cq to org.apache.geode.cq;
>> exports org.apache.geode.cache.query.internal.cq.spi to
>> org.apache.geode.cq;
>> exports org.apache.geode.distributed.internal to org.apache.geode.cq;
>> exports org.apache.geode.internal to org.apache.geode.cq;
>> exports org.apache.geode.internal.cache to org.apache.geode.cq;
>> exports org.apache.geode.internal.cache.tier.sockets to
>> org.apache.geode.cq;
>> exports org.apache.geode.internal.logging to org.apache.geode.cq;
>> exports org.apache.geode.internal.statistics to org.apache.geode.cq;
>> }
>>
>> geode-cq:
>> module org.apache.geode.cq {
>> requires org.apache.geode.core;
>>
>> provides org.apache.geode.cache.query.internal.cq.spi.CqServiceFactory
>> with org.apache.geode.cq.internal.cache.query.CqServiceFactoryImpl;
>> provides org.apache.geode.distributed.internal.DistributedSystemService
>> with org.apache.geode.cq.internal.CQDistributedSystemService;
>>
>> requires org.apache.logging.log4j;
>> }
>>
>> application:
>> module com.example.java11example {
>> exports com.example;
>>
>> // for PDX auto serialization
>> opens com.example to org.apache.geode.core;
>>
>> requires org.apache.geode.core;
>> requires org.apache.geode.cq;
>> }
>>
>> Thoughts?
>>
>> -Jake
>>
>>
Re: Third Iteration of Java Modules Support
Posted by Kirk Lund <kl...@apache.org>.
I'm iteratively cleaning up geode's internal logging (specifically our
dependency on log4j core) so that log4j core can be optional and a user
could switch it out for logback or do further customization of our logging.
Even without the modules work you're doing, moving our logging internals to
a new geode-logging module would make my work easier so that I could hide
the Geode log4j2 appenders behind a ServiceLoader -- would that make your
work easier or more difficult?
On Mon, Dec 3, 2018 at 1:31 PM Jacob Barrett <jb...@pivotal.io> wrote:
> All,
>
> I’ll start with yuck! I took a stab at adding module-info.java files to
> core and cq and it isn’t pretty. So all the work done in he second
> iteration, internal package refactoring, etc., also has to be done for real
> modules. To achieve this we basically have to compile the sources in a Java
> 9+ compiler using the new ‘—release X’ argument, where primary sources get
> ‘—release 8’ and module-info.java gets ‘—release 9’. If only it was that
> easy though as the compiler validates the module-info.java when compiling
> so all the packages and classes mention in it must exist in the source
> input to javac. Blah blah smoke and mirrors later it is doable, such that a
> jar is produced with Java 8 compatible (binary and API) classes and a Java
> 9+ module info file.
>
> When all is done here is the module file for the core, cq and an
> application.
>
> geode-core:
> module org.apache.geode.core {
> exports org.apache.geode;
> exports org.apache.geode.cache;
> exports org.apache.geode.cache.client;
> exports org.apache.geode.cache.query;
> exports org.apache.geode.pdx;
>
> requires org.apache.geode.common;
> requires org.apache.geode.json;
>
> requires java.desktop;
> requires java.naming;
> requires java.management;
> requires java.rmi;
> requires java.sql;
>
> requires org.apache.logging.log4j;
> requires org.apache.logging.log4j.core;
> requires antlr;
>
> opens org.apache.geode.internal.logging.log4j to
> org.apache.logging.log4j.core;
> opens org.apache.geode.cache.query.internal.parse to antlr;
>
> uses org.apache.geode.distributed.internal.DistributedSystemService;
> uses org.apache.geode.cache.query.internal.cq.spi.CqServiceFactory;
> uses org.apache.geode.internal.cache.CacheService;
>
> // TODO Internal exports are bad
> exports org.apache.geode.cache.client.internal to org.apache.geode.cq;
> exports org.apache.geode.cache.query.internal to org.apache.geode.cq;
> exports org.apache.geode.cache.query.internal.cq to org.apache.geode.cq;
> exports org.apache.geode.cache.query.internal.cq.spi to
> org.apache.geode.cq;
> exports org.apache.geode.distributed.internal to org.apache.geode.cq;
> exports org.apache.geode.internal to org.apache.geode.cq;
> exports org.apache.geode.internal.cache to org.apache.geode.cq;
> exports org.apache.geode.internal.cache.tier.sockets to
> org.apache.geode.cq;
> exports org.apache.geode.internal.logging to org.apache.geode.cq;
> exports org.apache.geode.internal.statistics to org.apache.geode.cq;
> }
>
> geode-cq:
> module org.apache.geode.cq {
> requires org.apache.geode.core;
>
> provides org.apache.geode.cache.query.internal.cq.spi.CqServiceFactory
> with org.apache.geode.cq.internal.cache.query.CqServiceFactoryImpl;
> provides org.apache.geode.distributed.internal.DistributedSystemService
> with org.apache.geode.cq.internal.CQDistributedSystemService;
>
> requires org.apache.logging.log4j;
> }
>
> application:
> module com.example.java11example {
> exports com.example;
>
> // for PDX auto serialization
> opens com.example to org.apache.geode.core;
>
> requires org.apache.geode.core;
> requires org.apache.geode.cq;
> }
>
> Thoughts?
>
> -Jake
>
>