Le 31 déc. 2017 19:15, "Andriy Redko" <drr...@gmail.com> a écrit :
I am not sure about plugin part, to be honest. I would better craft the
module-info.java by hand (but use
the tooling, jdeps f.e., to get the initial list of modules) and have it in
the source tree for each module,
so to keep the history, etc. That would be aligned with Sergey's suggestion
to have Java 9 master sometime
in the future.
But, by and large, you may be right and the plugin is the viable option.
Still, if 99% of the CXF dependencies are
going to be automatic modules nonetheless, what it will buy us? And looking
into other projects, that seems to
be the starting point for many. Anyway, I would prefer to get it all and
right now :-D but realistically, I see
the automatic module name to be the less riskier approach to begin with
(just a manifest change), not necessarily
the best one though.
Or the worst since you dont expose the "api" but all the classes and breaks
SPI since service loader loading is different in named modules, no?
Best Regards,
Andriy Redko
RMB> Hmm, shout if I didn't get your comments properly and my comment is
obvious but I think 1 and 3 are fine - that's
RMB> why I proposed them - because you can create the module-info.java with
java 8. This is what does the plugin I
RMB> mentionned, writing it directly with java 9 (long story short it has a
module-info parser and writer).
RMB> Romain Manni-Bucau
RMB> @rmannibucau | Blog | Old Blog | Github | LinkedIn
RMB> 2017-12-31 16:58 GMT+01:00 Andriy Redko <drr...@gmail.com>:
RMB> Hi Romain,
RMB> I think there are 2 parts regarding modules: 1) using CXF from
modularized
RMB> applications and 2) release/redesign CXF in a modular fashion (I mean
Java 9 modules).
RMB> The 2nd part is where we are heading eventually but we won't be
trully modular till
RMB> all our dependencies are available as modules as well. The idea of
adding
RMB> automatic module name is helping out with the 1st part. Regarding
your questions
RMB> though:
RMB> 1. Adding module-info.java would mean, at least, to branch the
artifacts (java9+ / java8).
RMB> 2. Yes, I think it makes sense, this is the recommended way, but we
should better make a
RMB> proposal first (as part of the JIRA Dennis created).
RMB> 3. I think this is the only way (as module-info.java won't compile
with Java 8)
RMB> Automatic modules is a good start (arguably, for sure), because from
the efforts
RMB> perspetive, it looks doable in a short time vs adding proper
module-info.java to
RMB> each module, which would take significantly more. Thoughts?
RMB> Best Regards,
RMB> Andriy Redko
RMB>> Hi guys,
RMB>> Few random notes/questions:
RMB>> 1. Why not using https://github.com/moditect/
moditect/blob/master/README.md
RMB>> and assume the moduleinfo instead of working it around with automatic
RMB>> module name?
RMB>> 2. For the naming it should really be someting like $group.$module
IMO,
RMB>> probably with underscores instead of iphens for the module and maybe
RMB>> removing cxf from the module dince it is in the package
RMB>> 3. Is it possible to double relezse each module, one with the module
info
RMB>> (if you do 1, or without the automatic module name if you dont) and a
RMB>> qualifier jdk9 and keep current ones as today until the whole stack
is java
RMB>> 9 (transitively). Easy to break consumers otherwise.
RMB>> Le 31 déc. 2017 13:38, "Dennis Kieselhorst" <m...@dekies.de> a écrit
:
>>> > Exactly, that's the idea, updating the manifest with
>>> Automatic-Module-Name. We could also add a sample
>>> > project (this would be Java 9 based) to illustrate the basic usage of
>>> CXF from/within green field Java 9
>>> > modular project (although we may need to do more work here I
suspect).
>>> Thanks.
>>> I've opened CXF-7600 for it. What should be the Automatic-Module-Name
>>> for cxf-core? Just org.apache.cxf? Or org.apache.cxf.core which doesn't
>>> match the package name structure?
>>> Regards
>>> Dennis
