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

• 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. http://www.apache.org/licenses/LICENSE-2.0.txt
  2. http://www.opensource.org/licenses/mit-license.php
  3. http://www.gnu.org/licenses/gpl-2.0.html
  4. http://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".

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

I've tried to perform a release of a set of maven projects at http://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.

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.

1. create a new maven nb platform based app from the archetype:
GroupId: org.codehaus.mojo.archetypes
ArtifactId: netbeans-platform-app-archetype
Version: 1.1

In the simple module subproject, define a new simple action (via New Action wizard) that will reside in toolbar and main menu.

2. add a profile for javarebel in the root pom.xml

<profile>

            <id>rebel</id>

            <pluginRepositories>

                <pluginRepository>

                    <id>zt-repo</id>

                    <name>Zero turnaround repo</name>

                    <url>http://repos.zeroturnaround.com/maven2</url>

                </pluginRepository>

            </pluginRepositories>

            <build>

                <plugins>

                    <plugin>

                        <groupId>org.zeroturnaround</groupId>

                        <artifactId>javarebel-maven-plugin</artifactId>

                        <version>1.0.5</version>

                        <executions>

                            <execution>

                                <id>generate-rebel-xml</id>

                                <phase>process-resources</phase>

                                <goals>

                                    <goal>generate</goal>

                                </goals>

                            </execution>

                        </executions>

                        <configuration>

                            <packaging>jar</packaging>

                        </configuration>

                    </plugin>

                </plugins>

            </build>

        </profile>

The important part here is the packaging parameter which we set to "jar" to have the netbeans modules (which have packaging "nbm" - unknown to the plugin) processed as plain jars.

3. in project properties dialog enable Configurations on the root project and activate the rebel profile. Then perform a build, all modules that are part of the project shall have the rebel.xml file generated now.

4. In Tools/Variables dialog, define a variable REBEL that points to the directory where you extracted JavaRebel to.

5. In the properties dialog of the nbm-application project, configure the startup parameters of the Run project action binding to include javarebel agent:
netbeans.run.params=-J-noverify -J-javaagent:${REBEL}/javarebel.jar -J-Drebel.log=true

Please Note: In 6.7, steps 4+5 won't work as described and you have to put the absolute path the javarebel jar in the action binding. Since it's written to the nbactions.xml file in the project basedir, it's rather inconvenient since you want to share that file in version control.

6. Now you can run the application. You can verify in the output of the maven build that the javarebel agent was started. You should have a basic Nb platform application started with the new action in the main menu. It doesn't do anything yet, let's change it. Note: keep the platform application running, don't exit.

7. Let's put something simple and visible into the action's performAction() method:


DialogDescriptor dd = new DialogDescriptor(new JLabel("foo"), "bar");
DialogDisplayer.getDefault().notify(dd);


Save the file. Unfortunately the class didn't get compiled on save, we will need to go to the module's project properties Compile panel and turn "Compile on Save" on for application sources. Now let's change and save the action class again and you should get the class compiled. Switch to the running application and trigger the action. You should get a dialog showing up now. Hurray!

Please note that in 6.7, you will have to add an maven-antrun-plugin snippet as described in the previous blog entry.

Note to self: It would be nice if the CoS support in the IDE would recognize the rebel.xml file in the target/classes folder and just automatically assume CoS shall be on, without additional configuration in the projects.

8. Unfortunately not everything is so bright, some things don't get propagated, like resources. If you try replace the explicit strings with

org.openide.util.NbBundle.getMessage(MyAction.class, "LBL_foo");
or
java.util.ResourceBundle.getBundle("com/mkleint/platformwithjavarebel/Bundle").getString("LBL_foo")

you end up with MissingResourceException. First I though it's caused by some caching in the ResourceBundle or NbBundle classes, but even if you create a new class in new package that was not touched before by the app, it will always just look for the bundle file in the jar, and never in the sources or output folder, which is strange because the javarebel log claims to watch the target/classes and src/main/resources folders when you start up the application.

9. I haven't even tried but anything that has to do with layer files, META-INF/services registration and annotations will not work either. I guess it could be added to the JavaRebel's netbeans plugin. Like dropping the various caches and reload everything when some of the significant files changes or appears, however it wil not work without having the resource problems mentioned in bullet 8.

Still, even with these limitations, the development cycle has been shortened significantly. Someone volunteer to add javarebel file generation to the Netbeans.org ant scripts?

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.

0. Install the latest dev binaries of upcoming NetBeans 6.7 (future beta or existing M3 shall also do, no guarantees for 6.5). Also download the Javarebel application from zeroturnaround.com

1. First take the appframework archetype and create a sample project we will be playing around. In Netbeans 6.7 builds, the archetype shall be available in the New Maven project creation wizard in a privileged location.

2. Open the pom.xml file for the project and add a profile for JavaRebel there.

   <profile>

    <id>rebel</id>

    <pluginRepositories>

        <pluginRepository>

            <id>zt-repo</id>

            <name>Zero turnaround repo</name>

            <url>http://repos.zeroturnaround.com/maven2</url>

        </pluginRepository>

    </pluginRepositories>

    <build>

        <plugins>

            <plugin>

                <groupId>org.zeroturnaround</groupId>

                <artifactId>javarebel-maven-plugin</artifactId>

                <version>1.0.2</version>

                <executions>

                    <execution>

                        <id>generate-rebel-xml</id>

                        <phase>process-resources</phase>

                        <goals>

                            <goal>generate</goal>

                        </goals>

                    </execution>

                </executions>

                <configuration>

                </configuration>

            </plugin>

            <plugin>

                <groupId>org.apache.maven.plugins</groupId>

                <artifactId>maven-antrun-plugin</artifactId>

                <version>1.3</version>

                <executions>

                    <execution>

                        <id>run</id>

                        <phase>process-resources</phase>

                        <goals>

                            <goal>run</goal>

                        </goals>

                    </execution>

                </executions>

                <configuration>

                    <tasks>

                        <echo file="${project.build.outputDirectory}/.netbeans_automatic_build">Generated by maven build for javarebel in netbeans.</echo>

                    </tasks>

                </configuration>

            </plugin>

        </plugins>

    </build>

</profile>

The configuration performs 2 tasks. It generates the rebel.xml file required by the Javarebel agent to find the output folders of the project in the resulting running application. Second, it generates a file in the output area of the project that tells NetBeans java support to copy the class files on saving.

3. Now you can Enable Configurations in the Project properties, activate the rebel profile there and for that profile/configuration, add additional VM options for running the application (the Run panel in project properties dialog)
For me it was:

-noverify -javaagent:/home/mkleint/javatools/javarebel/javarebel.jar

4. Build & Run the Application. If you've done things right, you should see in the output that the JavaRebel agent is running.If you open the application's AboutBox form and move stuff around, you should be able to see the changed propagated on Save in the IDE. Oups, You actually won't :) The showAboutBox() method the View class is caching the created about box, therefore the old layout persists. Once you remove the caching (even already in running application), you will see any changes in the AboutBox in the running application immediately.

5. Enjoy.

If one of the conditions is not met, you end up resolving the parent POM from repositories defined in the current project. That might be the right thing in some cases, but sometimes it will prevent you from building the project separately (without having built all the parent beforehand) and also loading of the project in the IDE. In NetBeans, this is one of the reasons for the famed "Badly formed Maven project" error message. Even if it resolves properly from repositories, you might end up in with inconsistent data if some of your projects use the parent from local repository and some from sources.

A way to double check in NetBeans how your projects resolve is to show the "POM Inheritance" navigator view while having the pom.xml file focused in editor.

In this screenshot, I have opened the v3/common/glassfish-api/pom.xml file from the latest GlassFish svn checkout. The navigator view is in the left bottom area. It displays the project's POM inheritance, the current pom at the top, the direct parent below it and so on. Any parent marked with "(read only") is only resolvable from local and remote repositories. In this example, that might be fine for the ultimate root (pom - 3), but it's most likely wrong for any SNAPSHOT parents, like glassfish-parent.

PS: The NetBeans 6.7 Milestone 3 is out. Check it out.

First, the dependency's Version field includes all properties defined in the project that end with .version, eg. ${spring.version} as suggested in the Maven Book, Chapter 8.3.

Second, I've created a new tab called "Open Projects" that lets the user pick from the list of currently opened projects and declare them as dependency of the current project.

Enjoy

= New in this release =

• Support for full lifecycle of the NetBeans platform based applications.
  
• Improved runtime dependency generation, now transitive with class
  usage checks.
  
• Better repository content generation for NetBeans.org artifacts, now
  located at http://bits.netbeans.org/maven2 and contains NetBeans 6.5 binaries only.
  

Please note that the 3.0 version is not compatible with previous 2.6.x
releases or 2.7 alphas. Please read the upgrade notes
Complete list of issues fixed.

There are new archetypes released that work with this version of
nbm-maven-plugin:
org.codehaus.mojo.archetypes:nbm-archetype:1.1
org.codehaus.mojo.archetypes:netbeans-platform-application-archetype:1.1

It tool a while to get the release out (too long), but now it's finally here. Please comment, file issues, send patches.. Thanks.