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 <gosulli...@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 <jbarr...@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 <jbarr...@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
>>>>>
>>>>>
>>
