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 149898 - "Needs to be compiled" badge shown on Java nodes when CoS enabled
Summary: "Needs to be compiled" badge shown on Java nodes when CoS enabled
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Jan Lahoda
URL:
Keywords: UI
Depends on:
Blocks: 152191
  Show dependency tree
 
Reported: 2008-10-13 02:46 UTC by David Konecny
Modified: 2009-02-19 21:08 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Konecny 2008-10-13 02:46:29 UTC
Minor issue IMO:

Create a Java project with Main class. First problem to notice is that Main class has "needs to be compiled" badge;
badge stays even if you edit file and save it. Press F6 and badge is gone; edit Main class and no badge is added which
is as expected; press Shift-F11 and edit Main class again - badge is back and will not disappear even if you save file.

  Product Version         = NetBeans IDE Dev (Build 081013)
  Operating System        = Linux version 2.6.24-19-generic running on i386
  Java; VM; Vendor        = 1.6.0_06; Java HotSpot(TM) Client VM 10.0-b22; Sun Microsystems Inc.
  Runtime                 = Java(TM) SE Runtime Environment 1.6.0_06-b02
  Java Home               = /usr/lib/jvm/java-6-sun-1.6.0.06/jre
Comment 1 Jiri Prox 2008-10-13 11:17:46 UTC
this is expected behavior, see http://wiki.netbeans.org/FaqCompileOnSave
Comment 2 David Konecny 2008-10-13 20:26:52 UTC
I think this is clearly wrong. The fact how CoS manages built classes and that sometimes they are in build folder and
sometimes not is our implementation detail. User is not and should not be aware of it. But if you put user's hat on for
a second and play with the IDE you get a badge on your Java files and tooltip saying "Needs to be compiled". You cannot
justify this by a paragraph of text somewhere on Internet saying "we do not know how to implement this so just ignore
it". How does user supposed to know that sometimes this feature actually is working correctly and he does need to
compile the file? This approach basically makes compiled badged unreliable and therefore useless for user.

If a project is CoS enabled I would suggest to disable "needs to be compiled" badges completely because you should never
need to compile anything anyway, no?
Comment 3 Jan Lahoda 2008-11-03 16:08:35 UTC
What are you referring to with "we do not know how to implement this so just ignore it"? If you mean that we do not know
how to disable the "needs to be compiled" badge for projects with enabled CoS, then this is not correct - I know how to
implement this (and I would consider it simpler than writing this comment to IZ, btw).

The reason why the "needs to be compiled" badges are visible even for CoS enabled project is this: consider two
projects, a Web Project and a J2SE library for the web project. Both have enabled Deploy/Compile on Save. But, as the
Web project cannot deploy the library from a directory (.jar file is needed), the standard build script is used to
produce the .jar file. Now, if the user makes a change into the library, he/she needs to run the Build action before the
changes will be actually propagated into the deployed Web project. In this case, the "needs to be compiled" badge can be
useful.

I would also disagree with the claim that the target of the .class files is our impl. detail - I think it makes a big
difference for the users.
Comment 4 David Konecny 2008-11-03 21:22:13 UTC
Honzo, let me rephrase what I'm saying: users are not going to read whole page about how a feature works and then try to
remember that after ant build the F9 should be used to get rid of badge but only until you run project because after
that everything works fine again and F9 is not necessary. I do agree that CoS makes big difference to users but whether
build folder contains classes generated by ant or internal javac is implementation detail and we should not bother users
with that distinction. Or as little as possible.

Re. your example with web and library projects - it would be good to have some indication on the library project that in
order to propagate changes to the web project they should build the library project. But that cannot be achieved via
compile badges. You would be tweaking one feature (compiled badges) to do something unrelated. Perhaps you could
annotate project node with compiled badge to indicate that user should build the project (of course only if project is
used in some web/other projects).

In that respect I still think that CoS enabled project should not show need compilation badges and this issue is valid.
For web/library scenario an enhancement/task could be filed. Would you agree?
Comment 5 David Konecny 2008-11-05 20:00:31 UTC
In that respect I still think that CoS enabled project should not show need compilation badges and this issue is valid.
For web/library scenario an enhancement/task could be filed. Would you agree?
Comment 6 Jan Lahoda 2008-11-05 21:16:30 UTC
Well, not, I still do not agree that disabling the "needs to be compiled" badges for projects with enabled CoS is good.
But, I am getting a bit tired with this ping-pong. So, here is what I am going to do: I am going to implement what are
you asking for. If there will be any issues/comments/etc. complaining about the behavior, I will relay them to you. If
you will not resolve them, or if you will assign/relay them back to me, I will suppose that you changed your mind w.r.t.
this issue, and revert the behavior of the NtbC badges back to the current state.
Comment 7 Jan Lahoda 2008-11-05 21:20:14 UTC
(I mean I will disable the NtbC badges for CoS enabled projects. You can of course file an enhacement/task for the other
idea, but do not be surprised if will not be implemented - I am not sure if it is implementable at all in reasonable
quality.)
Comment 8 David Konecny 2008-11-06 01:36:20 UTC
Honzo, I'm sorry you feel frustrated about this. It was not my intention.

Re. "If there will be any issues/comments/etc. complaining about the behavior, I will relay them to you." - I'm open to
change my opinion on this if somebody brings convincing arguments why it should be different. Until then I'm happy to
stand by this decision and provide rationale.

Re. enhancement - I filed it as issue 152470. It is slightly modified/simplified result of what we talked here about. I
would be interested in what you think about it and whether it could help this issue as well? I would stop by your desk
and talked about it in person if I did not sit on the other side of the world. :-)
Comment 9 Jan Lahoda 2008-11-07 09:32:24 UTC
Disabled for J2SE Project. You might want to do something similar in web.project (or maybe in common? - up to you).
http://hg.netbeans.org/main?cmd=changeset;node=35745920844d
Comment 10 Quality Engineering 2008-11-07 16:18:03 UTC
Integrated into 'main-golden', will be available in build *200811071401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/35745920844d
User: Jan Lahoda <jlahoda@netbeans.org>
Log: #149898: disabling the needs to be compiled badges when CoS is enabled.
Comment 11 David Konecny 2008-11-09 23:05:55 UTC
Thanks.

I was hoping the fix would be done in java.api.common (QuerySupport.createFileBuiltQuery) so that all "java based"
projects get the same behaviour. It is a friend API module so if something is missing it should be easy to add (eg.
whether compile-on-save is enabled in a project type - that might be useful in future regardless of this issue). Filed
issue 152829 and leaving new web/j2ee project types owners to deal with this.