mkleint

Like others (not that my timing or reasons correlate in any way with others), I've decided to move on and look for other opportunities outside Sun/Oracle. Working on NetBeans has been a great adventure of the last 10 years, I've enjoyed every minute of it. I wish my former coworkers all the best. I will surely remember NetBeans as one of the highlights of my career.


I've accepted a position at Sonatype, the Maven company. If you want anything Maven, it's us :) I will be working on m2eclipse and other Apache Maven related products. So I will still be around in a way, working for the good of Maven ecosystem, even when not working the NetBeans Maven integration (in any foreseeable future at least).


If you happen to be a Sonatype customer already (eg. by purchasing Nexus Pro) or are planning to become one and are using NetBeans in your team for developing Maven based applications, let me know. Either via Twitter or email.

This blog will probably not get update very often in the future. *If* I start blogging about my new work, it will most likely be at Sonatype..

Geertjan's old blog entry describes the general way of working with license headers. Let's add a few notes for all the Mavenites out there.

• There is no UI for setting the license for your project currently
• Use netbeans.hint.license property in your pom.xml file to point to the license header of choice. Please note that the ideal place for the property is the root parent pom of your project.
• There are few magic spots where it works out of the box. The Maven examines the <license> /<url> elements in the pom and when matching one of the hardwired urls, assigns the license header automatically. The current magic urls are:
  1. www.apache.org/licenses/LICENSE-2.0.txt
  2. www.opensource.org/licenses/mit-license.php
  3. www.gnu.org/licenses/gpl-2.0.html
  4. www.gnu.org/licenses/gpl-3.0.html
• There is currently no way to add this magical mapping to your custom license templates. If you have an OSS license that you would like be added, file an issue at netbeans.org (with the license template attached and url pointing to the license on the web.
• To have the license header added for your in-house non-OSS project, you can create a NetBeans module that will add the license header template declaratively. Ask me for details.

UPDATE: I've actually forgot to mention the name of the property to put in the pom.xml file. it's "netbeans.hint.license".

A way back I've written myself a small application to make geocaching easier to manage. It downloads geocache information, converts to gpx format (some sort of xml understood by the GPS device) and then writes to the GPS device - (Garmin Colorado) via USB. It's not really an application I'm proud of, it's full of hacks and the UI is also of stone age usability, but so far I wasn't able to find a better one.
Anyway, my wife suggested I install the app on her computer as well, so that she can upload a cache even when I'm not around. I've always run the app from command line or from the IDE, but that's not something I want my wife to go though :) Since she has a Mac laptop, I've looked into how to generate a Mac natively executable binary. It was easier than I though thanks to the wide and deep reservoir of Apache Maven plugins around. There is one for Mac applications as well - osxappbundle-maven-plugin. A simple copy&paste into my pom and there we have a nice geocaching.dmg file with the geocaching.app application. Great. The biggest obstacle turned out to be creation of the *.icns file with a custom icon for the application. It's created by the Icon Composer application (at /Developer/Applications/Utilities/Icon Composer) and it took me a while that it doesn't accept gif files but tiff image files. It's great when things just work and work in 15 minutes time..

And we've visited this geocache afterwards. A great trip.

.. is at bits.netbeans.org/netbeans/trunk/maven-snapshot/.

Since version 6.8 NetBeans provides annotations to simplify various NetBeans platform API usages. So you can register a ServiceProvider and the build process generates the proper META-INF/service entry. Other annotations are capable of generating layer file entries. So far this didn't work in Maven based project due to MCOMPILER-98 bug of the maven-compiler-plugin. The issue is fixed now, but it will take time to propagate into a released version of the compiler plugin. Here is how to enable it in your Apache Maven projects now.

Open your netbeans module project pom.xml file (or the parent pom of your module projects to configure all modules)
and add the following maven-compiler-plugin configuration:

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-compiler-plugin</artifactId>
   <version>2.1</version>
   <configuration>
     <source>1.6</source>
     <target>1.6</target>
   </configuration>
   <dependencies>
     <dependency>
       <groupId>org.codehaus.plexus</groupId>
       <artifactId>plexus-compiler-javac</artifactId>
       <version>1.7-SNAPSHOT</version>
     </dependency>
     <dependency>
       <groupId>org.codehaus.plexus</groupId>
       <artifactId>plexus-compiler-api</artifactId>
       <version>1.7-SNAPSHOT</version>
     </dependency>
   </dependencies>
</plugin>


Since you are depending on unreleased snapshots, a snapshot repository declaration pointing to Plexus snapshot repository is necessary.

Afterward you are ready to use the annotations in NetBeans APIs. Enjoy!

Configuring Maven projects and adhering to the declared best practices can be sometimes tough. I've tried to come up with a solution based on the IDE and task oriented UI for that.
How does it look like? First there are code generators directly in the pom.xml file (In NetBeans accessible from the editor's popup menu, main menu or via Alt-Insert shortcut) For each supported usecase there is one item that either appears all the time, or only when the relevant configuration is not present. Eg. If the IDE figures you already have the Maven Site, it shall not offer you to generate it.

Second there is a new panel into the Project Properties dialog that does approximately the same thing, It's called Generators and lists the available tasks. It will also show the ones that are recognized to be present in the project already. Ideally some generators shall appear on other panels (like Scala or Groovy language configuration which shall be placed in the Sources panel) but there's only APIs to plug new panels to the dialog, not into existing ones.

And what do the actual generators do? They add dependencies and/or plugins to your pom. Eventually some basic configuration. It's smart enough to figure that you have the dependency/plugin version managed already and omit the version in that case. At the same time for "pom" packaged projects it will prefer adding the plugin/dependency management section as well. If you already define the plugin or dependency, it will skip it during generation. So it should be smarter than plain copy & paste from the maven plugin's website.

And what generators are currently implemented?

• Maven SIte - it creates the site.xml file for you, adds and configures some basic report plugins.


• Scala - creates the scala source roots and adds the scala-library as dependency, configures the maven-scala-plugin. Please note that in order to have the Scala editor support you will need to install the Scala related NetBeans modules.


• Groovy - as as with Scala, source roots, dependency and plugin config to get started with writing your projects with Groovy


• Javarebel profile that adds the necessary configuration for running with Javarebel jvm agent


• You have ideas for more? Please add your suggestions at the comment area.

And where can you get the thing? It's available from
kenai.com, should work in 6.7+ (thus also in 6.7.1 and 6.8M1). Please note that some Scala/Groovy integration fixes only appear in 6.8M1. There's 2 zip files. Both are approx same quality, the latest one is a snapshot only though as it's using currently unreleased 2.8.0-SNAPSHOT of Scala. Yes, this NetBeans plugin is written in Scala :)

A new version of NetBeans is out, 6.7.1 - a bugfix release. Among other things it contains 20 bugfixes in the Apache Maven support. Please upgrade.

Because kenai.com doesn't provide any unified deployment vehicle for maven projects yet, I've tried the way suggested by Fabrizio Guidici. The following comments might help other who also attempt to do so.

I've tried to perform a release of a set of maven projects at kenai.com/projects/nb-maven-generators

• if you are using mercurial as the version control of choice, then release:prepare will fail for you if the mercurial root doesn't contain the root pom.xml file. I had the projects in a subdirectory and the checkout/clone that is part of the release:prepare goal didn't find it then. I suppose that's a generic issue with mercurial+maven-scm-plugin. It attempts to tag the project, but mercurial is only capable of tagging and cloning the whole repository. I haven't tried, but I suppose releasing just one submodule might not be possible


• If your username at kenai contains a special character, like @ in my case (milos.kleint@sun.com), you need to encode the character when running
  mvn -Dusername=milos.kleint%40sun.com -Dpassword= release:prepare
  For a complete list of url encodings, see this explanatory page
  
• When doing release:perform afterward, the forked maven build needed me to confirm credentials of the svn release repository. Unfortunately the forked maven instance within release:perform doesn't have the input streams connected correctly and therefore I could not confirm the credentials are ok. A workaround I found was to perform mvn deploy:deploy-file, confirm credentials and then cancel.


• Finally, when deploying you need to pass the username and password for the svn wagon extension via the ~/.m2/settings.xml file. See details about the exact syntax.
  

After a few try&error cycles, I finally managed to perform the release correctly. Hope that helps.

As the canonical Maven book suggests, you should use $[foo.bar.version} property expressions when you have multiple, related artifacts with the same version. Then you are able to upgrade all the dependencies consistently with minimal effort.

The NetBeans IDE 6.7 supports this pattern in the Add Dependency dialog. You can invoke that dialog from the Add Dependency action on project's Libraries node in Projects view, or from the pom.xml editor via Insert Code (Alt-Insert) editor action.
The Version field completion includes all *.version properties defined in the project (or any of the parent) and offers them as expressions in form ${*.properties}

That way you can keep your dependencies in sync right from the NetBeans UI.

In future 6.8, we also replace the GroupId and Version values with ${project.groupId} and ${project.version} if both the groupid and version match those of the current project. Again, a practise suggested by the Maven book.

When I was playing with JavaRebel in April, it was not possible to use JavaRebel with the NetBeans platform. Basically because the module system is just another container and for each container you need a JavaRebel plugin. The guys at Zeroturnaround wrote the plugin a few weeks back (thanks!) so I've downloaded the nightly build and tried to experiment a bit. I've also worked some more on Compile on Save support for 6.8, so I wanted to test how far we've got with #161337. Here's the result.

I've uploaded the Netbeans 6.7 final artifacts to the Maven repository at bits.netbeans.org/maven2/. It contains the module jars, NBM files, javadoc and source jars and other artifacts relevant to 6.7 release.

Please note that when upgrading your NetBeans platform application from 6.5 to 6.7, you need to increase the version of all artifacts from RELEASE65 to RELEASE67 and also in your nbm-application project, change the dependency from org.netbeans.cluster:platform9 to org.netbeans.cluster:platform10. The artifactId of the platform cluster has changed as the cluster version was increased. (Not sure what meaningful purpose the cluster numbering serves, but that's a different story)

        <dependency>
            <groupId>org.netbeans.cluster</groupId>
            <artifactId>platform10</artifactId>
            <version>${netbeans.version}</version>
            <type>pom</type>
        </dependency>

Please note that the current 3.0 version of the nbm-maven-plugin might have problems with NetBeans 6.7 . A new version of the plugin will appear shortly.