Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 91369 - App that depends on ide7 cluster modules fails to start
App that depends on ide7 cluster modules fails to start
Product: apisupport
Classification: Unclassified
Component: Harness
All All
: P1 (vote)
: 5.x
Assigned To: Jesse Glick
Depends on:
  Show dependency treegraph
Reported: 2006-12-20 20:46 UTC by Nathan Fiedler
Modified: 2007-02-01 16:50 UTC (History)
0 users

See Also:
Issue Type: DEFECT

Test module that demonstrates problem (147.46 KB, application/x-compressed)
2006-12-20 20:47 UTC, Nathan Fiedler

Note You need to log in before you can comment on or make changes to this bug.
Description Nathan Fiedler 2006-12-20 20:46:35 UTC
Since NetBeans 4.1 I have been writing an application based on the NetBeans
Platform, with some additional modules copied from the ide* cluster. This has
worked just fine up through version 5.0. Now, in NB 5.5, this is no longer
working. It appears that the harness is not including the ide7 cluster when
starting my application, and thus module dependencies are not resolved and it
fails to start. I have created a simple test module that demonstrates this
problem. It has everything you need (minus JDK and Ant) to test this issue.
Simply take the soon-to-be attached file and do the following:

1. Edit the file such that the paths are appropriate for your
2. Invoke "ant -f prepare.xml" -- that will fetch the NB Platform binary,
extract it, and copy the classfile.jar to the "ide7" cluster and enable it.
3. Invoke "ant clean netbeans run"

If you set to point to the 5.5 binary, the app will fail to
start. Now change to use the 5.0 binary instead and do steps 2
and 3 again. This time it will load all of the modules and start up fine.

I am probably doing something wrong, but I cannot tell what. As far as I know,
this should be working, but it mysteriously fails. Maybe my build process is
completely stupid, but I haven't found a better way yet.

BTW, I tried using the NB Ant debugger but it fails to show the variables at the
crucial point, so it is useless.
Comment 1 Nathan Fiedler 2006-12-20 20:47:18 UTC
Created attachment 36855 [details]
Test module that demonstrates problem
Comment 2 pzajac 2007-01-05 13:10:51 UTC
Are you really sure that it is our bug?

I removed two lines in build.xml:

    <property file=""/>
    <import file="default-properties.xml"/>

Building  of project seems to be working. 

If project points to wrong platform you can change it in customizer of project. 
Comment 3 Jesse Glick 2007-01-05 21:04:58 UTC
I'm afraid I do not follow what your build script is doing, or even what
properties I am supposed to edit, or what exactly they should point to. The
script looks like it will modify my NB installations but I cannot really tell.
Nor am I sure why I am supposed to be editing paths to NB installations when
prepare.xml seems to be downloading the NB platform anyway...? If I have it
installed locally then I do not need to download it.

Your prepare.xml hardcodes a cluster name which changed from 5.0 to 5.5, so I
would hardly expect it to work identically.

I don't really follow why you wrote all this, anyway, unless it is because you
started in NB 4.1. If you just make a regular module suite, you can pick which
clusters to include (and which modules within those clusters), all through the
Comment 4 Nathan Fiedler 2007-01-06 00:09:25 UTC
I entered this bug because I saw a change in behavior and I thought I would do
you a favor and let you know about it. Scott Kaylie had the same problem as I,
and asked a question on nbdev, but no one answered him. He and I came to the
conclusion that there must be a bug in NB.

Jesse: This build process was developed before apisupport had gotten its
overhaul. Since my process seems to fall outside the realm of understanding, and
because I have developed a much simpler process that relies on the new
apisupport (with scripts to work-around the backward module enable ui, and to
package a distributable that contains only what I need), I no longer care about
this problem. If you don't care either, then it can be closed.

BTW, hard-coding the cluster name works perfectly fine. I had left it that way
to make the example as simple as I could. Clearly it was not simple enough.

Petr: commenting those two lines of the build.xml renders the entire build
process null and void. Unless you had tried to build an application based on NB
Platform with some IDE modules during version 4.1, you will never understand the
Comment 5 Jesse Glick 2007-01-06 00:20:34 UTC
If some portion of the apisupport harness fails to behave as documented, that is
a bug we want to fix. However I am unable to follow your instructions as
currently given.
Comment 6 Nathan Fiedler 2007-01-06 00:26:34 UTC
Forgot to explain something else: the reason for this script is that it was to
fill in the missing pieces of the apisupport at the time. It provided support
for JavaHelp, JUnit tests, assembled the clusters and modules that I needed, and
provided an easy means of creating the distributable (just zip up the
installation that it creates).

The way the script works, it assumes that you do _not_ have an installation of
NB. It downloads the NB IDE source, builds the Platform, then builds the IDE
modules and copies those that it needs to the new installation. By building the
IDE from source, I get JavaHelp and JUnit for free. I hope that makes sense.
Comment 7 pzajac 2007-01-08 17:46:47 UTC
I know that to developing modules against nb41 is very difficult. I did it with
workaround. I made symbolic links to structure of netbeans cvs. I was happy that
 Jessy developed Module suites. I recreated all my modules from scratch in
module suite and only copied sources and nbproject/project.xml to new layout.    
Comment 8 Jesse Glick 2007-02-01 16:50:13 UTC
> 3 weeks, no new information. Reopen if you have any.

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