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" <[email protected]> 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 <[email protected]>:

 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" <[email protected]> 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










Reply via email to