Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 57941 - Physically move openide sources to new locations
Physically move openide sources to new locations
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: -- Other --
5.x
All All
: P1 (vote)
: 5.x
Assigned To: Jaroslav Tulach
issues@platform
:
Depends on:
Blocks: 19443
  Show dependency treegraph
 
Reported: 2005-04-15 15:49 UTC by Jaroslav Tulach
Modified: 2008-12-22 21:54 UTC (History)
1 user (show)

See Also:
Issue Type: TASK
:


Attachments
The patch that does the move and formating using jalopy (17.94 KB, patch)
2005-04-15 15:50 UTC, Jaroslav Tulach
Details | Diff
I have created also nbprojects for the openide submodules (132.81 KB, patch)
2005-04-18 14:48 UTC, Jaroslav Tulach
Details | Diff
Commit log (227.57 KB, text/plain)
2005-04-21 21:18 UTC, Jaroslav Tulach
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2005-04-15 15:49:29 UTC
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.
Comment 1 Jaroslav Tulach 2005-04-15 15:50:46 UTC
Created attachment 21680 [details]
The patch that does the move and formating using jalopy
Comment 2 Jaroslav Tulach 2005-04-15 15:55:17 UTC
Jesse, please check if you like the coding style, if not, there is
jalopy-settings UI program that one can use to change it.
Comment 3 Jesse Glick 2005-04-15 17:20:04 UTC
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.
Comment 4 Jaroslav Tulach 2005-04-18 14:48:16 UTC
Created attachment 21704 [details]
I have created also nbprojects for the openide submodules
Comment 5 Jesse Glick 2005-04-18 18:39:30 UTC
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.
Comment 6 Jaroslav Tulach 2005-04-18 19:05:17 UTC
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.  
Comment 7 Jesse Glick 2005-04-18 22:19:39 UTC
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.
Comment 8 Jaroslav Tulach 2005-04-19 10:20:53 UTC
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. 
 
Comment 9 Jaroslav Tulach 2005-04-21 21:18:58 UTC
Created attachment 21807 [details]
Commit log
Comment 10 Jaroslav Tulach 2005-04-21 21:21:24 UTC
Moved. Let's what will happen next.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo