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.
There is a big issue with the way the build system currently works. Our product is based on NetBeans and is a separate cluster of modules that we need other users to actively develop on and the way things are at the moment, they simply cannot. To do so they have to go to great lengths to get something done, as a matter of fact it is quicker not to use API support at all! Let me outline the problem. I'm building a module that uses API that is part of the mobility suite, therefore I have to build on top of it. However my module cannot be built against these modules but only against NetBeans Platform. This means that I have to either * run the mobility suite inside the IDE (1 instance), then develop my new module in the second instance (2 instances now) which has the cluster loaded and then finally test it in yet another instance started from the second (3 instances needed). This is ludicrous :-( * copy the new cluster and hack it into NetBeans so it gets added to the platform. Then use that but this has its drawbacks as follows.. Even if I do this, it is still pretty much useless because I also work on the mobility suite itself. So when I make some changes to that, I have to manually rebuild the platform, restart it, test it and then build the new module on top of it again to see if things work. Also no JavaDoc and code completion is available for our module suite, because they are used in the NetBeans platform as binary. We need this dependency problem solved baaad. Currently this is an extremely hot issue for us and severely bogs down our productivity and as such should be dealt with soon. Please invite me or asotona to any discussions regarding the API support and related build system planning in the future as we feel like no one listens to what we need even though we have had a pretty successful product that we build on top of NetBeans. We have discussed this with Tonda Nebuzelsky last week so he should be up to speed on this issue.
It could be a lot of work to implement this, TBD. I don't know if we have any plans to do any serious work on apisupport. The recommended approach, detailed in harness/README ("suite chaining"), is to create a new platform containing both the core NB platform/IDE plus your extra cluster(s), and set that as the target platform for your module development. You should be able to easily set up an Ant target to recreate this platform on demand, perhaps automatically as part of the build of your module, so no extra steps are required during development. Re. Javadoc and source associations: this should work if you add appropriate entries to the NetBeans Platform Manager for your target platform. You would need to include both the nb.org CVS root (for the core platform), and the suite dir for mobility.
Let me add some more arguments to push this issue. Now the only CLDC Pack consists of 19 independent modules (source roots) so setting up the platform sources manually for Mobility is 19-times more complicated then setting the platform sources for all the other NetBeans modules. And this will be required for all develpers that we (or any other other Packs) want to persuate to contribute to NetBeans. By skipping this manual source-roots setup we dispose the features like debugging, javadoc, goto-sources. Another important use case for us is ability to share some modules between two Packs. Currently we plan to provide some mobility core that we be used in both packs: CLDC Pack and CDC Pack. NetBeans architecture already contains this pattern however Apisupport achitecture does not allow to do so. NetBeans module and clusture architecture is already layered and allows various types of dependencies however this is allowed only to a listed set of modules and everything else is treated as an exception. One close analogy: Would it be acceptable way for any other NetBeans project type to depend on a library project by copying the library jar into a lib/ext of the JDK and to force developers to manually setup the source roots of all the libraries inside the Java Platform Manager?
asotona: your modules should all be placed into one suite, probably. There is no particular reason why you cannot build any number of "packs" from a single suite. Also re. source setup, remember that NB Plaf Mgr associates sources per whole *suite*, not per module, so it does not matter if you have 19 or 190 modules in that suite. BTW nb.org source layout is indeed an exceptional case for historical reasons that we plan to resolve at some point in the future. Cannot do it now because there is zero progress from build masters in defining what Ant entry points they require. Again, this is a reasonable feature request, but I don't know if we have time to spend on it. For now I would rather ensure that you are using the correct workarounds. Currently it sounds like you are not.
*** Issue 114389 has been marked as a duplicate of this issue. ***
I have a module suite for visual-vm and a module suite for NetBeans, however I'm having trouble getting both suites to share modules that I have developed. You can view it as If I have 'common' 'visual-vm-client' and 'netbeans-client' and I want: visual-vm-suite to contain 'common' and 'visual-vm-client' netbeans-suite to contain 'common' and 'netbeans-client' This doesn't seem to be allowed as the IDE (6.1) keeps wanting me to change the association. This is horrible, and I was pointed to this bug as the root of the problem. With the release of VisualVM this seems to be a bigger issue as I can't have a suite for both NetBeans IDE and VisualVM (currently)
Probably WONTFIX. The harness is too complicated already and we should not make it worse. Complex scenarios are probably better handled by Maven. Suite chaining already works for the case that you are building on a derivative platform created by someone else. In case you in fact "own" all the non-NB source modules, you do not even need suite chaining - you can create multiple products out of one suite using simple configurations (i.e. sets of Ant properties), which may have direct GUI support in the future.
Jesse, Re. "you can create multiple products out of one suite using simple configurations (i.e. sets of Ant properties), which may have direct GUI support in the future." Is there any more information on this? Is there a tutorial or some documentation some where? If not, can you post the steps here so that Tom, me, or someone can make some entries in the Dev FAQ? Thanks.
Re "Is there a tutorial or some documentation": I plan to create sample project with such a setup (based on info from Jesse), however I will not get to it before code freeze of 6.5. Of course I'll appreciate if anyone wants to try it sooner.
already solved by issue #152960