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.
Steps to reproduce: * Clean openide.dialogs * Try "Build with Dependencies" on apisupport.projects * Build ends with error: C:\NetBeansProjects\fixes-core-main\nbbuild\templates\projectized.xml:93: No such classpath entry: C:\NetBeansProjects\fixes-core-main\nbbuild\netbeans\platform9\modules\org-openide-dialogs.jar Other combinations, like clean of o.n.core and build of core.windows work well.
I believe this is due to the "clusterized" build process in nbbuild/build.xml that Michal instituted a few years back: all-apisupport.project checks to see whether nb.cluster.platform.built exists, and if so, skips that whole cluster. I am not sure what the real purpose of this change was, and perhaps it can be reverted to do a straightforward topological sort on module dependencies and build them. I have often been annoyed by a somewhat related problem: if I do e.g. ant init all-contrib/autoproject.web then every module in the enterprise cluster will be built, even though I only really need one or two API modules and a handful of their dependencies from this cluster.
BTW a quicker impl of all-* could work more like we do for tests: identify which module JARs on the classpath do not yet exist and build just these (perhaps recursing if these in turn lack some dependencies). That would avoid doing incremental builds on all of the dependencies, which is the time-consuming part of typical all-* builds; most of the dependencies are probably fully up to date already. There may also be a use case for running all the dependent build scripts, in case source code in dependency modules have been changed since last built and the target module in fact relies on these recent changes.
I should say that in fact when you do all-contrib/* for a module in the "experimental" list, _all_ standard clusters are first built, which is especially annoying and unnecessary.
Thanks for explanation. I've noticed that run-depend-build macro builds whole clusters and wasn't sure why. Michale, is there a reason to keep it this way?
The reason why the build is splitted to the clusters is NetBeans architecture. I don't remember the place where it is expained, but Jarda (CC'ed) should be able to point you there. Ad why it check whenever the cluster is built or not is only performance. If build of module doesn't work from IDE then I say that bug is somewhere else, because if there is no platform9\modules \org-openide-dialogs.jar then there is no nb.cluster.platform.built file. Could you please be more specific and tell us the exact steps to reproduce and/or attach verbose ANT log.
If the purpose is only to speed up the depend build, then we would be better off using my suggestion of (recursively) checking for the existence of JARs of dependencies. This would be simpler (no reference to clusters) as well as faster (checks only actual dependencies, not unrelated modules that happen to be in the same cluster as a real dependency). "if there is no platform9\modules\org-openide-dialogs.jar then there is no nb.cluster.platform.built file" - Richard's original steps to reproduce explain that you clean openide.dialogs, presumably after the platform cluster has been fully built.
The exact steps are stated in description of the issue, I'm attaching Ant log. Re nb.cluster.platform.built: the file remains there even after cleaning any of platform module projects.
Created attachment 75639 [details] Ant output
sorry, I missed it somehow... Now I understand the issue. The reason why the build is clusterized it to copy NetBeans architecture... So the fix would be to remove {cluster.name}.built file from {netbeasn.dest.dir} in case there was clean ran in one of the cluster's modules, right?
That would fix the originally reported problem, but none of the other issues I have mentioned. I still stick by my most recent recommendation.
I agree with Jesse here, to build exactly what is needed seems better approach to me than try to cover all situations when module jar gets deleted (which can't be done in 100% of cases, e.g. when someone deletes jar directly on disk). But I still don't know the reasons behind current behavior though, they may be more severe...?
I fixed initial issue. CS - 833ca090ff3c I will take a closer look at build system improvemnt in any case. BTW: dealing with situations when someone manually intervene building (manual delete of .jar file) is little bit paranoid. We can't handle every corner situation.
Integrated into 'main-golden', will be available in build *200902030229* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/833ca090ff3c User: Michal Zlamal <mzlamal@netbeans.org> Log: #156467 Set cluster as not built when one clean target has been ran for one of its modules