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 n
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 wrote:
> Yeah that would fix one of a dozen “leaked” internal p
Yeah that would fix one of a dozen “leaked” internal packages. Baby steps!
-Jake
> On Dec 3, 2018, at 4:32 PM, Kirk Lund 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 logg
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 wrote:
> I'm iteratively cleaning up geode's internal logging (
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 n
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
