Geertjan's Blog

  • July 9, 2008

JFugue Music NotePad & the NetBeans Platform Setting

Geertjan Wielenga
Product Manager
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.

Join the discussion

Comments ( 8 )
  • Jesse Glick Wednesday, July 9, 2008

    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.

  • Geertjan Wednesday, July 9, 2008

    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).

  • Geertjan Wednesday, July 9, 2008

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

  • Jesse Glick Wednesday, July 9, 2008

    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.

  • Tom Wheeler Wednesday, July 9, 2008

    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.

  • Jesse Glick Wednesday, July 9, 2008

    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).

  • Tom Wheeler Wednesday, July 9, 2008

    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.

  • Tom Wheeler Thursday, September 11, 2008

    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.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.