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.

Bug 215666 - Build problem with @Messages in Maven based module project
Summary: Build problem with @Messages in Maven based module project
Status: RESOLVED DUPLICATE of bug 220677
Alias: None
Product: projects
Classification: Unclassified
Component: Maven (show other bugs)
Version: 7.2
Hardware: PC Windows 7
: P3 normal with 2 votes (vote)
Assignee: Milos Kleint
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-18 06:52 UTC by mienamoo
Modified: 2012-10-24 06:33 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Screenshot 1 - expected result (12.31 KB, image/png)
2012-07-18 06:52 UTC, mienamoo
Details
Screenshot 2 - window and menu item text disappears (13.11 KB, image/png)
2012-07-18 06:53 UTC, mienamoo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mienamoo 2012-07-18 06:52:24 UTC
Created attachment 122136 [details]
Screenshot 1 - expected result

NetBeans 7.2 build 201206291011
JDK 7u5 32-bit

Steps to reproduce:

1. Create a new Maven-based NetBeans application, with a module. I picked the RELEASE72-BETA version of the platform during the wizard.
2. In the module, create a TopComponent window. Check "Open on Application Start" for convenience.
3. Clean and build the parent, and run the app. The window should appear as expected and also appear on the Window menu. (See the first attached screenshot.)
4. Close the app.
5. Go to the source code of the TopComponent, and modify something. I just put a System.out.println(); into the constructor. Any change that would require recompile of the class will do.
6. Build the module (NOT clean and build, just build).
7. Start up the app, and the window will no longer appear. (See screenshot 2.)
8. When choosing the nameless action on the Window menu, the following exception occurs:

java.lang.IllegalStateException: Cannot find TopComponent with preferredID TestTopComponent, see IDE log for more details.
	at org.openide.windows.OpenComponentAction.actionPerformed(OpenComponentAction.java:91)
	at org.openide.awt.AlwaysEnabledAction$1.run(AlwaysEnabledAction.java:197)
	at org.openide.util.actions.ActionInvoker$1.run(ActionInvoker.java:95)
	at org.openide.util.actions.ActionInvoker.doPerformAction(ActionInvoker.java:116)
	at org.openide.util.actions.ActionInvoker.invokeAction(ActionInvoker.java:99)
	at org.openide.awt.AlwaysEnabledAction.actionPerformed(AlwaysEnabledAction.java:200)
	at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018)
...


And looking at the log file reveals that earlier there was this issue:


INFO [org.netbeans.core.startup.layers.BinaryFS]: value = com.test.mavenproject1.Bundle#CTL_TestAction from Actions/Window/com-test-mavenproject1-TestTopComponent.instance
java.util.MissingResourceException: Can't find resource for bundle org.openide.util.NbBundle$PBundle, key CTL_TestAction
	at java.util.ResourceBundle.getObject(ResourceBundle.java:393)
[catch] at org.netbeans.core.startup.layers.BinaryFS$AttrImpl.getValue(BinaryFS.java:692)
	at org.netbeans.core.startup.layers.BinaryFS$BFSBase.getAttribute(BinaryFS.java:522)
	at org.openide.filesystems.MultiFileObject.getAttribute(MultiFileObject.java:930)

...

CONFIG [null]: Missing resource from class: org.openide.util.NbBundle$PBundle
CONFIG [null]: Key which was not found: CTL_TestAction

And this is consistent with my experience from a module of ours where the @Messages annotation is used on a non-TopComponent class, where we sometimes see at runtime a class not found exception for the generated Bundle class, in the same kind of scenario above.

If you then clean and build the module, it will return to normal.
Comment 1 mienamoo 2012-07-18 06:53:09 UTC
Created attachment 122137 [details]
Screenshot 2 - window and menu item text disappears
Comment 2 Milos Kleint 2012-08-17 15:18:17 UTC
the problem appears to be caused by compile on save being turned on. The project build after the file change will not compile anything (as it has been compiled by the IDE already)

the workaround here is to disable compile on save.

further investigation is needed with regard to what CoS is doing with annotations and what it should be doing. I've been told that the @messages annotation is unfortunately problematic, maybe this is one of the displays of it..
Comment 3 mienamoo 2012-08-17 16:13:58 UTC
Thanks for the workaround, Milos. I will definitely try it on Monday! :-)
Comment 4 Milos Kleint 2012-09-03 11:04:22 UTC
tzezula, jlahoda: any hints where to start looking?
Comment 5 javydreamercsw 2012-09-24 22:00:28 UTC
I have a project presenting this issue here: https://javydreamercsw@bitbucket.org/javydreamercsw/jwrestling presenting the same behavior.

If I have autocompile on when building a second time after cleaning the project, it fails generating code from annotations complaining there are duplicate classes.

I verified that the existent classes get overwritten and are nowhere else. It seems to be a cache thing.

I believe the code has autocompile off in the repo. Make sure to enable it to see the issue.

Hopefully it is helpful.
Comment 6 _ wadechandler 2012-10-11 15:22:00 UTC
I too am experiencing this. All my other top components in my current project were not using @Messages. I had upgraded to the 7.2 IDE and the first top component I created used the annotation. So, out of the box the IDE is creating code with issues. This is not always caused by auto compile I think though as I have some folks getting this just by building on the command line. Seems a "clean install" is required, but I'm pretty sure I have seen the issue a time or two even with a clean. The weirder issue is that it doesn't always happen.

I have a mvn module called gui which represents the NB RCP mvn parent and UI portion of our project. Under that I have cfg and application. cfg is where our UI forms reside; thus top components. From the command line I often cd to gui and run:
cd cfg/ && mvn -Pm3 -Dmaven.test.skip -o  install && cd ../application/ && mvn -Pm3 -Dmaven.test.skip -o clean nbm:cluster-app && cd ..

because it is just quicker than using the IDE.

So, I make some changes to *any* file in cfg. I come back to the shell and build. I then go to the IDE, right click on "Application" and choose a special target under "Custom" which is designed to not rebuild, but to instead just run without rebuilding ... since I do that on the command line. Every now and then I get a resource not found exception when the top component tries to open, and I have to close out and rebuild. Most times 1 rebuild fixes it. One time I had to rebuild like 3 times before it ran fine.

The funnier part, though I don't guess it is funny since it is such a PITA, is that I have not changed the top component class, but only classes used by it, so I'm not sure why this issue happens even when I have not made changes to code in the top component using the annotation.

I'm going to put those properties in the package bundle because this is a horrible experience, and I suggest the annotation not be the default in NB 7.3 if this issue isn't resolved as it doesn't seem only related to having the IDE open, creates code which has issues from the start, and is a big waste of time where the only real fix at this point seems to be to change the code to use the properties file instead or to turn off auto compile though I'm not convinced yet that auto compile is the exact issue, but will try to confirm before I make the switch. I'm still going to go back to the properties file though as this will affect other team members and I will have to tell them to turn off auto compile after they spend their time before asking if anyone knows about the issue if that is in fact the thing making this happen.
Comment 7 _ wadechandler 2012-10-11 16:27:07 UTC
So I turned off compile on save, and then I changed the top component and saved it. Did a rebuild. Missing resource exception. So, I'm going back to using the properties file for all top components. If there isn't a way to tell NB to not use this as the default in 7.2, then this is a definite must for 7.3 if this issue can't be resolved because it basically causes bugs.
Comment 8 Milos Kleint 2012-10-22 14:21:29 UTC
I've switched to a simpler case of having just @Messages("foo=bar") on a method

maven clean build all works file. Both Bundle.class file and Bundle.properties file are present target/classes. Maven also generates a Bundle.java file in target/generated-sources/annotations

when CoS is on, editing the @messages value eventually ends up in the following situation:
 .class file is touched, .properties file disappears, .java file is not updated. (which could be a problem since it's what's on source path of the project)

Running mvn build will not fix the problem (because the timestamp of the .class file?), but clean build does fix it again, .java file is updated, .class file touched and .properties file present.

_ wadechandler: with CoS off, I could not reproduce the problem
Comment 9 Milos Kleint 2012-10-24 06:33:20 UTC
duplicate of issue 220677 (well, i just described the problem to tzezula and not linked to this issue), is fixed in current dev build afaik.

*** This bug has been marked as a duplicate of bug 220677 ***