Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 83088 - Target platform cannot include external clusters
Target platform cannot include external clusters
Status: RESOLVED FIXED
Product: apisupport
Classification: Unclassified
Component: Project
5.x
All All
: P2 with 2 votes (vote)
: 6.x
Assigned To: rmichalsky
issues@apisupport
APISUPPORT_ISSUES tb20071015
:
: 114389 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-21 14:11 UTC by Jiri Prazak
Modified: 2009-05-05 08:49 UTC (History)
6 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Prazak 2006-08-21 14:11:23 UTC
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.
Comment 1 Jesse Glick 2006-08-21 16:30:02 UTC
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.
Comment 2 Adam Sotona 2006-08-22 13:04:57 UTC
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?
Comment 3 Jesse Glick 2006-08-22 21:02:21 UTC
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.
Comment 4 Jesse Glick 2007-08-31 15:40:54 UTC
*** Issue 114389 has been marked as a duplicate of this issue. ***
Comment 5 hallorant 2008-07-23 02:41:57 UTC
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)
Comment 6 Jesse Glick 2008-09-23 19:24:08 UTC
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.
Comment 7 _ wadechandler 2008-09-24 15:23:49 UTC
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.
Comment 8 rmichalsky 2008-09-24 16:07:09 UTC
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.
Comment 9 rmichalsky 2009-05-05 08:49:07 UTC
already solved by issue #152960


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