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" <drr...@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 <drr...@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" <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> 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" <m...@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 > > > > > > > > > > > > > >
