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.
Given: Module A in suite S Module B added as project to S (aka chaining) A depends on B modify a file in A, press "Apply Code changes" Observe: the following error "no dependent module B" (it does build regularly...) taskdefs: common-init: projectized-common.basic-init: basic-init: files-init: nbm-license-init: build-init: Scanning for modules in C:\a\j\NetBeans 7.0\apisupport Scanning for modules in C:\a\j\NetBeans 7.0\harness Scanning for modules in C:\a\j\NetBeans 7.0\ide Scanning for modules in C:\a\j\NetBeans 7.0\java Scanning for modules in C:\a\j\NetBeans 7.0\nb Scanning for modules in C:\a\j\NetBeans 7.0\platform Scanning for modules in C:\a\j\NetBeans 7.0\profiler Scanning for modules in C:\a\j\NetBeans 7.0\websvccommon Scanning for modules in suite C:\a\src\jvi-dev\nbvi C:\a\j\NetBeans 7.0\harness\build.xml:171: No dependent module org.netbeans.modules.jvi.help BUILD FAILED (total time: 3 seconds)
Created attachment 108703 [details] Test case
Working fine for me in a dev build with the attached test case. Build test199122b, then debug test199122a. Run the action and see the initial message. Modify the status text message a bit, Apply Code Changes, run again, and you see the new message.
Your test case works for me with NB7. I also tried adding B as a standalone module (which matches my case) rather than adding B's suite. But that works for me too. The "Apply code changes" is a red herring. My case fails when I simply build module A as opposed to building the suite S. It's failing in <parseprojectxml> but I admit that task is particularly strange to me the way it takes the names of properties... I'll work with the test case and try to get it to fail.
(In reply to comment #3) > The "Apply code changes" is a red herring. My case fails when I simply build > module A as opposed to building the suite S. In the initial description you said "it does build regularly". Sounds to me like you simply did not build B first.
> did not build B first. B is built (I just tried again) Build the suite, it works. Build the module, it fails.
I think my several year old modules/projects are causing the problem. In the failing situation, -convert-old-project is executed. Can you tell me how to manually convert an old to a new? === === when building the suite, which WORKS, === I see this sequence in ant debug output === Setting project property: cluster.path -> ... .../websvccommon:jvi-help/build/cluster:NB-jVi-SPI/build/cluster ... Setting project property: libs.Comet-GlassFish-v3.maven-pom -> Setting project property: libs.javac-api.javadoc -> Setting project property: harness.dir -> C:\a\j\NetBeans 7.0/harness Setting project property: nbplatform.active.dir -> C:\a\j\NetBeans 7.0 Setting project property: cluster.path.evaluated -> ... .../websvccommon:jvi-help/build/cluster:NB-jVi-SPI/build/cluster Class org.apache.tools.ant.taskdefs.condition.Contains loaded from parent ... Class org.apache.tools.ant.types.selectors.ContainsSelector loaded from ... Found directory: C:\a\j\NetBeans 7.0\harness Importing file C:\a\j\NetBeans 7.0\harness\suite.xml from C:\a\src\jvi-dev\nbvi\nbproject\build-impl.xml ... -convert-old-project: Skipped because property 'cluster.path.evaluated' set. === === when building individual module, which FAILS === NOTE: cluster.path.evaluated not set === conver-old-project is executed === eventually cluster.path.evaluated is set without jvi-help === Setting project property: cluster.path -> ... .../websvccommon:jvi-help/build/cluster:NB-jVi-SPI/build/cluster ... Setting project property: libs.Comet-GlassFish-v3.maven-pom -> Setting project property: libs.javac-api.javadoc -> Setting project property: harness.dir -> C:\a\j\NetBeans 7.0/harness Setting project property: netbeans.dest.dir -> C:\a\j\NetBeans 7.0 Class org.apache.tools.ant.types.resources.selectors.Not loaded from parent ... Found directory: C:\a\j\NetBeans 7.0\harness Importing file C:\a\j\NetBeans 7.0\harness\build.xml from C:\a\src\jvi-dev\nbvi\nbvi-module\nbproject\build-impl.xml -convert-old-project: fileset: Setup scanner in dir C:\a\j\NetBeans 7.0 with ... ... Set property cluster.path.evaluated = ... ...\websvccommon
In project.xml I tried changing 2 to 3 as in <data xmlns="http://www.netbeans.org/ns/nb-module-project/3"> but that didn't matter. Aha, zapped build-impl and the re-created version works. I'm guessing the 2-->3 was needed as well, since the previous build-impl had been created less than a month ago. Are there any gotcha's I should watch out for changing 2-->3?
(In reply to comment #6) > Can you tell me how to manually convert an old to a new? You are using a pre-cluster-path suite platform.properties I guess. But this is supposed to be corrected just in the suite AFAIK, not in individual modules. I would need a self-contained reproducible test case to follow what is going wrong in your case.
Created attachment 108766 [details] modifed test to demonstrate failure Starting with your test case I manually modified project.xml and build-impl.xml for project a to make project A look like an old project. With that, build suiteA works, build module A fails. Note that from my point of view you can close it; but if you want to track it down, here's a test case.
(In reply to comment #9) > Starting with your test case I manually modified project.xml and build-impl.xml > for project a to make project A look like an old project. With that, build > suiteA works, build module A fails. Indeed, because the old (I think pre-6.7?) build-impl.xml template does not handle cluster paths. The question remains why A's build-impl.xml was using this old template. If you delete it and reopen the project, building A works fine. And the IDE automatically upgrades old build-impl.xml files when opening projects, unless you have made custom edits (which you are explicitly warned not to do in the header of the file).
(In reply to comment #10) > the IDE automatically upgrades old build-impl.xml files when opening > projects, That's what I expected and so was surprised that this old one was still there. The file has no customization in it. > unless you have made custom edits (which you are explicitly warned > not to do in the header of the file). I certainly didn't intentionally modify the file; shtuff happens. I thought genfiles.properties was used to detect if build-imp.xml had been changed and ifso would automatically regenerate it. I guess I'm misunderstanding the comments/warnings. Changing resolution to invalid.
(In reply to comment #11) > I thought genfiles.properties was used to detect if build-imp.xml had been > changed and if so would automatically regenerate it. Yes, that is the idea. Somehow this broke down in your case.
(In reply to comment #12) > (In reply to comment #11) > > I thought genfiles.properties was used to detect if build-imp.xml had been > > changed and if so would automatically regenerate it. > > Yes, that is the idea. Somehow this broke down in your case. I don't think that works anymore. If it did, when you opened the updated test case I sent you, you would have not have seen the build-imp.xml that I manually changed.
(In reply to comment #13) > I don't think that works anymore. If it did, when you opened the updated test > case I sent you, you would have not have seen the build-imp.xml that I manually > changed. It's trickier than that. Given a complete set of project.xml, genfiles.properties, and build-impl.xml exactly as written by an old NB installation, a new installation should update them upon opening. (org.netbeans.spi.project.support.ant.GeneratedFilesHelper.shouldGenerateBuildScript if you are curious)