Nimbus with JNLP

We want to use the Nimbus look and feel in our project and use the following code in our Installer.restored method (as described at http://download.oracle.com/javase/tutorial/uiswing/lookandfeel/nimbus.html):

try {
    for (LookAndFeelInfo info : UIManager.getInstalledLookAndFeels()) {
        if ("Nimbus".equals(info.getName())) {
            UIManager.setLookAndFeel(info.getClassName());
            break;
        }
    }
} catch (Exception e) {
    // If Nimbus is not available, you can set the GUI to another look and feel.
}

And this works nicelly! However, due to 

https://netbeans.org/bugzilla/show_bug.cgi?id=190175 this 

does not really work with jnlp yet... I'll be back!

*** 2010-12-09 ***

By adding  the following to you master.jnlp Nimbus is run on webstart too 

(wouldnt mind having 190175 fixed anyway but still...):

  <application-desc>
    <argument>--laf</argument>
    <argument>com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel</argument>
  </application-desc>

Netbean Platform Locale in zip-build

Ok. I want to run our netbeans platform-based application in Swedish regardles of locale settings used in development IDE. Turns out that if I use Netbeans IDE in Swedish everything looks fine while executing the application from within the IDE (it starts and run in Swedish) but if I build an independet zip, it starts in english (15 minutes of googling lets me know that this is a pretty common complaint). However, there is an uggly fix while we wait for the following to bugs to be completed:
http://netbeans.org/bugzilla/show_bug.cgi?id=133901 (vote for them)
http://netbeans.org/bugzilla/show_bug.cgi?id=157031

After you  have build your zip-distribution (or jnlp distribution), you need to copy
the following libraries from your netbeans installation into corresponding locations in your application:
platform/core/locale
platform/lib/locale
platform/modules/locale
platform/modules/ext/locale

You also have to edit your .conf file located in your_app/etc/your_app.conf
find default_options and add this: -J-Duser.language=sv --locale sv (change sv to your locale setting).

All of the above is automated with Ant and only applicable if you have the original IDE with your desired locale to begin with...

Edit:

To enable locale translations in zip builds and jnlp builds I ended up using the build in 

support for Branding. Here you can enter your own values to pretty much any property-file 

in your project. And the locale data is stored in files accessible here.

However, entering all those translations here just isn't a realistic option so what I did was that I 

changed one or two properties here so that I could see what and how this changed was 

stored in my project. It turned out that it is stored in file and directory hierarchy much similar 

to how the localized jars are stored. 

So, what I did was this:

I downloaded the platform locale project from http://hg.netbeans.org/main/l10n/ using Mercury.

From there I chose the sv branch since I'm interested in the swedish locale. Then I copied 

the each sub directory corresponding to the jar I was wanting to translate into the projects 

branding directory. After copy there was two things that had to be done: 

1) rename the top directory (add ".jar" to its name) 

2) rename the Bundle_sv.properties file that contains the translations.

This all may sound complicated but in reality was quite simple 

(but it took about 1.5 hours to do it manually for my project). Take a look at the branding tool 

and what it does when you change a value in one of the properties (it's browsable in the 

branding directory in the Files tab of your project) if you need a hand.

And just like that, you have locale data build in to you zip and jnlp builds!

Encoding magic

Ok, so the other week I spent two days on trying to lure my Netbeans project to execute with the possibility to read utf-encoded xml on windows platforms. Reading through, and trying, multiple sites with advice on how to set the file.encoding in a variety of project and platform settings files, I finally changed my xml-reading implementation from getClass().getResourceAsStream("guide.xml") to
new InputStreamReader(getClass().getResourceAsStream("guide.xml"), "UTF-8").

Just like that. If this is usefull to someone else I'm happy...