Bug 206540 - Incorrectly displayed error badges on performance/*
Incorrectly displayed error badges on performance/*
Status: STARTED
Product: ide
Classification: Unclassified
Component: Performance
7.1
PC Linux
: P4 (vote)
: TBD
Assigned To: Tomas Hurka
issues@performance
issue_reviewed
: TEST
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-19 13:54 UTC by Petr Cyhelsky
Modified: 2012-06-11 07:17 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Cyhelsky 2011-12-19 13:54:51 UTC
Product Version: NetBeans IDE Dev (Build 201112180600)
Java: 1.7.0_02; Java HotSpot(TM) Client VM 22.0-b10
System: Linux version 2.6.38-13-generic running on i386; UTF-8; en_US (nb)

steps to reproduce: run "ant" in nb repository to build all clusters. -> open performance module and its two submodules: j2ee, j2se in netbeans(run with clean userdir). After some scanning there are many red badges. 

If you run the same scenario but build the three projects first, there will be no error badges.
Comment 1 Jan Lahoda 2011-12-19 17:54:19 UTC
Before the performance module is built, this is missing on the j2se project compile classpath:
.../nbbuild/netbeans/extra/modules/org-netbeans-modules-performance.jar
which is there when the performance module is built. There is therefore no way for the parser to find the classes from the performance module.
Comment 2 Jesse Glick 2011-12-19 19:01:37 UTC
Not a general problem, just applies to these pseudo-modules which are not really supported by the build harness generally.
Comment 3 Jesse Glick 2011-12-19 20:06:24 UTC
The issue is that performance is a netbeans.org-type module, but performance/j2se is a standalone module - and standalone modules cannot depend on anything in their platform that is not built yet.

Temporary workaround is to force a recalculation of metadata by e.g. editing performance/j2se/nbproject/project.xml (add space and delete) and saving.

Cleaner would be one of these options:

1. Make performance.j2se a top-level dir in the main repo, named according to the usual convention (so org.netbeans.modules.performance.j2se), and make it nb.org-type module rather than standalone (so delete <standalone/>, make build.xml import projectized.xml, delete build-impl.xml & platform.properties). Then it can depend on other nb.org-type modules, whether built or not.

2. Make performance and its submodules be part of an external suite, which could not be directly in main or contrib but could be in (e.g.) contrib/other or misc. Then they can have whatever interdependencies make sense. They could employ nb.org modules as test deps but not depend on the tests of those modules (i.e. <test/> in <test-dependency>).

3. Dissolve these modules and move them into functional test dirs of relevant nb.org modules, e.g. java.kit.
Comment 4 Jaroslav Tulach 2011-12-20 09:06:10 UTC
This is a known flaw. When creating performance/xyz modules, we intentionally made them a standalone modules (I don't remeber why - #3 would be an option, I guess). They depend on performance module (which is not part of any standard config). If you build performance module before starting the IDE, errors will be gone.

The apisupport.project could be a bit more clever and watch for changes in JARs inside of the platform, however.
Comment 5 Quality Engineering 2011-12-20 15:56:21 UTC
Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/26c861b0abe3
User: Jesse Glick <jglick@netbeans.org>
Log: Improving diagnosis of #206540 (missing test dep).
Comment 6 Jesse Glick 2011-12-20 23:41:30 UTC
(In reply to comment #4)
> apisupport.project could [...] watch for changes in JARs inside of the platform

Might work - e.g. listening for changes in */update_tracking. Not sure if this is a common enough use case to merit the added complexity.
Comment 7 Jaroslav Tulach 2011-12-25 15:19:17 UTC
Rather you should listen for config/Modules changes. Btw. It would help us with our integration with JDeveloper as well.
Comment 8 Jesse Glick 2011-12-27 18:01:42 UTC
Report a separate issue if you want. It would still be better to rework the performance pseudomodules so dependencies are understood correctly even without doing a build.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo