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
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
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.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
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
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
6th - How can I specify dependency on openide when it gets removed!? Better to fix
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.
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
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
> 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]
Moved. Let's what will happen next.