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