This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
In order to turn the parts of openide into real modules, we need to move the sources to separate dirs. And while we are at it, we can also reformat them to use new standards.
Created attachment 21680 [details] The patch that does the move and formating using jalopy
Jesse, please check if you like the coding style, if not, there is jalopy-settings UI program that one can use to change it.
Well I can't realistically guess what that Jalopy convention will do to actual sources without seeing some examples. Probably OK so long as it does nothing weird or noticeably unlike our current formatting.
Created attachment 21704 [details] I have created also nbprojects for the openide submodules
I don't understand why you are keeping all the crap in openide/build.xml, like the all-openide/windows target for example. Why is it here and not in nbbuild/build.xml? What is the do-lib-javac target for, now that each openide/*/build.xml just imports projectized.xml? IMHO all the submodules should be built just like any other modules, as far as nbbuild goes, with the exceptions that (1) the cluster is set to 'extra'; (2) openide is included as a pseudomodule and openide/build.xml just collects all their JARs into openide.jar for now (and makes an update-tracking entry for it). (It would be nice to be able to use a single Ant property to change this behavior to doing a copy from extra to platform*, so that we can see easily what things look like with the JARs physically separated, but skip it if it is difficult at all.) javadoc.main.page is OK to use temporarily, but later we should just move **/doc-files/api.html to be **/package.html, and not use this property for org.openide.** APIs. At some point (not necessarily now), I think we should move e.g. openide/arch/arch-openide-windows.xml to openide/windows/arch.xml. However we also need to clean these up seriously: many of them describe not just the API, but also the impl in core. There should be e.g. a separate core/windows/arch.xml that describes what the impl module does. No need to include commented-out properties such as javadoc.docfiles in project.properties. If it does not need to be set, delete the line. Please use the http://www.netbeans.org/ns/nb-module-project/2 schema for new modules. openide/compat/manifest.mf has the wrong code name base. Why is openide/src/org/openide/modules/Bundle.properties created but empty? Same for enum? And why don't other modules have bundles? And why does openide/text/manifest.mf specify OpenIDE-Module-Localizing-Bundle: org/openide/windows/Bundle.properties? org.openide.util.enum *has to* specify a dependency on org.openide (same for some others); currently the module system does not permit any module to not have one. This should be fixed sometime, but it isn't yet. Big project: update all existing modules in netbeans.org to specify precise deps on org.openide.* submodules in project.xml, so that we actually compile against the correct APIs. You will need some kind of script to do this. It may not be possible to do this until openide JARs are physically split, I don't know. Please keep all entries in modules.xml alphabetically sorted. Suggest making openide/util/enum be openide/enum to avoid unnecessary 3rd-level modules. Comments such as "JST-PENDING: Remove somehow dependency on options" (for openide/text) should go into the appropriate project.xml, not openide/build.xml.
Re. first paragraph - what is in the patch is what you describe. all-blabal is there to move the sources. It cannot be build into extra as that gets on classpath of regular netbeans, that is why. There is no single switchable property, behaviour is hardcoded. As soon as we move the sources, I can delete a lot of openide/build.xml. So I have to say, that the comments in first paragraph seem confused and useless. If you insist on something from it to be really applicable, please identify it... 2nd paragraph - yes, that is what I'd like to do next week. Or do you really insist on writing yet another <move /> into the build scripts? I have enough of moving with using jalopy. 3,4, ok. 5th paragraph - they are empty to be filled with reasonable content. It is not used right now, as the openide is still built in the old way, but I'll fill the content before merge. 6th - How can I specify dependency on openide when it gets removed!? Better to fix module system. 7th - do you remember that there are more planned steps to implement the final state. Have not you read the proposal? This bug is just about the first one - e.g. move sources. 8th - I see no reason to sort. Anyway modules.xml shall be generated and not filled by hand. But I can do it. 9th - openide/util/enum - does not hurt anything, moreover it is supposed to be deprecated. Unless there is some benefit, I'll keep it where it is. 10th - ok, check for JST-PENDING comments Thanks for review, please reevaluate your comments in 1st paragraph as those were somehow confused.
Re. dep on openide - well it's not removed yet, and for now you have to declare a dep on it, or else ModuleAutoDeps gets triggered and you get a dep anyway. Can be fixed, but not right now. Re. my first paragraph - I am asking why there is any compilation-related target in openide/build.xml, when each openide/*/build.xml knows how to build itself (w/ projectized.xml), and all openide/build.xml needs to do is aggregate those JARs. If 'extra' goes into the live NB classpath, then make up some other dummy cluster name to use as a temp dir during the build. I just want to see all calls to <javac> gone from openide/build.xml, so that we know openide/*/nbproject/project.xml are really being used correctly and so on. I am not sure exactly what you are doing with scripts to move sources, but probably all such stuff should be kept in a separate file. What I want to see is a diff that shows what the *result* will be when sources have been moved. Re. modules.xml - I will probably delete it anyway, but until now I was keeping it sorted as it is much easier to inspect and edit that way.
I believe I managed to implement all, I have not rejected. > you have to declare a dep on it, or else ModuleAutoDeps gets triggered and The dep does not need to be there now, as the module is not part of final build (it goes to tmp cluster). For later phases of the separation, I think we shall change the module system behaviour with respect to the dependency on open ide as in fact there will be no openide anymore. I've made a note to the http://openide.netbeans.org/proposals/arch/modularize.html about that, however I do not have details now how it shall be changed. > I am asking why there is any compilation-related target > in openide/build.xml, You are right, I've just deleted all <javac> from there as it was useless anyway. I also renamed all the target to express their meaning better. > I am not sure exactly what you are doing with scripts to move sources, but > probably all such stuff should be kept in a separate file. What I want to > see is a diff that shows what the *result* will be when sources have been > moved. I think that it is unreasonable request. The move heavily depends on selectors defined in the openide/build.xml and just a promise that it is not used during a build and will be asap after merge shall be enough imho. Also I am not producing full diff in advance, but rather a zip with all moved files. I do not want to add files into CVS and then resolve conflicts with changes made meantime in the original sources. That is the whole point of the move! > it sorted as it is much easier to inspect and edit that way. Sorted, but I do not buy the argument at all.
Created attachment 21807 [details] Commit log
Moved. Let's what will happen next.