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.
JDK: 1.5.0_06 Build number: 200510131600 - Q-build During ModuleBackward compatibility testing I found the problem with Profile Main Project action. It is disabled. When I tried to run Attach Profiler action, it worked fine. So I don't know where is the problem. ------------------------------- Here are details how do I test it: - installed modules are all modules available as NBMs from Profiler M8, that was developed against NB.1 - The following module dependencies could not be satisfied:: MODULE: org.netbeans.modules.profiler.j2ee.tight.sunas8/1 modules org.netbeans.modules.j2ee.sun.ide/1 = 1.0 MODULE: org.netbeans.modules.profiler.j2ee.tight.tomcat5/1 module org.netbeans.modules.tomcat5/1 = 200505031930 - Turning on modules: org.netbeans.modules.profiler/1 [0.8 0.8] org.netbeans.modules.profiler.j2ee.jboss/1 [0.80 0.8] org.netbeans.modules.profiler.j2se/1 [0.80 0.8] org.netbeans.modules.profiler.j2ee/1 [0.80 0.8] org.netbeans.modules.profiler.j2ee.weblogic/1 [0.80 0.8] org.netbeans.modules.profiler.j2ee.sunas/1 [0.80 0.8] org.netbeans.modules.profiler.freeform/1 [0.8 0.8] org.netbeans.modules.profiler.j2ee.tomcat/1 [0.80 0.8]
I expect this is reported against profiling a web project. The reason is that modules ~.tight.sunas8 and ~.tight.tomcat declared implementation dependencies on some other modules to be able to use some features not available in their public API. This worked only for final build of NB 4.1. For NB 5.0 new (public) API was added for profiling web projects and it is used by Profiler Milestone 9. Here is the map of supported Profiler & NB configurations: Profiler M8 -> NetBeans 4.1 Profiler M9 -> NetBeans 5.0beta (won't work with latest daily/qbuilds) Profiler M10 (to be released soon) -> NetBeans 5.0beta + latest daily/qbuilds
Sorry, this happend with JavaApplication project. So what is the reason for disabled action? Sorry for disturbing, but we need to evaluate this case.
OK. Which version of NetBeans are you trying to use with Profiler M8? From the build number I expect that it's NB 5.0.
NB5.0
As I wrote before, only NetBeans 4.1 are supported by M8, it isn't expected to work with any version of NB 5.0. For that version the M9 was released. Concrete problems with ~.tight.sunas8 and ~.tight.tomcat5 modules are caused by the fact that NB 5.0 use modules with different implementation versions than in NB 4.1 (which is quite expectable) and thus implementation dependencies of Profiler modules are broken. In fact this has nothing to do with webprojects/javaapps as the modules are loaded (and eventually disabled) during NB startup independently on any project type. Is there any special reason why M8 should work in NB 5.0 and any problems with it should be evaluated? If not, please close this issue.
> Is there any special reason why M8 should work in NB 5.0 and any problems with > it should be evaluated? If not, please close this issue. Yes, it is. I am testing Module Backward compatibility. So we decided to use for these tests the only one real-test - reuse existing modules, developed against NB4.1 and try to use it with NB5.0 Regarding implementation dependencies & version numbers, there has already been fixed problem with version numbers. We have a conversion file, for more details see issue 65729.
Mariane, can you please explain what is the problem we should solve? Indeed we used some hacks in 4.1 that seized to work in 5.0. E.g. the fact that the namespace and project file version changed in 5.0 is one such thing - a profiler designed for 4.1 can not read files written by future version of the IDE (if there was an API for what we need to do, it would work, but there isn't any). We will not come back and fix M8. M9, M10, etc. are the evolution of the codebase. I am confused as to what you are asking us to do here.
Ian, thanks for axplanation. > the fact that the namespace and project file version changed > in 5.0 is one such thing that's exactly information I've been asking for! > can you please explain what is the problem we should solve? there is no "problem to solve", only thing I've been asking for is the reason why it doesn't work. > We will not come back and fix M8. M9, M10, etc. are the evolution of the > codebase. I am confused as to what you are asking us to do here. Sorry for confusion, but I haven't been asking to do something. I've been asking for the reason, why is the action disbaled. Look at my previous comments, there is no word about asking to fix something, the whole issue is investigation why is this action disabled, nothing else. Anyway please correct me if I am wrong, but in the light of these informations we can say: There was an incompatible change in the namespaces and project file version in NB5.0. Am I right? This is the most important information from the compatibility testing point of view. Thanks for help and I am really sorry for wasting your time.
This was filed as a P3 defect against profiler, and we've been treating it as such, thus the confusion with the issue and reopening it after our evaluation. From looking at the extent of communication inside this bug, it is clear we've spent large amount of time resolving something that was not clearly described. If the issue was entered as "4.1 profiler does not work in 5.0, tell us why" it would be a five minutes excersise. We had very little context about what you were doing and why and did not have enough information to understand. Back to the issue: The change is indeed incompatible, but the project namespaces and project.xml format is not a stable API, so I do not think this can be classified as incompatible API change.
Thanks, verified