mkleint

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

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