JFugue Music NotePad & the NetBeans Platform Setting

When I check out http://nbjfuguesupport.dev.java.net/ and I then build the suite, I see the following in the Output window:
/home/geertjan/Desktop/nbj/nbjfuguesupport/build.xml:7: The following error occurred while executing this line:
/home/geertjan/Desktop/nbj/nbjfuguesupport/nbproject/build-impl.xml:19: You must define 'nbplatform.NetBeans_IDE_5.5.1_(Build_200704122300).harness.dir'

To fix this:

  1. Right-click the "Music NotePad" node in the Projects window.
  2. Choose Properties and then go to the Libraries node.
  3. In the "NetBeans Platform" drop-down, browse to the main folder of NetBeans IDE 5.5. Click Next and Finish.
  4. In the "NetBeans Platform" drop-down, make sure that you now see "NetBeans IDE 5.5", together with the name of some 5.5 build. Then click OK.
  5. Now run the application and it will start without a problem.

In other words, the message above appears if you haven't set the platform for the JFugue Music NotePad. The platform (i.e., the NetBeans Platform) provides the underlying modules that the application is built on top of. Currently, the platform used by the application is NetBeans Platform 5.5 (or 5.5.1), which doesn't mean that you can't use NetBeans IDE 6.x for development purposes, of course.

Comments:

Give your platform a more generic name, e.g. "nb55". The choice of platform is done by ID, and this is persisted in the versionable platform.properties, so it should be something suitably lax. Then someone opening the project need only create a platform with the same name and the suite should work without being modified.

Posted by Jesse Glick on July 09, 2008 at 01:19 AM PDT #

Thanks! Good tip. I renamed it 'nb55'. Now if someone already has a platform registered with that name, the suite should be able to run as soon as you've opened it in the IDE (such as NetBeans IDE 6.1, for example).

Posted by Geertjan on July 09, 2008 at 01:27 AM PDT #

So, the changed platform name is now committed to the nbjfuguesupport CVS repository.

Posted by Geertjan on July 09, 2008 at 01:27 AM PDT #

BTW I looked at making the Add NetBeans Platform wizard pick a cleaner name automatically. The Add Java Platform wizard already does this, e.g. "JDK 1.6", based on ${java.specification.version}. Unfortunately it is much trickier to determine what "version" a NetBeans installation is, since it is made up of many independent modules, and the (localizable) window title label may or may not include "Dev", build numbers, etc. When you get into custom platforms, it gets even worse. So for now the wizard just defaults to using the window title but you are advised to choose a more generic name if you expect the platform to be used by projects shared with others.

Posted by Jesse Glick on July 09, 2008 at 01:52 AM PDT #

There are inherent dangers associated with developing against your own IDE as the platform. In particular, another person may have a different version of the IDE, have different modules/clusters installed or even have simply named the platform something different. This can result in a broken build or the introduction of unwanted features.

If you want to avoid these problems, you can check the platform you want to build against into source control and then set the netbeans.dest.dir and harness.dir properties in your suite's project.properties file to point to the platform and harness, respectively.

All of this is made more difficult because there's unfortunately no platform binary download from netbeans.org anymore, but it's possible to build your own by creating a new suite, excluding all but the platform cluster and building a ZIP distribution from that.

Posted by Tom Wheeler on July 09, 2008 at 02:48 AM PDT #

While you could check a platform into source control, it should suffice to just settle on a stable public release, e.g. "nb60". Anyone with a NB 6.0 installation (IDE of any size) can use it as the platform.

If you do need to make a platform from an IDE, it is easiest to just make an empty dir and then copy the "platform\*" subdir from the IDE into it; optionally also "harness" (if you want to use a fixed harness rather than that associated with the development IDE).

Posted by Jesse Glick on July 09, 2008 at 03:02 AM PDT #

Regarding just settling on a specific release, I respectfully disagree.

Consider the case where some members on a team install updates while others do not. The application built by developers who installed the patches will be different than that built by the others. This is really a difficult problem to track down (and I speak from experience).

Likewise, because modules in a cluster are excluded (rather than included) in platform.properties, a developer who has installed something extra from the plugin portal will include that module in the releases he builds but that module would not exist in releases built by others.

Building from a known version checked out from source control avoids these problems and makes it possible to historically reproduce any build.

Posted by Tom Wheeler on July 09, 2008 at 03:32 AM PDT #

I just noticed my comment from 9:48 AM says "in your suite's project.properties file" but should say "in your suite's platform.properties file" instead.

Posted by Tom Wheeler on September 11, 2008 at 01:59 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Geertjan Wielenga (@geertjanw) is a Principal Product Manager in the Oracle Developer Tools group living & working in Amsterdam. He is a Java technology enthusiast, evangelist, trainer, speaker, and writer. He blogs here daily.

The focus of this blog is mostly on NetBeans (a development tool primarily for Java programmers), with an occasional reference to NetBeans, and sometimes diverging to topics relating to NetBeans. And then there are days when NetBeans is mentioned, just for a change.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
12
13
14
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today