You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Andriy Redko <dr...@gmail.com> on 2017/12/24 00:11:52 UTC
Re: New Java 9 master
Hey guys,
It feels like a right time to resume the discussion around Java 9. The adoption of modules is slowly but is taking
off. I run into this article https://www.javaadvent.com/2017/12/automatic-module-name-calling-java-library-maintainers.html by
Sander Mak (co-author of Java 9 Modularity book) recently, he gives pretty pragmatic advice on how to start embracing the
modular applications. Indeed, the first steps are pretty low risk and straightforward, just updating the MANIFEST.MF files.
Also, I have checked a couple of leading Java libraries (f.e. Spring Framework) and can confirm that they already did the
relevant updates. Does it sound like a good idea? It does not require a dedicated Java 9 master but something with could
do in the current one. Thanks.
Best Regards,
Andriy Redko
SB> Hi Jeff
SB> Good to hear from you, thanks for the feedback :-).
SB> I suppose there's some consensus that in the next few months the team
SB> should probably spend more time with using Java 9 with CXF 3.2.x, and
SB> really get a better appreciation of what Java 9 is and which tools are
SB> available around (such as may be Maven Java 9 related as Dan indicated,
SB> etc) as it's fair enough to say that some of us (incl. myself) are not
SB> doing practical Java 9 at all at the moment...
SB> Hopefully that will help, perhaps another round of discussions will
SB> follow afterwards, we'll see.
SB> Thanks, Sergey
SB> On 17/11/17 03:42, Jeff Genender wrote:
>>> On Nov 16, 2017, at 7:02 AM, Sergey Beryozkin <sb...@gmail.com> wrote:
>>> Indeed it will take a long time for a team with the limited resources to have CXF embracing Java 9. Postponing the start of this long process for 2 years or so and wait for the users to come in and say, when will CXF will do what SpringBoot with Java 9 can do, is not strategically right move IMHO.
>> +1000!!!!
>>> Have the Java 9 branch, let people spend as much time as needed to play there, keep going with Java 8+9 in 3.2.1. I don't see where the conflict is
>> +1,000,000!!!
>> Jeff
>>> Cheers. Sergey
>>> On 16/11/17 13:53, Andriy Redko wrote:
>>>> Modules are really far away in the future (IMHO). As per my understanding, we
>>>> could think about real modules only when all our dependencies are modularized,
>>>> which would take quite a lot of time I suppose. The Reactive Streams part is
>>>> really appealing *BUT* even there we **could** keep the same master for 8 and 9
>>>> (http://openjdk.java.net/jeps/238).
>>>> Honestly, I am not 100% sure we have to branch off the new master and keep it
>>>> Java 9 only right now. May be the good moment will be when we discountinue
>>>> 3.1.x so at least the code will be much easier to cherry-pick?
>>>> Best Regards,
>>>> Andriy Redko
>>>> CS> I am not sure sure about the need for Java 9 modules. Currently I see no
>>>> CS> user requesting this. It is also not yet fully clear how these modules
>>>> CS> behave in OSGi. As far as I understood as soon as we start with this we
>>>> CS> have code that is not working in Java 8. As we require every change to be
>>>> CS> done in master first this means we have a lot of back port work. A Java 9
>>>> CS> only master will also make it much harder for Java 8 users to supply pull
>>>> CS> requests as they have to develop and test on java 9 which is not their
>>>> CS> production system.
>>>> CS> So I think the current situation with a master that works on Java 9 and
>>>> CS> Java 8 is a pretty good situation that we should keep for as long as
>>>> CS> possible.
>>>> CS> I am not sure how attractive the other Java 9 features are. Personally I
>>>> CS> were really eager to adopt Java 8 because of the closures but I see no real
>>>> CS> need for myself to rush to java 9.
>>>> CS> When I remember how reluctant we were when it came to adopting the previous
>>>> CS> java versions like 7 and 8 as minimal requirement I think it makes sense to
>>>> CS> do this rather slowly.
>>>> CS> Christian
>>>> CS> 2017-11-16 13:31 GMT+01:00 Sergey Beryozkin <sb...@gmail.com>:
>>>>>> Hi Andriy
>>>>>> I'm only presuming that yes, a Java 9 only master would have to support
>>>>>> the new Java 9 modules system, so I'd say a lot of exciting work would
>>>>>> await for the CXF dev community :-)
>>>>>> Cheers, Sergey
>>>>>> On 16/11/17 12:19, Andriy Redko wrote:
>>>>>>> Hey Sergey,
>>>>>>> Do we have a goal to support Java 9 modules (aka Jigsaw) for
>>>>>>> the new master branch? Or we just looking to benefit from the
>>>>>>> latest changes in stardand library (as you mentioned, Flow & Co,
>>>>>>> collections are also a good example)? Is our current master JDK9
>>>>>>> compatible actually (haven't seen successfull builds from
>>>>>>> https://builds.apache.org/job/CXF-Master-JDK9) ?
>>>>>>> Best Regards,
>>>>>>> Andriy Redko
>>>>>>> SB> It's pretty simple really. It's about having a new impetus for the CXF
>>>>>>> SB> development.
>>>>>>> SB> Without a Java 9 only master CXF will be about fixing the bugs only.
>>>>>>> SB> JAX-WS is done long time ago, next version of JAX-RS will take N
>>>>>>> amount
>>>>>>> SB> of time to materialize.
>>>>>>> SB> Java 9 with its Flow class will let CXF do new work around Reactive
>>>>>>> SB> support. It will have new features that only work with Java 9 and may
>>>>>>> SB> give new ideas for the contributions.
>>>>>>> SB> 3.2.x is at the start of its life-cycle and will have a couple of
>>>>>>> years
>>>>>>> SB> at least for it to retire, giving Java 8 support.
>>>>>>> SB> 3.1.x has probably 6 months or so left in it, and after it's gone we
>>>>>>> SB> will have 3.2.x and 4.0.x or whatever new version is preferred.
>>>>>>> SB> Sergey
>>>>>>> SB> On 16/11/17 08:15, Dennis Kieselhorst wrote:
>>>>>>>> On 2017-11-16 07:27, Christian Schneider <ch...@die-schneider.net>
>>>>>>>>> wrote:
>>>>>>>>>> I dont think we can already predict when users move to Java 9.
>>>>>>>>>> So creating a Java 9 only branch at this time means we have to
>>>>>>>>>> maintain two
>>>>>>>>>> main branches over a long time.
>>>>>>>>>> What is the rationale behind a Java 9 only branch compared to being
>>>>>>>>>> Java 9
>>>>>>>>>> and Java 8 compatible on master?
>>>>>>>>> I also don't see a good reason to do that at the moment. Let's release
>>>>>>>>> the XJC plugin and users should be able to use CXF with Java 9 or am I
>>>>>>>>> missing something?
>>>>>>>>> Cheers
>>>>>>>>> Dennis
>>>> CS> --
Re: New Java 9 master
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Ok, the behavior is a bit different with this flag or not transitively (a
named module will see these classes as belonging to a named module so using
them you looks SPI, RB etc... but not for their own usage) but it looks it
can work "good enough" short term.
Le 3 janv. 2018 22:42, "Andriy Redko" <dr...@gmail.com> a écrit :
Because it will be **always** named automatically, there is nothing we can
do about it. The only thing we can
do is to suggest the better name for automatic naming (which still keeps
module in unnamed category). I think the
good example may be a convincing argument towards go / no-go decision, will
try to find time to work on it this week.
RMB> Le 3 janv. 2018 18:28, "Andriy Redko" <dr...@gmail.com> a écrit :
RMB> As per my understading of the efforts required (I hope to be wrong
here), this is ideal but unrealistic for CXF. We either
RMB> start build some foundation (following other projects), or embark on
transforming everything to named modules (and we will be
RMB> affected by all our dependecies anyway, there is nothing we can do
about it). I see the first option doable, CXF won't
RMB> able to embrace the migration at once untill all and every dependency
we use does the same. This might happen eventually
RMB> but not any time soon for sure :-(
RMB> Why not keeping it unamed then? There are very few adherence on cxf
except in integrations, no?
RMB>> This is my first point. Once named and fully migrated you hit both
issue: not default classloader and visibility
RMB>> change. First is surely workaround-able but last impacts users so
better to let people migrate on java 9...only
RMB>> once and not N times cause CXF didnt embrace it at once. This is my
big concern.
RMB>> Le 3 janv. 2018 01:56, "Andriy Redko" <dr...@gmail.com> a écrit :
RMB>> I don't think this is the case actually. If you use CXF as-is right
now in modular application, its components will
RMB>> be loaded as automatic modules, implicitly. The only step forward
we are taking is to hint JVM what the name of the
RMB>> automatic module should be (instead of relying on the automatic
conversions). Rules don't change, the presence
RMB>> of automatic module name in the manifest does not make the JAR a
named module, only module-info.java will do that
RMB>> (and this would be a large and risky change indeed). But the
presence of the better name would help us to do
RMB>> migration to module-info.java a bit more smoothly, since the module
name won't change but semantics of the module
RMB>> will (one by one they should become named modules).
RMB>>> yep
RMB>>> issue is exactly this one: automatic modules are a one way path,
you can't go back on manual modules since you
RMB>>> exposed the world and would introduce a breaking change modifying
it.
RMB>>> The other one I tried to mentionned is: what about all the cases
where CXF will be deployed on java 9 but not in
RMB>>> the root classloader (tomcat to cite a random case) which doesnt
support the new SPI loading? You are broken :(
RMB>>> Romain Manni-Bucau
RMB>>> @rmannibucau | Blog | Old Blog | Github | LinkedIn
RMB>>> 2018-01-02 14:54 GMT+01:00 Andriy Redko <dr...@gmail.com>:
RMB>>> I might be mistaken (sorry, haven't worked with Jigsaw closely
yet), but I think the service loader would work the same
RMB>>> way in case of named module and automaticaly named module. The
only differences would be contraints/rules/visibility: automaticaly
RMB>>> named module just implicitly open/export/import everything while
named module should be picky and precise.
RMB> RMB>>> 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?
RMB> RMB>>> Le 31 déc. 2017 19:15, "Andriy Redko" <dr...@gmail.com> a
écrit :
RMB> RMB>>> I am not sure about plugin part, to be honest. I would
better craft the module-info.java by hand (but use
RMB> RMB>>> the tooling, jdeps f.e., to get the initial list of
modules) and have it in the source tree for each module,
RMB> RMB>>> so to keep the history, etc. That would be aligned with
Sergey's suggestion to have Java 9 master sometime
RMB> RMB>>> in the future.
RMB> RMB>>> But, by and large, you may be right and the plugin is the
viable option. Still, if 99% of the CXF dependencies are
RMB> RMB>>> going to be automatic modules nonetheless, what it will buy
us? And looking into other projects, that seems to
RMB> RMB>>> be the starting point for many. Anyway, I would prefer to
get it all and right now :-D but realistically, I see
RMB> RMB>>> the automatic module name to be the less riskier approach
to begin with (just a manifest change), not necessarily
RMB> RMB>>> the best one though.
RMB> RMB>>> Best Regards,
RMB> RMB>>> Andriy Redko
RMB>> 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>> RMB>>> why I proposed them - because you can create the
module-info.java with java 8. This is what does the plugin I
RMB>> RMB>>> mentionned, writing it directly with java 9 (long story
short it has a module-info parser and writer).
RMB>> RMB>>> Romain Manni-Bucau
RMB>> RMB>>> @rmannibucau | Blog | Old Blog | Github | LinkedIn
RMB>> RMB>>> 2017-12-31 16:58 GMT+01:00 Andriy Redko <dr...@gmail.com>:
RMB>> RMB>>> Hi Romain,
RMB>> RMB>>> I think there are 2 parts regarding modules: 1) using CXF
from modularized
RMB>> RMB>>> applications and 2) release/redesign CXF in a modular
fashion (I mean Java 9 modules).
RMB>> RMB>>> The 2nd part is where we are heading eventually but we
won't be trully modular till
RMB>> RMB>>> all our dependencies are available as modules as well.
The idea of adding
RMB>> RMB>>> automatic module name is helping out with the 1st part.
Regarding your questions
RMB>> RMB>>> though:
RMB>> RMB>>> 1. Adding module-info.java would mean, at least, to
branch the artifacts (java9+ / java8).
RMB>> RMB>>> 2. Yes, I think it makes sense, this is the recommended
way, but we should better make a
RMB>> RMB>>> proposal first (as part of the JIRA Dennis created).
RMB>> RMB>>> 3. I think this is the only way (as module-info.java
won't compile with Java 8)
RMB>> RMB>>> Automatic modules is a good start (arguably, for sure),
because from the efforts
RMB>> RMB>>> perspetive, it looks doable in a short time vs adding
proper module-info.java to
RMB>> RMB>>> each module, which would take significantly more.
Thoughts?
RMB>> RMB>>> Best Regards,
RMB>> RMB>>> Andriy Redko
RMB>>> RMB>>> Hi guys,
RMB>>> RMB>>> Few random notes/questions:
RMB>>> RMB>>> 1. Why not using https://github.com/moditect/mo
ditect/blob/master/README.md
RMB>>> RMB>>> and assume the moduleinfo instead of working it around
with automatic
RMB>>> RMB>>> module name?
RMB>>> RMB>>> 2. For the naming it should really be someting like
$group.$module IMO,
RMB>>> RMB>>> probably with underscores instead of iphens for the
module and maybe
RMB>>> RMB>>> removing cxf from the module dince it is in the package
RMB>>> RMB>>> 3. Is it possible to double relezse each module, one
with the module info
RMB>>> RMB>>> (if you do 1, or without the automatic module name if
you dont) and a
RMB>>> RMB>>> qualifier jdk9 and keep current ones as today until the
whole stack is java
RMB>>> RMB>>> 9 (transitively). Easy to break consumers otherwise.
RMB>>> RMB>>> Le 31 déc. 2017 13:38, "Dennis Kieselhorst" <
mail@dekies.de> a écrit :
RMB>>> >>>> > Exactly, that's the idea, updating the manifest with
RMB>>> >>>> Automatic-Module-Name. We could also add a sample
RMB>>> >>>> > project (this would be Java 9 based) to illustrate the
basic usage of
RMB>>> >>>> CXF from/within green field Java 9
RMB>>> >>>> > modular project (although we may need to do more work
here I suspect).
RMB>>> >>>> Thanks.
RMB>>> >>>> I've opened CXF-7600 for it. What should be the
Automatic-Module-Name
RMB>>> >>>> for cxf-core? Just org.apache.cxf? Or org.apache.cxf.core
which doesn't
RMB>>> >>>> match the package name structure?
RMB>>> >>>> Regards
RMB>>> >>>> Dennis
Re: New Java 9 master
Posted by Andriy Redko <dr...@gmail.com>.
Because it will be **always** named automatically, there is nothing we can do about it. The only thing we can
do is to suggest the better name for automatic naming (which still keeps module in unnamed category). I think the
good example may be a convincing argument towards go / no-go decision, will try to find time to work on it this week.
RMB> Le 3 janv. 2018 18:28, "Andriy Redko" <dr...@gmail.com> a écrit :
RMB> As per my understading of the efforts required (I hope to be wrong here), this is ideal but unrealistic for CXF. We either
RMB> start build some foundation (following other projects), or embark on transforming everything to named modules (and we will be
RMB> affected by all our dependecies anyway, there is nothing we can do about it). I see the first option doable, CXF won't
RMB> able to embrace the migration at once untill all and every dependency we use does the same. This might happen eventually
RMB> but not any time soon for sure :-(
RMB> Why not keeping it unamed then? There are very few adherence on cxf except in integrations, no?
RMB>> This is my first point. Once named and fully migrated you hit both issue: not default classloader and visibility
RMB>> change. First is surely workaround-able but last impacts users so better to let people migrate on java 9...only
RMB>> once and not N times cause CXF didnt embrace it at once. This is my big concern.
RMB>> Le 3 janv. 2018 01:56, "Andriy Redko" <dr...@gmail.com> a écrit :
RMB>> I don't think this is the case actually. If you use CXF as-is right now in modular application, its components will
RMB>> be loaded as automatic modules, implicitly. The only step forward we are taking is to hint JVM what the name of the
RMB>> automatic module should be (instead of relying on the automatic conversions). Rules don't change, the presence
RMB>> of automatic module name in the manifest does not make the JAR a named module, only module-info.java will do that
RMB>> (and this would be a large and risky change indeed). But the presence of the better name would help us to do
RMB>> migration to module-info.java a bit more smoothly, since the module name won't change but semantics of the module
RMB>> will (one by one they should become named modules).
RMB>>> yep
RMB>>> issue is exactly this one: automatic modules are a one way path, you can't go back on manual modules since you
RMB>>> exposed the world and would introduce a breaking change modifying it.
RMB>>> The other one I tried to mentionned is: what about all the cases where CXF will be deployed on java 9 but not in
RMB>>> the root classloader (tomcat to cite a random case) which doesnt support the new SPI loading? You are broken :(
RMB>>> Romain Manni-Bucau
RMB>>> @rmannibucau | Blog | Old Blog | Github | LinkedIn
RMB>>> 2018-01-02 14:54 GMT+01:00 Andriy Redko <dr...@gmail.com>:
RMB>>> I might be mistaken (sorry, haven't worked with Jigsaw closely yet), but I think the service loader would work the same
RMB>>> way in case of named module and automaticaly named module. The only differences would be contraints/rules/visibility: automaticaly
RMB>>> named module just implicitly open/export/import everything while named module should be picky and precise.
RMB> RMB>>> 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?
RMB> RMB>>> Le 31 déc. 2017 19:15, "Andriy Redko" <dr...@gmail.com> a écrit :
RMB> RMB>>> I am not sure about plugin part, to be honest. I would better craft the module-info.java by hand (but use
RMB> RMB>>> the tooling, jdeps f.e., to get the initial list of modules) and have it in the source tree for each module,
RMB> RMB>>> so to keep the history, etc. That would be aligned with Sergey's suggestion to have Java 9 master sometime
RMB> RMB>>> in the future.
RMB> RMB>>> But, by and large, you may be right and the plugin is the viable option. Still, if 99% of the CXF dependencies are
RMB> RMB>>> going to be automatic modules nonetheless, what it will buy us? And looking into other projects, that seems to
RMB> RMB>>> be the starting point for many. Anyway, I would prefer to get it all and right now :-D but realistically, I see
RMB> RMB>>> the automatic module name to be the less riskier approach to begin with (just a manifest change), not necessarily
RMB> RMB>>> the best one though.
RMB> RMB>>> Best Regards,
RMB> RMB>>> Andriy Redko
RMB>> 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>> RMB>>> why I proposed them - because you can create the module-info.java with java 8. This is what does the plugin I
RMB>> RMB>>> mentionned, writing it directly with java 9 (long story short it has a module-info parser and writer).
RMB>> RMB>>> Romain Manni-Bucau
RMB>> RMB>>> @rmannibucau | Blog | Old Blog | Github | LinkedIn
RMB>> RMB>>> 2017-12-31 16:58 GMT+01:00 Andriy Redko <dr...@gmail.com>:
RMB>> RMB>>> Hi Romain,
RMB>> RMB>>> I think there are 2 parts regarding modules: 1) using CXF from modularized
RMB>> RMB>>> applications and 2) release/redesign CXF in a modular fashion (I mean Java 9 modules).
RMB>> RMB>>> The 2nd part is where we are heading eventually but we won't be trully modular till
RMB>> RMB>>> all our dependencies are available as modules as well. The idea of adding
RMB>> RMB>>> automatic module name is helping out with the 1st part. Regarding your questions
RMB>> RMB>>> though:
RMB>> RMB>>> 1. Adding module-info.java would mean, at least, to branch the artifacts (java9+ / java8).
RMB>> RMB>>> 2. Yes, I think it makes sense, this is the recommended way, but we should better make a
RMB>> RMB>>> proposal first (as part of the JIRA Dennis created).
RMB>> RMB>>> 3. I think this is the only way (as module-info.java won't compile with Java 8)
RMB>> RMB>>> Automatic modules is a good start (arguably, for sure), because from the efforts
RMB>> RMB>>> perspetive, it looks doable in a short time vs adding proper module-info.java to
RMB>> RMB>>> each module, which would take significantly more. Thoughts?
RMB>> RMB>>> Best Regards,
RMB>> RMB>>> Andriy Redko
RMB>>> RMB>>> Hi guys,
RMB>>> RMB>>> Few random notes/questions:
RMB>>> RMB>>> 1. Why not using https://github.com/moditect/moditect/blob/master/README.md
RMB>>> RMB>>> and assume the moduleinfo instead of working it around with automatic
RMB>>> RMB>>> module name?
RMB>>> RMB>>> 2. For the naming it should really be someting like $group.$module IMO,
RMB>>> RMB>>> probably with underscores instead of iphens for the module and maybe
RMB>>> RMB>>> removing cxf from the module dince it is in the package
RMB>>> RMB>>> 3. Is it possible to double relezse each module, one with the module info
RMB>>> RMB>>> (if you do 1, or without the automatic module name if you dont) and a
RMB>>> RMB>>> qualifier jdk9 and keep current ones as today until the whole stack is java
RMB>>> RMB>>> 9 (transitively). Easy to break consumers otherwise.
RMB>>> RMB>>> Le 31 déc. 2017 13:38, "Dennis Kieselhorst" <ma...@dekies.de> a écrit :
RMB>>> >>>> > Exactly, that's the idea, updating the manifest with
RMB>>> >>>> Automatic-Module-Name. We could also add a sample
RMB>>> >>>> > project (this would be Java 9 based) to illustrate the basic usage of
RMB>>> >>>> CXF from/within green field Java 9
RMB>>> >>>> > modular project (although we may need to do more work here I suspect).
RMB>>> >>>> Thanks.
RMB>>> >>>> I've opened CXF-7600 for it. What should be the Automatic-Module-Name
RMB>>> >>>> for cxf-core? Just org.apache.cxf? Or org.apache.cxf.core which doesn't
RMB>>> >>>> match the package name structure?
RMB>>> >>>> Regards
RMB>>> >>>> Dennis
Re: New Java 9 master
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 3 janv. 2018 18:28, "Andriy Redko" <dr...@gmail.com> a écrit :
As per my understading of the efforts required (I hope to be wrong here),
this is ideal but unrealistic for CXF. We either
start build some foundation (following other projects), or embark on
transforming everything to named modules (and we will be
affected by all our dependecies anyway, there is nothing we can do about
it). I see the first option doable, CXF won't
able to embrace the migration at once untill all and every dependency we
use does the same. This might happen eventually
but not any time soon for sure :-(
Why not keeping it unamed then? There are very few adherence on cxf except
in integrations, no?
RMB> This is my first point. Once named and fully migrated you hit both
issue: not default classloader and visibility
RMB> change. First is surely workaround-able but last impacts users so
better to let people migrate on java 9...only
RMB> once and not N times cause CXF didnt embrace it at once. This is my
big concern.
RMB> Le 3 janv. 2018 01:56, "Andriy Redko" <dr...@gmail.com> a écrit :
RMB> I don't think this is the case actually. If you use CXF as-is right
now in modular application, its components will
RMB> be loaded as automatic modules, implicitly. The only step forward we
are taking is to hint JVM what the name of the
RMB> automatic module should be (instead of relying on the automatic
conversions). Rules don't change, the presence
RMB> of automatic module name in the manifest does not make the JAR a
named module, only module-info.java will do that
RMB> (and this would be a large and risky change indeed). But the presence
of the better name would help us to do
RMB> migration to module-info.java a bit more smoothly, since the module
name won't change but semantics of the module
RMB> will (one by one they should become named modules).
RMB>> yep
RMB>> issue is exactly this one: automatic modules are a one way path, you
can't go back on manual modules since you
RMB>> exposed the world and would introduce a breaking change modifying it.
RMB>> The other one I tried to mentionned is: what about all the cases
where CXF will be deployed on java 9 but not in
RMB>> the root classloader (tomcat to cite a random case) which doesnt
support the new SPI loading? You are broken :(
RMB>> Romain Manni-Bucau
RMB>> @rmannibucau | Blog | Old Blog | Github | LinkedIn
RMB>> 2018-01-02 14:54 GMT+01:00 Andriy Redko <dr...@gmail.com>:
RMB>> I might be mistaken (sorry, haven't worked with Jigsaw closely yet),
but I think the service loader would work the same
RMB>> way in case of named module and automaticaly named module. The only
differences would be contraints/rules/visibility: automaticaly
RMB>> named module just implicitly open/export/import everything while
named module should be picky and precise.
RMB>>> 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?
RMB>>> Le 31 déc. 2017 19:15, "Andriy Redko" <dr...@gmail.com> a écrit :
RMB>>> I am not sure about plugin part, to be honest. I would better
craft the module-info.java by hand (but use
RMB>>> the tooling, jdeps f.e., to get the initial list of modules) and
have it in the source tree for each module,
RMB>>> so to keep the history, etc. That would be aligned with Sergey's
suggestion to have Java 9 master sometime
RMB>>> in the future.
RMB>>> But, by and large, you may be right and the plugin is the viable
option. Still, if 99% of the CXF dependencies are
RMB>>> going to be automatic modules nonetheless, what it will buy us?
And looking into other projects, that seems to
RMB>>> be the starting point for many. Anyway, I would prefer to get it
all and right now :-D but realistically, I see
RMB>>> the automatic module name to be the less riskier approach to
begin with (just a manifest change), not necessarily
RMB>>> the best one though.
RMB>>> Best Regards,
RMB>>> Andriy Redko
RMB> 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> RMB>>> why I proposed them - because you can create the
module-info.java with java 8. This is what does the plugin I
RMB> RMB>>> mentionned, writing it directly with java 9 (long story
short it has a module-info parser and writer).
RMB> RMB>>> Romain Manni-Bucau
RMB> RMB>>> @rmannibucau | Blog | Old Blog | Github | LinkedIn
RMB> RMB>>> 2017-12-31 16:58 GMT+01:00 Andriy Redko <dr...@gmail.com>:
RMB> RMB>>> Hi Romain,
RMB> RMB>>> I think there are 2 parts regarding modules: 1) using CXF
from modularized
RMB> RMB>>> applications and 2) release/redesign CXF in a modular
fashion (I mean Java 9 modules).
RMB> RMB>>> The 2nd part is where we are heading eventually but we
won't be trully modular till
RMB> RMB>>> all our dependencies are available as modules as well. The
idea of adding
RMB> RMB>>> automatic module name is helping out with the 1st part.
Regarding your questions
RMB> RMB>>> though:
RMB> RMB>>> 1. Adding module-info.java would mean, at least, to branch
the artifacts (java9+ / java8).
RMB> RMB>>> 2. Yes, I think it makes sense, this is the recommended
way, but we should better make a
RMB> RMB>>> proposal first (as part of the JIRA Dennis created).
RMB> RMB>>> 3. I think this is the only way (as module-info.java won't
compile with Java 8)
RMB> RMB>>> Automatic modules is a good start (arguably, for sure),
because from the efforts
RMB> RMB>>> perspetive, it looks doable in a short time vs adding
proper module-info.java to
RMB> RMB>>> each module, which would take significantly more. Thoughts?
RMB> RMB>>> Best Regards,
RMB> RMB>>> Andriy Redko
RMB>> RMB>>> Hi guys,
RMB>> RMB>>> Few random notes/questions:
RMB>> RMB>>> 1. Why not using https://github.com/moditect/
moditect/blob/master/README.md
RMB>> RMB>>> and assume the moduleinfo instead of working it around
with automatic
RMB>> RMB>>> module name?
RMB>> RMB>>> 2. For the naming it should really be someting like
$group.$module IMO,
RMB>> RMB>>> probably with underscores instead of iphens for the module
and maybe
RMB>> RMB>>> removing cxf from the module dince it is in the package
RMB>> RMB>>> 3. Is it possible to double relezse each module, one with
the module info
RMB>> RMB>>> (if you do 1, or without the automatic module name if you
dont) and a
RMB>> RMB>>> qualifier jdk9 and keep current ones as today until the
whole stack is java
RMB>> RMB>>> 9 (transitively). Easy to break consumers otherwise.
RMB>> RMB>>> Le 31 déc. 2017 13:38, "Dennis Kieselhorst" <ma...@dekies.de>
a écrit :
RMB>> >>>> > Exactly, that's the idea, updating the manifest with
RMB>> >>>> Automatic-Module-Name. We could also add a sample
RMB>> >>>> > project (this would be Java 9 based) to illustrate the
basic usage of
RMB>> >>>> CXF from/within green field Java 9
RMB>> >>>> > modular project (although we may need to do more work here
I suspect).
RMB>> >>>> Thanks.
RMB>> >>>> I've opened CXF-7600 for it. What should be the
Automatic-Module-Name
RMB>> >>>> for cxf-core? Just org.apache.cxf? Or org.apache.cxf.core
which doesn't
RMB>> >>>> match the package name structure?
RMB>> >>>> Regards
RMB>> >>>> Dennis
Re: New Java 9 master
Posted by Andriy Redko <dr...@gmail.com>.
As per my understading of the efforts required (I hope to be wrong here), this is ideal but unrealistic for CXF. We either
start build some foundation (following other projects), or embark on transforming everything to named modules (and we will be
affected by all our dependecies anyway, there is nothing we can do about it). I see the first option doable, CXF won't
able to embrace the migration at once untill all and every dependency we use does the same. This might happen eventually
but not any time soon for sure :-(
RMB> This is my first point. Once named and fully migrated you hit both issue: not default classloader and visibility
RMB> change. First is surely workaround-able but last impacts users so better to let people migrate on java 9...only
RMB> once and not N times cause CXF didnt embrace it at once. This is my big concern.
RMB> Le 3 janv. 2018 01:56, "Andriy Redko" <dr...@gmail.com> a écrit :
RMB> I don't think this is the case actually. If you use CXF as-is right now in modular application, its components will
RMB> be loaded as automatic modules, implicitly. The only step forward we are taking is to hint JVM what the name of the
RMB> automatic module should be (instead of relying on the automatic conversions). Rules don't change, the presence
RMB> of automatic module name in the manifest does not make the JAR a named module, only module-info.java will do that
RMB> (and this would be a large and risky change indeed). But the presence of the better name would help us to do
RMB> migration to module-info.java a bit more smoothly, since the module name won't change but semantics of the module
RMB> will (one by one they should become named modules).
RMB>> yep
RMB>> issue is exactly this one: automatic modules are a one way path, you can't go back on manual modules since you
RMB>> exposed the world and would introduce a breaking change modifying it.
RMB>> The other one I tried to mentionned is: what about all the cases where CXF will be deployed on java 9 but not in
RMB>> the root classloader (tomcat to cite a random case) which doesnt support the new SPI loading? You are broken :(
RMB>> Romain Manni-Bucau
RMB>> @rmannibucau | Blog | Old Blog | Github | LinkedIn
RMB>> 2018-01-02 14:54 GMT+01:00 Andriy Redko <dr...@gmail.com>:
RMB>> I might be mistaken (sorry, haven't worked with Jigsaw closely yet), but I think the service loader would work the same
RMB>> way in case of named module and automaticaly named module. The only differences would be contraints/rules/visibility: automaticaly
RMB>> named module just implicitly open/export/import everything while named module should be picky and precise.
RMB>>> 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?
RMB>>> Le 31 déc. 2017 19:15, "Andriy Redko" <dr...@gmail.com> a écrit :
RMB>>> I am not sure about plugin part, to be honest. I would better craft the module-info.java by hand (but use
RMB>>> the tooling, jdeps f.e., to get the initial list of modules) and have it in the source tree for each module,
RMB>>> so to keep the history, etc. That would be aligned with Sergey's suggestion to have Java 9 master sometime
RMB>>> in the future.
RMB>>> But, by and large, you may be right and the plugin is the viable option. Still, if 99% of the CXF dependencies are
RMB>>> going to be automatic modules nonetheless, what it will buy us? And looking into other projects, that seems to
RMB>>> be the starting point for many. Anyway, I would prefer to get it all and right now :-D but realistically, I see
RMB>>> the automatic module name to be the less riskier approach to begin with (just a manifest change), not necessarily
RMB>>> the best one though.
RMB>>> Best Regards,
RMB>>> Andriy Redko
RMB> 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> RMB>>> why I proposed them - because you can create the module-info.java with java 8. This is what does the plugin I
RMB> RMB>>> mentionned, writing it directly with java 9 (long story short it has a module-info parser and writer).
RMB> RMB>>> Romain Manni-Bucau
RMB> RMB>>> @rmannibucau | Blog | Old Blog | Github | LinkedIn
RMB> RMB>>> 2017-12-31 16:58 GMT+01:00 Andriy Redko <dr...@gmail.com>:
RMB> RMB>>> Hi Romain,
RMB> RMB>>> I think there are 2 parts regarding modules: 1) using CXF from modularized
RMB> RMB>>> applications and 2) release/redesign CXF in a modular fashion (I mean Java 9 modules).
RMB> RMB>>> The 2nd part is where we are heading eventually but we won't be trully modular till
RMB> RMB>>> all our dependencies are available as modules as well. The idea of adding
RMB> RMB>>> automatic module name is helping out with the 1st part. Regarding your questions
RMB> RMB>>> though:
RMB> RMB>>> 1. Adding module-info.java would mean, at least, to branch the artifacts (java9+ / java8).
RMB> RMB>>> 2. Yes, I think it makes sense, this is the recommended way, but we should better make a
RMB> RMB>>> proposal first (as part of the JIRA Dennis created).
RMB> RMB>>> 3. I think this is the only way (as module-info.java won't compile with Java 8)
RMB> RMB>>> Automatic modules is a good start (arguably, for sure), because from the efforts
RMB> RMB>>> perspetive, it looks doable in a short time vs adding proper module-info.java to
RMB> RMB>>> each module, which would take significantly more. Thoughts?
RMB> RMB>>> Best Regards,
RMB> RMB>>> Andriy Redko
RMB>> RMB>>> Hi guys,
RMB>> RMB>>> Few random notes/questions:
RMB>> RMB>>> 1. Why not using https://github.com/moditect/moditect/blob/master/README.md
RMB>> RMB>>> and assume the moduleinfo instead of working it around with automatic
RMB>> RMB>>> module name?
RMB>> RMB>>> 2. For the naming it should really be someting like $group.$module IMO,
RMB>> RMB>>> probably with underscores instead of iphens for the module and maybe
RMB>> RMB>>> removing cxf from the module dince it is in the package
RMB>> RMB>>> 3. Is it possible to double relezse each module, one with the module info
RMB>> RMB>>> (if you do 1, or without the automatic module name if you dont) and a
RMB>> RMB>>> qualifier jdk9 and keep current ones as today until the whole stack is java
RMB>> RMB>>> 9 (transitively). Easy to break consumers otherwise.
RMB>> RMB>>> Le 31 déc. 2017 13:38, "Dennis Kieselhorst" <ma...@dekies.de> a écrit :
RMB>> >>>> > Exactly, that's the idea, updating the manifest with
RMB>> >>>> Automatic-Module-Name. We could also add a sample
RMB>> >>>> > project (this would be Java 9 based) to illustrate the basic usage of
RMB>> >>>> CXF from/within green field Java 9
RMB>> >>>> > modular project (although we may need to do more work here I suspect).
RMB>> >>>> Thanks.
RMB>> >>>> I've opened CXF-7600 for it. What should be the Automatic-Module-Name
RMB>> >>>> for cxf-core? Just org.apache.cxf? Or org.apache.cxf.core which doesn't
RMB>> >>>> match the package name structure?
RMB>> >>>> Regards
RMB>> >>>> Dennis
Re: New Java 9 master
Posted by Romain Manni-Bucau <rm...@gmail.com>.
This is my first point. Once named and fully migrated you hit both issue:
not default classloader and visibility change. First is surely
workaround-able but last impacts users so better to let people migrate on
java 9...only once and not N times cause CXF didnt embrace it at once. This
is my big concern.
Le 3 janv. 2018 01:56, "Andriy Redko" <dr...@gmail.com> a écrit :
> I don't think this is the case actually. If you use CXF as-is right now in
> modular application, its components will
> be loaded as automatic modules, implicitly. The only step forward we are
> taking is to hint JVM what the name of the
> automatic module should be (instead of relying on the automatic
> conversions). Rules don't change, the presence
> of automatic module name in the manifest does not make the JAR a named
> module, only module-info.java will do that
> (and this would be a large and risky change indeed). But the presence of
> the better name would help us to do
> migration to module-info.java a bit more smoothly, since the module name
> won't change but semantics of the module
> will (one by one they should become named modules).
>
>
>
> RMB> yep
>
>
> RMB> issue is exactly this one: automatic modules are a one way path, you
> can't go back on manual modules since you
> RMB> exposed the world and would introduce a breaking change modifying it.
> RMB> The other one I tried to mentionned is: what about all the cases
> where CXF will be deployed on java 9 but not in
> RMB> the root classloader (tomcat to cite a random case) which doesnt
> support the new SPI loading? You are broken :(
>
>
> RMB> Romain Manni-Bucau
> RMB> @rmannibucau | Blog | Old Blog | Github | LinkedIn
>
> RMB> 2018-01-02 14:54 GMT+01:00 Andriy Redko <dr...@gmail.com>:
>
> RMB> I might be mistaken (sorry, haven't worked with Jigsaw closely yet),
> but I think the service loader would work the same
> RMB> way in case of named module and automaticaly named module. The only
> differences would be contraints/rules/visibility: automaticaly
> RMB> named module just implicitly open/export/import everything while
> named module should be picky and precise.
>
> RMB>> 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?
>
>
>
> RMB>> Le 31 déc. 2017 19:15, "Andriy Redko" <dr...@gmail.com> a écrit :
>
> RMB>> I am not sure about plugin part, to be honest. I would better craft
> the module-info.java by hand (but use
> RMB>> the tooling, jdeps f.e., to get the initial list of modules) and
> have it in the source tree for each module,
> RMB>> so to keep the history, etc. That would be aligned with Sergey's
> suggestion to have Java 9 master sometime
> RMB>> in the future.
>
> RMB>> But, by and large, you may be right and the plugin is the viable
> option. Still, if 99% of the CXF dependencies are
> RMB>> going to be automatic modules nonetheless, what it will buy us?
> And looking into other projects, that seems to
> RMB>> be the starting point for many. Anyway, I would prefer to get it
> all and right now :-D but realistically, I see
> RMB>> the automatic module name to be the less riskier approach to begin
> with (just a manifest change), not necessarily
> RMB>> the best one though.
>
>
>
>
>
> RMB>> Best Regards,
> RMB>> 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 <dr...@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> RMB>>> Hi guys,
>
> RMB> RMB>>> Few random notes/questions:
>
> RMB> RMB>>> 1. Why not using https://github.com/moditect/
> moditect/blob/master/README.md
> RMB> RMB>>> and assume the moduleinfo instead of working it around with
> automatic
> RMB> RMB>>> module name?
> RMB> RMB>>> 2. For the naming it should really be someting like
> $group.$module IMO,
> RMB> RMB>>> probably with underscores instead of iphens for the module
> and maybe
> RMB> RMB>>> removing cxf from the module dince it is in the package
> RMB> RMB>>> 3. Is it possible to double relezse each module, one with
> the module info
> RMB> RMB>>> (if you do 1, or without the automatic module name if you
> dont) and a
> RMB> RMB>>> qualifier jdk9 and keep current ones as today until the
> whole stack is java
> RMB> RMB>>> 9 (transitively). Easy to break consumers otherwise.
>
>
> RMB> RMB>>> Le 31 déc. 2017 13:38, "Dennis Kieselhorst" <ma...@dekies.de>
> a écrit :
>
>
> RMB> >>>> > Exactly, that's the idea, updating the manifest with
> RMB> >>>> Automatic-Module-Name. We could also add a sample
> RMB> >>>> > project (this would be Java 9 based) to illustrate the
> basic usage of
> RMB> >>>> CXF from/within green field Java 9
> RMB> >>>> > modular project (although we may need to do more work here
> I suspect).
> RMB> >>>> Thanks.
> RMB> >>>> I've opened CXF-7600 for it. What should be the
> Automatic-Module-Name
> RMB> >>>> for cxf-core? Just org.apache.cxf? Or org.apache.cxf.core
> which doesn't
> RMB> >>>> match the package name structure?
>
> RMB> >>>> Regards
> RMB> >>>> Dennis
>
>
>
>
>
>
>
>
>
>
>
>
>
>
Re: New Java 9 master
Posted by Andriy Redko <dr...@gmail.com>.
I don't think this is the case actually. If you use CXF as-is right now in modular application, its components will
be loaded as automatic modules, implicitly. The only step forward we are taking is to hint JVM what the name of the
automatic module should be (instead of relying on the automatic conversions). Rules don't change, the presence
of automatic module name in the manifest does not make the JAR a named module, only module-info.java will do that
(and this would be a large and risky change indeed). But the presence of the better name would help us to do
migration to module-info.java a bit more smoothly, since the module name won't change but semantics of the module
will (one by one they should become named modules).
RMB> yep
RMB> issue is exactly this one: automatic modules are a one way path, you can't go back on manual modules since you
RMB> exposed the world and would introduce a breaking change modifying it.
RMB> The other one I tried to mentionned is: what about all the cases where CXF will be deployed on java 9 but not in
RMB> the root classloader (tomcat to cite a random case) which doesnt support the new SPI loading? You are broken :(
RMB> Romain Manni-Bucau
RMB> @rmannibucau | Blog | Old Blog | Github | LinkedIn
RMB> 2018-01-02 14:54 GMT+01:00 Andriy Redko <dr...@gmail.com>:
RMB> I might be mistaken (sorry, haven't worked with Jigsaw closely yet), but I think the service loader would work the same
RMB> way in case of named module and automaticaly named module. The only differences would be contraints/rules/visibility: automaticaly
RMB> named module just implicitly open/export/import everything while named module should be picky and precise.
RMB>> 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?
RMB>> Le 31 déc. 2017 19:15, "Andriy Redko" <dr...@gmail.com> a écrit :
RMB>> I am not sure about plugin part, to be honest. I would better craft the module-info.java by hand (but use
RMB>> the tooling, jdeps f.e., to get the initial list of modules) and have it in the source tree for each module,
RMB>> so to keep the history, etc. That would be aligned with Sergey's suggestion to have Java 9 master sometime
RMB>> in the future.
RMB>> But, by and large, you may be right and the plugin is the viable option. Still, if 99% of the CXF dependencies are
RMB>> going to be automatic modules nonetheless, what it will buy us? And looking into other projects, that seems to
RMB>> be the starting point for many. Anyway, I would prefer to get it all and right now :-D but realistically, I see
RMB>> the automatic module name to be the less riskier approach to begin with (just a manifest change), not necessarily
RMB>> the best one though.
RMB>> Best Regards,
RMB>> 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 <dr...@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> RMB>>> Hi guys,
RMB> RMB>>> Few random notes/questions:
RMB> RMB>>> 1. Why not using https://github.com/moditect/moditect/blob/master/README.md
RMB> RMB>>> and assume the moduleinfo instead of working it around with automatic
RMB> RMB>>> module name?
RMB> RMB>>> 2. For the naming it should really be someting like $group.$module IMO,
RMB> RMB>>> probably with underscores instead of iphens for the module and maybe
RMB> RMB>>> removing cxf from the module dince it is in the package
RMB> RMB>>> 3. Is it possible to double relezse each module, one with the module info
RMB> RMB>>> (if you do 1, or without the automatic module name if you dont) and a
RMB> RMB>>> qualifier jdk9 and keep current ones as today until the whole stack is java
RMB> RMB>>> 9 (transitively). Easy to break consumers otherwise.
RMB> RMB>>> Le 31 déc. 2017 13:38, "Dennis Kieselhorst" <ma...@dekies.de> a écrit :
RMB> >>>> > Exactly, that's the idea, updating the manifest with
RMB> >>>> Automatic-Module-Name. We could also add a sample
RMB> >>>> > project (this would be Java 9 based) to illustrate the basic usage of
RMB> >>>> CXF from/within green field Java 9
RMB> >>>> > modular project (although we may need to do more work here I suspect).
RMB> >>>> Thanks.
RMB> >>>> I've opened CXF-7600 for it. What should be the Automatic-Module-Name
RMB> >>>> for cxf-core? Just org.apache.cxf? Or org.apache.cxf.core which doesn't
RMB> >>>> match the package name structure?
RMB> >>>> Regards
RMB> >>>> Dennis
Re: New Java 9 master
Posted by Romain Manni-Bucau <rm...@gmail.com>.
yep
issue is exactly this one: automatic modules are a one way path, you can't
go back on manual modules since you exposed the world and would introduce a
breaking change modifying it.
The other one I tried to mentionned is: what about all the cases where CXF
will be deployed on java 9 but not in the root classloader (tomcat to cite
a random case) which doesnt support the new SPI loading? You are broken :(
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau>
2018-01-02 14:54 GMT+01:00 Andriy Redko <dr...@gmail.com>:
> I might be mistaken (sorry, haven't worked with Jigsaw closely yet), but I
> think the service loader would work the same
> way in case of named module and automaticaly named module. The only
> differences would be contraints/rules/visibility: automaticaly
> named module just implicitly open/export/import everything while named
> module should be picky and precise.
>
> RMB> 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?
>
>
>
> RMB> Le 31 déc. 2017 19:15, "Andriy Redko" <dr...@gmail.com> a écrit :
>
> RMB> I am not sure about plugin part, to be honest. I would better craft
> the module-info.java by hand (but use
> RMB> the tooling, jdeps f.e., to get the initial list of modules) and
> have it in the source tree for each module,
> RMB> so to keep the history, etc. That would be aligned with Sergey's
> suggestion to have Java 9 master sometime
> RMB> in the future.
>
> RMB> But, by and large, you may be right and the plugin is the viable
> option. Still, if 99% of the CXF dependencies are
> RMB> going to be automatic modules nonetheless, what it will buy us? And
> looking into other projects, that seems to
> RMB> be the starting point for many. Anyway, I would prefer to get it all
> and right now :-D but realistically, I see
> RMB> the automatic module name to be the less riskier approach to begin
> with (just a manifest change), not necessarily
> RMB> the best one though.
>
>
>
>
> RMB> Best Regards,
> RMB> 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 <dr...@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" <ma...@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
>
>
>
>
>
>
>
>
>
>
>
Re: New Java 9 master
Posted by Andriy Redko <dr...@gmail.com>.
I might be mistaken (sorry, haven't worked with Jigsaw closely yet), but I think the service loader would work the same
way in case of named module and automaticaly named module. The only differences would be contraints/rules/visibility: automaticaly
named module just implicitly open/export/import everything while named module should be picky and precise.
RMB> 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?
RMB> Le 31 déc. 2017 19:15, "Andriy Redko" <dr...@gmail.com> a écrit :
RMB> I am not sure about plugin part, to be honest. I would better craft the module-info.java by hand (but use
RMB> the tooling, jdeps f.e., to get the initial list of modules) and have it in the source tree for each module,
RMB> so to keep the history, etc. That would be aligned with Sergey's suggestion to have Java 9 master sometime
RMB> in the future.
RMB> But, by and large, you may be right and the plugin is the viable option. Still, if 99% of the CXF dependencies are
RMB> going to be automatic modules nonetheless, what it will buy us? And looking into other projects, that seems to
RMB> be the starting point for many. Anyway, I would prefer to get it all and right now :-D but realistically, I see
RMB> the automatic module name to be the less riskier approach to begin with (just a manifest change), not necessarily
RMB> the best one though.
RMB> Best Regards,
RMB> 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 <dr...@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" <ma...@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
Re: New Java 9 master
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 31 déc. 2017 19:15, "Andriy Redko" <dr...@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 <dr...@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" <ma...@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
Re: New Java 9 master
Posted by Andriy Redko <dr...@gmail.com>.
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.
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 <dr...@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" <ma...@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
Re: New Java 9 master
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 why I proposed them - because you can
create the module-info.java with java 8. This is what does the plugin I
mentionned, writing it directly with java 9 (long story short it has a
module-info parser and writer).
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau>
2017-12-31 16:58 GMT+01:00 Andriy Redko <dr...@gmail.com>:
> Hi Romain,
>
> I think there are 2 parts regarding modules: 1) using CXF from modularized
> applications and 2) release/redesign CXF in a modular fashion (I mean Java
> 9 modules).
> The 2nd part is where we are heading eventually but we won't be trully
> modular till
> all our dependencies are available as modules as well. The idea of adding
> automatic module name is helping out with the 1st part. Regarding your
> questions
> though:
>
> 1. Adding module-info.java would mean, at least, to branch the artifacts
> (java9+ / java8).
> 2. Yes, I think it makes sense, this is the recommended way, but we should
> better make a
> proposal first (as part of the JIRA Dennis created).
> 3. I think this is the only way (as module-info.java won't compile with
> Java 8)
>
> Automatic modules is a good start (arguably, for sure), because from the
> efforts
> perspetive, it looks doable in a short time vs adding proper
> module-info.java to
> each module, which would take significantly more. Thoughts?
>
> Best Regards,
> 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" <ma...@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
>
>
>
>
>
Re: New Java 9 master
Posted by Andriy Redko <dr...@gmail.com>.
Hi Romain,
I think there are 2 parts regarding modules: 1) using CXF from modularized
applications and 2) release/redesign CXF in a modular fashion (I mean Java 9 modules).
The 2nd part is where we are heading eventually but we won't be trully modular till
all our dependencies are available as modules as well. The idea of adding
automatic module name is helping out with the 1st part. Regarding your questions
though:
1. Adding module-info.java would mean, at least, to branch the artifacts (java9+ / java8).
2. Yes, I think it makes sense, this is the recommended way, but we should better make a
proposal first (as part of the JIRA Dennis created).
3. I think this is the only way (as module-info.java won't compile with Java 8)
Automatic modules is a good start (arguably, for sure), because from the efforts
perspetive, it looks doable in a short time vs adding proper module-info.java to
each module, which would take significantly more. Thoughts?
Best Regards,
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" <ma...@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
Re: New Java 9 master
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi guys,
Few random notes/questions:
1. Why not using https://github.com/moditect/moditect/blob/master/README.md
and assume the moduleinfo instead of working it around with automatic
module name?
2. For the naming it should really be someting like $group.$module IMO,
probably with underscores instead of iphens for the module and maybe
removing cxf from the module dince it is in the package
3. Is it possible to double relezse each module, one with the module info
(if you do 1, or without the automatic module name if you dont) and a
qualifier jdk9 and keep current ones as today until the whole stack is java
9 (transitively). Easy to break consumers otherwise.
Le 31 déc. 2017 13:38, "Dennis Kieselhorst" <ma...@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
>
>
>
Re: New Java 9 master
Posted by Dennis Kieselhorst <ma...@dekies.de>.
> 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
Re: New Java 9 master
Posted by Andriy Redko <dr...@gmail.com>.
Hey,
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.
Best Regards,
Andriy Redko
DK> Hey,
DK> I would simply apply Automatic-Module-Name to existing master as the
DK> Commons guys did.
DK> See also: https://github.com/jodastephen/jpms-module-names
DK> Merry xmas
DK> Dennis
Re: New Java 9 master
Posted by Dennis Kieselhorst <ma...@dekies.de>.
Hey,
I would simply apply Automatic-Module-Name to existing master as the
Commons guys did.
See also: https://github.com/jodastephen/jpms-module-names
Merry xmas
Dennis