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.
Jesse Glick wrote: > Rich Unger wrote: > >> 1. Is the hard-coding of "devel" as the cluster name a temporary >> thing, or is that going to be it going forward? Is there a good >> reason why I can't specify cluster.dir=rssreader1 in each module's >> project.properties? Or better yet, have a default value in my >> suite's properties file? > > > Can't you? AFAIK you can, but I haven't tried yet. If you find otherwise, please try to track down why and fix it, or file a bug report. Well, I found the problem, but I don't have the permissions to fix it. In harness/common.xml, the target "basic-init" depends on "common-init". In harness/build.xml, the "common-init" target sets cluster.dir: <target name="common-init" depends="taskdefs"> <property name="cluster.dir" value="devel"/> <property name="netbeans.javadoc.dir" location="build/javadoc"/> </target> I can get the desired behavior by moving the line <property name="cluster.dir" value="devel"/> out of build.xml to common.xml::basic-init, right after <property file="nbproject/private/private.properties"/> <property file="nbproject/project.properties"/> However, as common.xml is copied from nbbuild/, I don't have permissions.
...and it would be wrong anyway, since common.xml is used by projectized.xml in nbbuild, for which "devel" is never a correct cluster name. Can you look for a better solution, affecting only the harness? Maybe putting the cluster.dir def into build-init or something, so project.properties in the suite can override it?
Putting the def in build.init is an equivalent solution, so that's better, as it only affects the harness. I'm not sure I get why the default cluster for platform module developers should be any different than the default cluster for netbeans devs. Why isn't it just "extra" for everybody? This solution still doesn't allow me to specify a default in the suite properties. I can't find anything in harness-build.xml or its includes that actually loads any properties from the suite. Am I missing something?
In netbeans.org, usually the cluster is defined by nbbuild/cluster.properties. For modules not in the standard distro, the cluster defaults to "extra", which will be loaded by the default IDE launcher, so you can build and run them. For external modules, the cluster "devel" is used by default, specifically because it is *not* included in the default list of clusters loaded by the standard IDE launcher. It is loaded only if you pass a special command-line flag, which is what harness-build.xml does. This is helpful when using the default platform, so you don't mess up your IDE installation. A possible alternative would be to set the cluster for external modules to be some totally different location (build/netbeans/ or similar inside the standalone module or suite project dir); I haven't investigated for feasibility yet, but it could probably be done. Would however screw up script fragments which expect things to build to "${netbeans.dest.dir}/${cluster.dir}"; we would need to introduce a new property like ${cluster.dir.absolute} (to be used throughout netbeans.org CVS but especially in common.xml), then have harness-build.xml define this to be whatever path (not using ${netbeans.dest.dir}). Modules when built do not load $suite/nbproject/project.properties. They do load $suite/nbproject/platform.properties (and private equiv), so try defining the cluster there.
OK, using platform.properties works, and I see your reasoning for devel vs. extra.
Verified.