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 2018/01/02 13:54:10 UTC
Re: New Java 9 master
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>.
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
>
>
>
>
>
>
>
>
>
>
>