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.
Summary: | "Needs to be compiled" badge shown on Java nodes when CoS enabled | ||
---|---|---|---|
Product: | java | Reporter: | David Konecny <dkonecny> |
Component: | Project | Assignee: | Jan Lahoda <jlahoda> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | jiriprox, phejl |
Priority: | P3 | Keywords: | UI |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 152191 |
Description
David Konecny
2008-10-13 02:46:29 UTC
this is expected behavior, see http://wiki.netbeans.org/FaqCompileOnSave 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? 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. 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? 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? 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. (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.) 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. :-) 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 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. 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. |