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.
[ BUILD # : Beta ] [ JDK VERSION : 1.5.0_01 ] Try this: 1) Clean & Build a project 2) All files' status will be 'not compiled' (binary icon) 3) Right-Click on a single file and choose 'Compile file' 4) Its status has changed to compiled (no binary icon)
Umm... what? After cleaning & building a project, all the uncompiled flags go away, as designed (contrary to what you say). After cleaning a project, the flags appear on all Java files. After pressing F9 on one of those files, the flag disappears from it. All working correctly for me.
Created attachment 20799 [details] Compile status
Attached is a screenshot showing the wrong compile status after a Clean & Build. The not-compiled state is removed only when pressing F9. It happened to me only with this Enterprise Application (everything build from scratch)
This is a J2EE project, reassigning accordingly. No steps to reproduce from scratch -> INCOMPLETE for now.
Tried it too, can't reproduce. Do you get the same behavior with a new project? Do you get the same behavior with any other projects too? Could you post a *very* simple project in which you still can experience the bug? Is the project on the screenshot included in an enterprise application?
The project was created form scratch, option I prefer from previous experiences with web applications. This is what I did: 1) Created a new Enterprise Application. 2) Created a new EJB Module. 3) Created the EJBs. 4) Added 'Bussines methods' and filled with old application code. 5) Added the EJB Module to the Enterprise Application. Looking further I found that 'build' creates: project build ear-module packages and classes whereas 'Compile single F9' creates: project build jar packages and classes which is what sets the compile status. Tough the Enterprise Application was a renamed project, iaejb is a brand new EJB Module, due NB4.1 demands a separated project.
It doesn't happen with other projects, only with the EJB Module.
I can reproduce it now. If I do clean & build on the EJB module, everything is fine. If I do it on the enterprise application which the EJB module was added to, files status is 'not compiled'. I experience this behavior in the Web project as well.
This is caused by the fact that the classes are built to different directories based on whether you build only the EJB project or the whole enterprise application. When you build only the project, they go to ${build.classes.dir}, otherwise they go to ${build.ear.classes.dir}. Not sure about the fix. I have two ideas: 1. Could add to the project's FileBuiltQueryImplementation both ${build.classes.dir} and ${build.ear.classes.dir} for each source root. This solution has the obvious disadvantage that you could have half the files compiled in the one build directory and half in the other one -- the project would look compiled, but that wouldn't be true. Moreover, this use case is currently not supported by AntProjectHelper.createGlobFileBuiltQuery(), which is used to implement FileBuiltQueryImplementation. 2. Could just always build to one directory. Not sure why the decision to build to different directories was taken. Pavle, do you know why?
TM 5.0 -> TBD
Reassigning to Pavel for evaluation. Pavle, please see my last post.
The reason for having 2 different build directories for EJB module is that packaging of libraries is different. When building standalone module build includes jar files into the module, when building EAR it includes them into the EAR and adds manifest entries into EJB module's manifest. The Java classes are always compiled in the same way. The reason why we do not put compiled classes into one location is that creating jar file is easier and also possibly for directory based deployment (though I am not sure if/how that works for ejb module). I think we could compile classes into one location. If directory deployment is an issue (I will have to check this) then we would compile classes into the directory where the standalone module gets compiled and when including the module into EAR we would use these classes to build the jar file.
App server is not actually using directory deployment for EJB modules. J2EE server makes it theoretically possible but it is not used. One correction to my previous proposal: If we copy classes into build\jar and then want to copy them into build\ear-module we would need to filter out other files. We could filter */**.class but it is not 100% bullet proof (if the user puts .class file into sources folder...). Sooo.. we should probably compile classes to a separate directory, e.g. build\classes and then use them to build the jar file together with build\jar or build\ear-module as needed. If we find issues with directory deployment we would fix them by copying build\classes into build\jar and/or build\ear-module, but for now it is not really needed. Andrei, let me know if this makes sense and if you want to fix this or you want me to take it. Thanks.
Is this even a P3 bug? Sounds like a P4 to me.
Yes, it seems this qualifies as a P4 according to the guidelines ("incorrect behavior that doesn't affect functionality").
Obsolete milestone, please reevaluate
Not valid anymore, the project is built to a single directory in 6.0.