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 http://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.

I've tried to play around with various setups of Maven projects in NetBeans, testing "Compile On Save" primarily. The traditional CoS in NetBeans will redeploy your webapp or quickly rerun the application (without recompiling the sources). I've tested a bit more IDE independent setup here, described in few simple steps, hopefully useful to someone.

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.

Whenever you have a Maven project inheriting from a parent POM, you should make sure the parent is accessible from the sources via the project/parent/relativePath element. The default value is "../pom.xml", the direct parent folder. The sources version will only be used if the coordinates match, of course. Eg. your project/parent /version element value needs to match the parent's version element.

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.

I've added a few additions to the "Add Dependency" dialog in NetBeans 6.7 daily builds (and the upcoming Milestone 3 of 6.7)

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

I'm proud to announce new release of nbm-maven-plugin. The plugin
helps with creation and building of NetBeans module projects and
NetBeans platform based applications.

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

If anyone wonders why the NetBeans 6.5 binaries still aren't at the Maven repository at deadlock.netbeans.org, here is why.

The maven repository is primarily targeted to be used together with nbm-maven-plugin that creates NetBeans module artifacts. Actually the repository itself is being automatically generated by one the goals of the plugin (populate-repository goal).

There is a new major version of the plugin waiting for release. Among other things, like improved support for platform based development, this new version also reworked how the automatic generation of the repository with NetBeans artifacts works.

• It uploads both module jar files and the NBM files. These are crucial to some of the new features of the plugin


• It consults a Nexus repository index to generate proper dependency metadata. For libraries not found in the index, a custom groupId+artifactId coordinates are created and the binaries (with metadata) are hosted at the same repository as the NetBeans modules.


• A POM is generated for each of the IDE's clusters along with a list of modules in that cluster

All these features (and especially the second entry) are in fact causing the repository content not to be backward compatible with the previous version. It could be probably used with the 2.6.x version of the plugin but it would behave differently than the content generated by that 2.6.x version.

One option is to have the deadlock repository dedicated to 2.6.x plugin and for 3.0.x and later, just use a different repository where new metadata gets created. I'm indeed currently in talks to find a new place for the NetBeans binary artifacts, so a new repository is to be expected for use by 3.0.x.
However it will not solve the problem entirely, might make it worse actually. As there will be Maven POMs floating around the internet that shall describe the very same artifact, but the metadata contained within (eg. stated dependencies) will be different. If these meet in your local repository at the same time, you're in trouble and get non-reproducible and irrationally failing builds :(

Therefore the only sane solution I was capable of finding is to never generate the repository content for Netbeans 6.5 using 2.6.x version of the plugin and only make the 3.0.x version available.
If you need the old bits generated, you are free to do so locally at your company/project using the very same maven goal I use for the public repository.

I will generate the content for the new repository as soon as I get hold of the new server and after I release the 3.0 version of the nbm-maven-plugin.

PS: As you might notice, I will not be generating NetBeans 6.0/6.1 content using the new 3.0.x plugin goal. Again to prevent a clash in the metadata..

Ever wanted to have the Continuous integration server results at your fingertips? And always just relevant to your current work? Automatically?

Jesse Glick has posted a new version of the Hudson plugin on NetBeans.org Plugin Portal. It includes integration of issue 1643 which takes the Hudson server and job definition right from the Maven's POM file.
If you define the <ciManagement> section in your pom.xml and it's Hudson you point at, the
Hudson integration will pick up the correct URL(s) from the opened projects and automatically contact those servers. The jobs from the URLs will be considered a priority and shown in status bar if broken. Once you close the relevant projects, the Hudson support disconnects again and will stop notifying you.

To download the hudson module(s) binaries, follow these links.
Hudson module and Hudson Maven bridge

For NetBeans Module developers: It shall be fairly easy to write bridges for other NetBeans project types as well, feel free to contact me if you want to give it a try.