Community
Participate
Working Groups
I have released some change in Core for creating a module-info from a given IPackageFragmentRoot. The changes are here: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?h=BETA_JAVA9&id=b9da98e4a12f82e982be70838141e32cdd231156 The API is not ideal. Ideally we want it to return something like IModule or something like that. But because we don't have a module representation in Java model and DOM, we will have to settle for this for now. The command can take this string and put it into a unit name module-info.java directly under the package fragment root.
The command/tool will be invoked at the package fragment root (source folder) and will create a module-info.java file (adding the file content received from jdt.core API) in the default package of that source folder. This is similar to bug 482582 and the same option added for that bug can by used as the tool to convert the root to module (by creating the module-info.java file in its default package). I will complete the patch for bug 482582 and will use the new JavaCore#createModuleFromPackageRoot API for the file content.
(In reply to Noopur Gupta from comment #1) > The command/tool will be invoked at the package fragment root (source > folder) and will create a module-info.java file (adding the file content > received from jdt.core API) in the default package of that source folder. > > This is similar to bug 482582 and the same option added for that bug can by > used as the tool to convert the root to module (by creating the > module-info.java file in its default package). > > I will complete the patch for bug 482582 and will use the new > JavaCore#createModuleFromPackageRoot API for the file content. Released the patch for bug 482582 which can be used for ECNA demo as the migration command. If required, this can be added as a separate action later on.
The action will be available in the "Configure" context menu on a project and will create the module-info.java file. Changes from bug 482582 will be reverted.
New Gerrit change created: https://git.eclipse.org/r/80783
*** Bug 482582 has been marked as a duplicate of this bug. ***
(In reply to Eclipse Genie from comment #4) > New Gerrit change created: https://git.eclipse.org/r/80783 This patch reverts the changes from bug 482582 and adds a context menu option "Create module-info.java" under the "Configure" context menu on a project with java nature (includes plug-in projects). It creates the module-info.java file in the default package of the first source folder. If a module-info.java file already exists in the default package of any source folder in that project, the user is given the option to overwrite it. If the project has a compliance level below 9, an error message is shown currently. We can improve it later to change the project to 9, if required. For the file contents, the temporary API from comment #0 is used. Jay, please have a look at the behavior (CreateModuleInfoAction.java) and suggest if changes are required. Also, provide the final API which can be used instead of the API from comment #0.
(In reply to Noopur Gupta from comment #6) > Jay, please have a look at the behavior (CreateModuleInfoAction.java) and > suggest if changes are required. Also, provide the final API which can be > used instead of the API from comment #0. Looks good. I came across few bugs in the module descriptor's content, though. That part needs significant changes anyway. So, would returning a JavaModel (let's say IModule) be enough? There's a version of this exists without much documentation already. Or do you need a assistance from DOM side as well somehow?
(In reply to Jay Arthanareeswaran from comment #7) > So, would returning a JavaModel (let's say IModule) be enough? There's a > version of this exists without much documentation already. > > Or do you need a assistance from DOM side as well somehow? Java model API(s) should be good enough to create the contents of module-info.java file here.
What's the state here?
I had changed the API being used by UI but then reverted it to keep the build going. The revert was this: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?h=BETA_JAVA9&id=279152beda9141939083ad9ed1f5782eb729f730 If we could agree on a time for simultaneous release, I can put that change back in. The new API now takes a IJavaProject instead of a package fragment root and returns an IModuleDescription instead of a String.
Created attachment 265006 [details] Updated UI patch Updated the UI patch. This should go with the new Core API. But we need to have a careful look at the API if it were to be permanent solution. For two reasons: 1. This seems out of place in a global API like JavaCore. 2. The API is going to return a handle only Java element that doesn't exist. So, the utility that constructs the module has to ensure that the element infos are not read. The client code must also ensure that it only accesses the information that is intended. Now, what is intended to be accessed is a sub-set of what the module element 'can' contain, so the client must not try to access other information. I will also attach a patch for core that goes with this patch.
Created attachment 265007 [details] Core part Patch for the Core part. The patch I added for UI needs close inspection. I only put that code for testing, I am not sure if that's the right way to create a file content. For e.g., I have hard-coded the line delimiter.
(In reply to Jay Arthanareeswaran from comment #10) > If we could agree on a time for simultaneous release, I can put that change > back in. The new API now takes a IJavaProject instead of a package fragment > root and returns an IModuleDescription instead of a String. Jay, I am having a look at the updated patch from comment #11 which uses the new API and making the necessary changes now. We can commit the patches after that.
Created attachment 265020 [details] Updated UI patch Attaching the updated UI patch based on the patch from comment #11: - Using the line delimiter which is used by the specified project. - For indentation, the patch still uses: fileContent.append('\t'); I assume this should not be required and the file should be formatted correctly by the formatter. But currently, the formatter doesn't work with CodeFormatter.K_COMPILATION_UNIT for module-info.java file. Reported bug 506430 for this. - Removed the code from the patch which adds "to" and "public" in the file as I don't think these details will be available and should be added when a module-info.java file is newly created. Jay, let me know if this is not the case. As discussed with Dani, this scenario is not intended to be demoed at ECE 2016. So we need not rush to commit the changes.
*** Bug 509705 has been marked as a duplicate of this bug. ***
Recent changes in bug 486011 removed the API JavaCore.createModuleFromPackageRoot(..) which was used while creating module-info.java file via "New Source Folder" wizard. Updated the code to handle the same in jdt.ui now: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?h=BETA_JAVA9&id=8070f3a502020e5759289a789fe05cc78f9a04f6
New Gerrit change created: https://git.eclipse.org/r/99310
(In reply to Eclipse Genie from comment #17) > New Gerrit change created: https://git.eclipse.org/r/99310 This patch removes the checkbox from New Source Folder wizard and adds an action on the Java project: Configure > Create module-info.java. (In reply to Noopur Gupta from comment #14) > But currently, the formatter doesn't work with > CodeFormatter.K_COMPILATION_UNIT for module-info.java file. Reported bug > 506430 for this. It still doesn't work with K_COMPILATION_UNIT for module-info.java and needs a new kind K_MODULE_INFO. I have used K_MODULE_INFO in the patch until it is clarified in bug 506430. Jay, please have a look and let me know if I should push the changes.
(In reply to Noopur Gupta from comment #18) > Jay, please have a look and let me know if I should push the changes. Works well for me. Thanks!
Gerrit change https://git.eclipse.org/r/99310 was merged to [BETA_JAVA9]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=b80504c89eb283c803eee942d751edf19b80acff
2 Questions: - Does anyone mind when I remove "java.base" from the set of modules returned by JavaCore.getReferencedModules()? It doesn't add any value to the generated module-info.java. - Wouldn't it be great if the conversion can be invoked on multiple projects in one swoop?
(In reply to Stephan Herrmann from comment #21) > 2 Questions: > > - Does anyone mind when I remove "java.base" from the set of modules > returned by JavaCore.getReferencedModules()? > It doesn't add any value to the generated module-info.java. Not at all.
(In reply to Stephan Herrmann from comment #21) > - Wouldn't it be great if the conversion can be invoked on multiple projects > in one swoop? This action can show a dialog during conversion for errors or questions like: - Project requires compliance level of 9 or above. - No source folder exists in the project. - The module-info.java file already exists in the source folder ''{0}''. Do you want to overwrite it? This makes it difficult to manage multiple projects.
(In reply to Noopur Gupta from comment #23) > (In reply to Stephan Herrmann from comment #21) > > - Wouldn't it be great if the conversion can be invoked on multiple projects > > in one swoop? > > This action can show a dialog during conversion for errors or questions like: > - Project requires compliance level of 9 or above. > - No source folder exists in the project. > - The module-info.java file already exists in the source folder ''{0}''. Do > you want to overwrite it? > > This makes it difficult to manage multiple projects. I see. I was just wondering (also in comparison to the corresponding PDE conversion to Plug-in Project). Nevermind.
(In reply to Jay Arthanareeswaran from comment #22) > (In reply to Stephan Herrmann from comment #21) > > 2 Questions: > > > > - Does anyone mind when I remove "java.base" from the set of modules > > returned by JavaCore.getReferencedModules()? > > It doesn't add any value to the generated module-info.java. > > Not at all. Done via bug 521388
