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 134760 - Find Usages across chained module suites
Summary: Find Usages across chained module suites
Status: RESOLVED WONTFIX
Alias: None
Product: apisupport
Classification: Unclassified
Component: Project (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: issues@java
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-05-09 08:42 UTC by _ moser
Modified: 2008-05-14 18:23 UTC (History)
3 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 _ moser 2008-05-09 08:42:23 UTC
Unfortunately I just experienced that "Find Usages" and other refactorings do not work accross chained module suites.
E.g. if I invoke "Find Usages" on a method of a class from a base suite's module (accross all open projects), the usages
in modules of subsuites are *not* listed even if they are open.

This is a real showstopper for using chained module suites, in my eyes.

Frank-Michael
Comment 1 Jesse Glick 2008-05-13 03:20:58 UTC
Right, because there is no association between the *copy* of a module project's JAR which goes into the intermediate
platform, and the module project's sources.

Sorry but chained suites are not really recommended in general; there are numerous drawbacks. Best to keep all modules
which might interact in one suite, and use Ant targets to make packaging decisions later. There is no plan to change how
suites work short of a complete rewrite.
Comment 2 _ moser 2008-05-13 10:38:05 UTC
This is very bad news. If "chained suites are not really recommended in general" what else is the recommended way to
reuse modules across different suites without copying?

I see that there are drawbacks with the chained suites, but what is the alternative. Also it would have been nice to
clearly say that refacting does *not* work with them in the harness readme file and mark this technique as somehow
deprecated. I have spent weeks to fine-tune the directory layout and build environment of my freshly migrated RCP. As
for now I have to rethink and rebuild that all to get refactoring back. No refactoring simply means no chained
module-suites.

From a more general point of view, in my eyes there must be a simple way to reuse modules between suites, the simple as
reusing classic components. So there must be a high priority issue to either wipe out the drawbacks of chained suites or
to create a fully featured alternative for for multi-suite developement.
Comment 3 err 2008-05-13 16:56:37 UTC
Moser,
You might try connecting with some of the work done by Fabrizio Giudici; he has blogged some excellent stuff on
working around NB's problems with developing large RCP apps
http://www.tidalwave.it/infoglueDeliverLive/ViewPage.action?siteNodeId=270&languageId=1&contentId=1655 
and most importantly
http://weblogs.java.net/blog/fabriziogiudici/archive/2007/11/netbeans_rcp_be.html .

> From a more general point of view, in my eyes there must be a simple way to reuse modules between suites, the
> simple as reusing classic components. So there must be a high priority issue to either wipe out the drawbacks of
> chained suites or to create a fully featured alternative for for multi-suite developement.

I recall considerable heated debate about this. The bottom line seems to be that large project RCP support with NB is
not a priority at this time.
Comment 4 _ moser 2008-05-13 17:22:14 UTC
Thanks for the pointers. I had a look at the nice stuff, but I do not see how these tools enable refactoring accross
platforms. 

Also for me this issue is less about *large* suites but more about *multiple* suites. Currently NetBeans Platform is not
 RCP but SCP (Single Client Platform): There is *no* feasible way to reuse a module in two suites and that's really sad.
Comment 5 Jesse Glick 2008-05-14 18:23:47 UTC
Generally it is going to be more reliable to put all your modules in one suite. You can still do various things with the
modules, e.g. have different Ant targets to create or run different products with different subsets of the modules. A
"suite" doesn't do a lot more than contain a bunch of modules and specify a base platform.

Certainly how suite projects work is not desirable for the long term. Right now there is no one dedicated to rewriting
the infrastructure. Conversion to Maven is the most plausible option but will involve nontrivial investigation and
development.


Regarding the particular issue of source associations for modules in a lower suite, it should suffice to

1. Define a platform in NetBeans Platform Manager corresponding to the derived platform (P2 in README terminology).

2. Specify the basedir of the lower suite (S1) as the sources for this platform.

This trick is documented in README in step #4 and with that, cross-suite refactoring and find usages works fine (to the
best of my knowledge).

Since suite chaining is not fully supported, the IDE does not "know" that P2 is derived from S1 unless you tell it in
this way (and such information cannot currently be stored in a VCS). It might be possible to make the IDE know about
this association automatically in the case of a derived platform produced by the 'create-platform' target so long as you
did not move it from its default location (${basedir}/dist/${appname}).