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.
Need to be able to take a NB build (i.e. the platform cluster plus zero or more additional clusters) and build projectized modules against it, without them needing to be in the cvs.netbeans.org tree. This means that nbbuild/templates/*.xml and some other nbbuild/*.{xml,properties}; nbantext.jar; etc.; all need to be included in the binary build in some special directory ("kit" or something). projectized.xml would refer to this kit (you would need to define some Ant property to refer to a "cluster path") and apisupport/project would too. Ideally the platform cluster dir would have the main stuff, and other cluster dirs would have just have some information listing their own modules (if it could not be determined quickly on the fly). Probably modules.xml should not be included as it only applies to building against a source tree. TBD whether the SourceForBinaryQueryImplementation in apisupport/project should support finding sources for a foreign cluster this way. There are various issues that will arise; this has not been thoroughly designed yet.
*** Issue 51333 has been marked as a duplicate of this issue. ***
*** Issue 52937 has been marked as a duplicate of this issue. ***
*** Issue 56507 has been marked as a duplicate of this issue. ***
I attached a patch to solve hard-coding 'nbbuild' name in issue 56507 which I closed as duplicate of this issue (I filed that issue before rereading Jesse email).
This can, of course, be done on a limited basis now with the cluster build harness. However, I think the ideal solution would not involve an external build directory like nbbuild/ at all (or, at least, just for the core, non-module stuff in the CVS tree, and unnecessary for building a cluster of modules).
This is my main task right now. Not simple.
An initial question is how to get rid of modules.xml. Need some way of figuring out, starting from an NBM project, what "nearby" modules are, in terms of the info in modules.xml: source path, JAR path, and code name base. Proposed algorithm, for both apisupport/project and ParseProjectXml: 1. Make <path> optional in project.xml /2: deleted for nb.org modules, and for external modules, to mean path within an external module suite. 2. If ${nb_all} is defined (which is done consistently for nb.org modules in nbbuild/default-properties.xml, and may be done for external modules where there is an NB source association too, indirectly thru some "NB platform definition" properties file), scan for NBM projects among ${nb_all}/{*,*/*,*/*/*}. Since no nb.org modules are more than three dirs deep, this should work for now. For reference, on my laptop, echo */{,*/,*/*/}nbproject/project.xml only takes a second or so, but we need to add some XML parsing and so on; should try to cache the result (per ${nb_all}) within one Ant build (for PPX) and in apisupport/project (at runtime). 3. If <path> is defined, use it to infer a root for the external module suite, and scan e.g. ${root}/{*,*/*}, i.e. permit modules two levels deep. (Could be made deeper as needed, but best to limit the scan for performance reasons.) Again, need to cache result by ${root}. If you aren't referring to those other modules, no problem, but you can if you want (using <module-dependency>). 4. If ${nb_all} was *not* defined (for an external module), netbeans.dest.dir must be defined (so you can build!), so first scan ${netbeans.dest.dir}/*/modules/*.jar for entries w/o source path. 4a. (The source path is only important for ParseProjectXml to find Class-Path extensions. Currently this uses an odd hack but that should be deleted and <class-path-extension> searched for in project.xml. If there is no source, the JAR manifest must be used instead - it is preferable to use a source path because use of <binary-origin> or <extra-compilation-unit> in the subproject helps to avoid needless classpath rescanning. apisupport/project of course uses the source path for various purposes, but if not found, oh well - if you don't have sources, it won't use any.) Other fine points not related to modules.xml: 1. All external modules will I guess build into the "extra" cluster of your ${netbeans.dest.dir}. So it should be easy to clean them from ${netbeans.dest.dir} (just delete this whole cluster). If you want them somewhere else in a real app, that's fine - write some separate Ant script to move them (or just pack them into a ZIP with a different prefix, as Ant makes it easy to do). 1a. If you want to keep a pristine reference copy of your NB platform and not trust deletion of extra/, make a temp copy somewhere and set ${netbeans.dest.dir} to that instead. 2. No initial support for building a whole module suite at once - you can (pretty) easily write this yourself. Should be possible later, using <build-prerequisite> declarations.
Sounds good, for the most part. I'm concerned about your "fine point" #1. You say that, if I want my modules in a cluster other than 'extra', I can just copy them to another cluster, or rename the prefix. But what about ${netbeans.dest.dir}/moduleCluster.properties? Is there a reason why adding a cluster element to the module's project.xml is a bad idea?
So what about moduleCluster.properties? This file is junk, used only during the build AFAIK. It can just be deleted, or if not, its contents do not matter after you have finished building. Re. defining an explicit cluster from an NBM project - could probably be supported to let project.properties set ${cluster.dir} or something. Will see.
Created attachment 21743 [details] Initial work
The patch seems good to me.
Well I'm just starting - there will be more changes, especially in apisupport/project.
Created attachment 21781 [details] Continued work (should be enough for NB to build itself OK)
Minor adjustment: for external modules, ${nb_all} is not interpreted by <parseprojectxml> at all; it is not needed for anything. apisupport/project will however look for a property ${netbeans.sources} (path format) to use for source association at development time.
Created attachment 21805 [details] Continued work (1 of 2)
Created attachment 21806 [details] Continued work (2 of 2)
I would put this all into a branch, but I would have to branch *every* module (to upgrade /1 -> /2 in project.xml), and it would take soooo long in CVS, it's not worth it. :-(
Created attachment 21842 [details] More progress; NB itself builds, and you can again work on netbeans.org modules with apisupport/project correctly
Created attachment 21856 [details] Further progress; working on apisupport recognition of external modules
Created attachment 21895 [details] A few more fixes... seems possible to open external projects with correct in-IDE classpath etc. (but still testing)
Created attachment 21897 [details] More work... it actually seems to work to open an external module in the IDE and build it, including intra- and inter-suite dependencies; no unit testing support yet
Created attachment 21900 [details] Unit testing working, context menu in Projects nicer, ...
Created attachment 21901 [details] Documented and nearing completion.
Implemented.
Created attachment 21903 [details] Commit log