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 <drr...@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" <drr...@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 <drr...@gmail.com>: > > RMB>> Hi Romain, > > RMB>> I think there are 2 parts regarding modules: 1) using CXF from > modularized > RMB>> applications and 2) release/redesign CXF in a modular fashion (I > mean Java 9 modules). > RMB>> The 2nd part is where we are heading eventually but we won't be > trully modular till > RMB>> all our dependencies are available as modules as well. The idea of > adding > RMB>> automatic module name is helping out with the 1st part. Regarding > your questions > RMB>> though: > > RMB>> 1. Adding module-info.java would mean, at least, to branch the > artifacts (java9+ / java8). > RMB>> 2. Yes, I think it makes sense, this is the recommended way, but > we should better make a > RMB>> proposal first (as part of the JIRA Dennis created). > RMB>> 3. I think this is the only way (as module-info.java won't compile > with Java 8) > > RMB>> Automatic modules is a good start (arguably, for sure), because > from the efforts > RMB>> perspetive, it looks doable in a short time vs adding proper > module-info.java to > RMB>> each module, which would take significantly more. Thoughts? > > RMB>> Best Regards, > RMB>> Andriy Redko > > > RMB>>> Hi guys, > > RMB>>> Few random notes/questions: > > RMB>>> 1. Why not using https://github.com/moditect/ > moditect/blob/master/README.md > RMB>>> and assume the moduleinfo instead of working it around with > automatic > RMB>>> module name? > RMB>>> 2. For the naming it should really be someting like > $group.$module IMO, > RMB>>> probably with underscores instead of iphens for the module and > maybe > RMB>>> removing cxf from the module dince it is in the package > RMB>>> 3. Is it possible to double relezse each module, one with the > module info > RMB>>> (if you do 1, or without the automatic module name if you dont) > and a > RMB>>> qualifier jdk9 and keep current ones as today until the whole > stack is java > RMB>>> 9 (transitively). Easy to break consumers otherwise. > > > RMB>>> Le 31 déc. 2017 13:38, "Dennis Kieselhorst" <m...@dekies.de> a > écrit : > > > >>>> > Exactly, that's the idea, updating the manifest with > >>>> Automatic-Module-Name. We could also add a sample > >>>> > project (this would be Java 9 based) to illustrate the basic > usage of > >>>> CXF from/within green field Java 9 > >>>> > modular project (although we may need to do more work here I > suspect). > >>>> Thanks. > >>>> I've opened CXF-7600 for it. What should be the > Automatic-Module-Name > >>>> for cxf-core? Just org.apache.cxf? Or org.apache.cxf.core which > doesn't > >>>> match the package name structure? > > >>>> Regards > >>>> Dennis > > > > > > > > > > >
