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.
<target name="all-javacvs/cvsmodule" depends="init,all-javacvs/libmodule,all-diff,all-versioncontrol,all-core,all-core/progress,all-projects/projectsapi,all-projects/projectsuiapi,..."> duplicates data in: javacvs/cvsmodule/nbproject/project.xml. Expected behaviour dependecies are automaticaly taken from project.xml and merged with declated (additional e.g. init).
Yes. I could solve it easily in the old style - depending on build of each module that it depends on - but what about the cluster build sequence? (Does anyone actually care about building clusters in a particular order? Where did this requirement come from, and can it be removed?)
Is issue #45234 relevant here?
*** Issue 42629 has been marked as a duplicate of this issue. ***
Note that *external* suite modules can now do this automatically with a fairly simple Ant task.
The requirement for clusters is simple: "build each cluster on top of binary distribution of others". We are not there yet, but the state in nbbuild is heading towards that direction. I am not sure how suite work, but cannot you just define a suite for platform, other suite for ide that would depend on platform, etc. and then handle the module dependencies just inside each suite? If necessary (and helpful) create nbbuild/platform, nbbuild/ide, nbbuild/enterprise, etc. with separate build scripts for each part.
> The requirement for clusters is simple: "build each cluster on top of binary > distribution of others". We are not there yet, but the state in nbbuild is > heading towards that direction. As far as I know this is possible with current nbbuild/build.xml - if there are wrong dependencies between all- target file a IZ please > I am not sure how suite work, but cannot you just define a suite for platform, > other suite for ide that would depend on platform, etc. and then handle the > module dependencies just inside each suite? > If necessary (and helpful) create nbbuild/platform, nbbuild/ide, > nbbuild/enterprise, etc. with separate build scripts for each part. This make sence to me and should be relativly simple to implement. The problem could be that one want to build only one module and all its dependencies then this approach won't work (at least I'm not aware how). Other issue is what to do with NOT stable modules and with all the modules configs like stable-with-apisuppor stable-without-webapps? The only suitable granularity (in view of build system) could be clusters then...
The state in nbbuild is not heading anywhere at the moment, as far as I know. Why is there a requirement to build each cluster on top of a binary distribution of the preceding ones? What are the use cases? You cannot define "suites" for netbeans.org modules. "Suites" are only permitted for external modules. Module configs are long out of date and should just be deleted - they should have been deleted a year or two ago, when they stopped working. The simplest rewrite that I can think of is to rip out all of the all-* targets and all of the cluster-by-cluster build targets. For any given list of clusters to be built (determined from cluster.properties), collect all the modules in those clusters, then build them all in their dependency order (ignoring clusters), using a special Ant task to do a topological sort (similar to what suites already do) and then <subant>. But again, it is unsafe to make any serious changes without having a list of intended entry points to the build system, so as to test that they are not broken. I don't even know what targets RE runs when doing a daily build of the NetBeans Platform, NetBeans IDE, or any derivative product.
The intent of cluster dependencies is to eat our own food and also allow RPMs and other packages to be build in an incremental mode. First platform, then ide reusing the previously installed platform, and so on. Not very compleling, but still (a bit) desirable. Moreover simple to implement. "rip out all of the all-* targets" Ok. Can you generate them on a fly? So people can type "ant all-core"? If that is possible, I would not be worried about incompatible changes, as the set of nbbuild targets stayed nearly the same. "to be built (determined from cluster.properties), collect all the modules in those clusters, then build them all in their dependency order (ignoring clusters), using a special Ant task to do a topological sort (similar to what suites already do) and then <subant>." Slight modification. For any cluster create build-cluster (like build-platform) target that depends on all its modules. When building a module dependency, replace all references to modules in other cluster with build-cluster dependency. This does not seem to be much harder to write and behaves more like current and hopefully also the desired state.
That could probably work. So who will write it? I don't have time right now.
I will try a simplified variant that just autocreates the all-* targets but does not add any new build-* targets (should be closer to current impl). The system will still be too much of a mess, but that is for Michal or someone else to clean up; this should at least remove the many redundant all-* targets.
committed 1.13 java/javacore/build.xml committed 1.8 mdr/module/build.xml committed 1.9 mdr/module/nbproject/project.xml committed 1.8 mdr/nbjmiutils/build.xml committed 1.279 nbbuild/build.properties committed 1.692 nbbuild/build.xml committed 1.92 nbbuild/cluster.properties added 1.1 nbbuild/antsrc/org/netbeans/nbbuild/InsertModuleAllTargets.java committed 1.20 nbbuild/antsrc/org/netbeans/nbbuild/ModuleListParser.java committed 1.26 tomcatint/tomcat5/bundled/build.xml committed 1.66 xml/tax/build.xml