Bug 199122 - "Apply code changes" fails
"Apply code changes" fails
Status: RESOLVED INVALID
Product: apisupport
Classification: Unclassified
Component: Harness
7.0
PC Windows XP
: P3 (vote)
: TBD
Assigned To: Jesse Glick
issues@apisupport
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-06-02 21:46 UTC by err
Modified: 2011-06-06 21:33 UTC (History)
0 users

See Also:
Issue Type: DEFECT
:


Attachments
Test case (15.89 KB, application/zip)
2011-06-03 14:30 UTC, Jesse Glick
Details
modifed test to demonstrate failure (15.40 KB, application/zip)
2011-06-06 18:09 UTC, err
Details

Note You need to log in before you can comment on or make changes to this bug.
Description err 2011-06-02 21:46:55 UTC
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)
Comment 1 Jesse Glick 2011-06-03 14:30:19 UTC
Created attachment 108703 [details]
Test case
Comment 2 Jesse Glick 2011-06-03 14:32:14 UTC
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.
Comment 3 err 2011-06-03 17:50:05 UTC
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.
Comment 4 Jesse Glick 2011-06-03 18:04:05 UTC
(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.
Comment 5 err 2011-06-03 18:42:15 UTC
> did not build B first.

B is built (I just tried again)

Build the suite, it works. Build the module, it fails.
Comment 6 err 2011-06-03 20:41:25 UTC
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
Comment 7 err 2011-06-05 18:33:51 UTC
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?
Comment 8 Jesse Glick 2011-06-06 16:38:03 UTC
(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.
Comment 9 err 2011-06-06 18:09:38 UTC
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.
Comment 10 Jesse Glick 2011-06-06 19:17:26 UTC
(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).
Comment 11 err 2011-06-06 19:42:36 UTC
(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.
Comment 12 Jesse Glick 2011-06-06 20:38:48 UTC
(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.
Comment 13 err 2011-06-06 20:43:27 UTC
(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.
Comment 14 Jesse Glick 2011-06-06 21:33:10 UTC
(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)


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo