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.

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

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.

When editing your pom.xml file, you get the regular xml file navigation panel. That one is provided for any xml file. it shows you the structure of the currently edited xml file in a tree.

The newly added navigator panel will show you the inheritance of your current pom file. That means the artifactId + version of the current file, it's parent POM's artifactId + version and so on, all the way back to the root company or project POM. it will also denote if the parent is accessible in the sources or is being retrieved from the repository. That happens when your project is using an already released version of the parent pom and is not depending on the current version in the sources or when the source is not accessible for some other reason. The editable parent POMs can be quickly opened by double clicking on the node.

I couldn't resist installing it even though it's only 6.0 and as a NetBeans IDE developer I'm using the latest daily builds mostly. For my daily work as least, sometimes I need to test on older versions though.

Maven also comes prepackaged but it was even older. 2.0.4 I think, I'll rather stick to the latest 2.0.9 release.

The 3.1 (coming soon) version of Maven integration for NetBeans is using these indexes to greatly enhance the user experience within the IDE. Let's preview some of the places that benefit from the indexing data.

First we need to add the Terracotta.org repository to the list of known repositories.

That's done in the Maven Repositories top level window. You can open it from Windows menu.

To verify we added the correct thing, let's expand the root node of the new repository and see what content we have there.

You can easily drill down from groupIds to artifactIds to versions. There you can immediately add the artifact to your projects or (if the metadata is present) view project website, file a bug or checkout the sources.

Browsing is cool but it gets boring after a while. The true integration puts the metadata from the index right at your fingertips when you need it.

For example when creating a new project from archetype

or in the editor for your poject's POM file when you need to check what dependencies or maven plugins are available and in what versions.

The new 3.1 version of Mevenide is not 100% ready for release, however if you want to test drive the beta quality code, it's fairly easy to setup. Download the latest NBM binaries from the NetBeans.org continuous integration machine and install them through the Tools/Plugins dialog. And while you are in testing mode, you should check it in the NetBeans 6.1 Beta build

Enjoy

Milos

org.openide.util.NbBundle.getMessage(FindResultsPanel.class, "FindResultsPanel.btnModify.text")

Here the FindResultsPanel is the class where the text is used, The Bundle.properties file resides in the same package as the class and the getMessage method makes sure it loads properly in an efficient manner. If you are coding a NetBeans module, you should avoid calling java.util.ResourceBundle directly.

However it's been always a pain to edit the text. First you ned to find the I18N token, then find and open the relevant Bundle.properties file and then find the line with the I18N token. The pain has become unbearable for me and I created a simple module that's capable of "hyperlinking" to the correct location in the correct resource bundle file directly from the java source file.

The hyperlink is invoked by pressing Ctrl while pointing to the I18N string. If you wait a bit, a tooltip shows with the actual message text from bundle file.

The module NBM file can be downloaded from here.
Works in Netbeans module projects only (both Ant and Maven based)
It will eventually make it either into the Maven support or the NetBeans module development modules

Enjoy.

Good job, Eric!

A bit of background:
The upcoming NetBeans 6.0 has file templates based on FreeMarker template engine. Most templates include license header. Each project can specify the license it's using and new files created in that project include the correct license then. For Apache Ant based projects, the magic property is "project.license=foo" in nbproject/project.properties file where "foo" is the name of the license template in Tools/Templates dialog.
For Maven projects I'm looking for "netbeans.hint.license" property in the pom.xml file. As a nifty easter egg, if you happen to be using Apache 2.0 license and have the "licences.license.url" xml element filled in correctly with "http://www.apache.org/licenses/LICENSE-2.0.txt" value you get the correct header automatically. (Note: If you are using some other OSS license and want that feature as well, send me the url and header content and I'll add it to the list of licenses that ship with Maven support)

Now we are getting close to my today's idea. The Apache license header includes the copyright notice, eg. Copyright [yyyy] [name of copyright owner]. Right now the name of copyright owner is replaced by the username in the resulting new file, however it would be nice if one could specify something more fancy. Like ${pom.organization.name} which would extract the data directly from the pom. With this syntax the Maven project type could make the whole POM available for new file templating. But I'm wondering if that's actually useful. What part of the POM can be used for templating? Please comment.

Just lately I've found out a new, cool feature was added. You can compare projects in terms of codebase. Obviously it doesn't make sense for any 2 random projects but sometimes it reveals interesting information. Like this Ant vs. Maven2 duel.
It shows (at least to me, please comment) that each tool is in different phase of development. In terms of codebase, activity and number of contributors as well. I'm not sure if the 200+ vs.140+ stack counts reflect a real world usage share though. We'll probably see more reliable results once the number of people joining the site grows.
Too bad one cannot compare Netbeans and Eclipse codebase the same way. The different philosophy behind the projects is reflected even here at ohloh. While NetBeans has one entry, Eclipse is split into many ohloh project definitions.

Don't vote for t-shirt, vote for the truth! Choose 4C.

MEVENIDE-465 activating profile on build execution has no effect
MEVENIDE-452 java.lang.AbstractMethodError: org.codehaus.mevenide.netbeans.j2ee.ejb.EjbJarImpl.getMetadataUnit()
MEVENIDE-463 Run & Debug outruns build
MEVENIDE-467 remove any webservices related templates, as they don't work
MEVENIDE-466 NPE in HyperlinkProviderImpl

Code completion in POM or profiles.xml files is limited in 5.5 due to this Netbeans bug - 87177

Everyone is counting differently, so I decided to go by first commit. And here it is. Turns out I missed the birthday by 2 days. But anyway, after one year, 500 commits, 50k of sources and 4 releases, check out for yourself where we are now.

PS: the features above will appear in the next version of mevenide2 for netbeans.

Here and here are the blog entries from planetnetbeans.org

• The biggest change since 2.0.1 is probably under the hood. The maven embedder was rewritten and building with mevenide is now exactly the same as on the command line. Gone are the problems with multiproject builds etc. Thanks goes to Jason for the rewrite.
  
• The eyecandy is probably the graph of project dependencies. Transitive dependencies and easy to discover, each scope (runtime/provider/compile/test) has it's own color, the initial automatic layout is not ideal but good enough, additionally allowing you to relayout and save the changes. For screenshots see my previous blog entry
  
• The project loading got optimized, now it's faster and more reliable. It never downloads it's dependencies up front. (Obviously it needs to for building, but you don't want to download dependencies of 40 projects on IDE start)
  
• It's possible now to execute arbitrary goals on projects and IDE action have some default mappings. Technically it's possible to map the right goals to you "Build project" or "Run project" actions, but for now there is no UI for customizing this behaviour. To be done for next release I guess.
  
• You can customize some of the maven2 user settings in the Tools/Options dialog now.
  
• And of course many bugs were fixed. But of course there can and probably are more. If you find some, please file them in the bug tracking system.
  

And there lies the usability problem apparently. I get questions quite frequently about how to setup the IDE and that there's no "Create Maven project with existing sources" item in the Create project wizard. I can definitely see the logic here. There's a "Create Project with existing Ant script" in the UI. If you have an existing Ant based project with custom build.xml, then the IDE needs some additional information about your dependencies, source roots etc. But for Maven there is basically everything included in the POM.

But I'm quite seriously considering to add an entry "Create maven project with existing POM" wizard, just to fullfill the expectations of the users and not to give the bad first impression. But isn't that cheating to just open the project then?

Things I had to do:

I have changed the node renderer to visually distinguish different scopes (compile/test/runtime/..).

I've overriden the link renderer to draw thick lines from the project's artifact. That way it should be more obvious what are the direct dependencies.

When a node is selected by user, it's dependencies are also selected. Again a nice visual indication of interdependencies, plus helps when moving nodes around.

I've implemented my own graph node layouter, because the default didn't scale for big numbers of dependencies and was a bit chaotic for projects with interdependent dependencies. The current one attempts to cluster the related dependencies together. As can be seen in the picture, the netbeans deps are separated from the maven dependencies visually.

Implementing layout persistece is supported by the graph library, so when you relayout the graph, it's not lost the next time you open it..

All and together, quite good results for the few hours I spent on the feature. The hardest part was coming up with the layouting algorithm.

With the IDE integration, you get the docs at your fingertips then.

Adding it to your pom is simple.

Every Maven project got a new subnode that lists all the dependencies of the given project. It visually shows the type of dependency, if it's present locally, if it's overriden.
You can view what other versions are available in the remote and local repositories, you can edit the dependencies, download the artifacts, check if javadoc and/or sources are available for dependencies etc.
Another added subnode is the Project files one, which gives shortcut access to all the project files of a maven project, no matter where these are physically present.

After endless hours and hints from coworkers, I figured that the problem was cause by a visible glasspane which was painting the wait cursor. Funny enough the visibility of the wait cursor correlates with the visibility of the progress bar in my case. Ensuring the glasspane stays invisible is hard to achieve. And it did work on Mac. The reason for that is that Apple's JDK enforces heavyweight popup. Oh, I didn't tell you that yet.
There are internally 3 kinds of popups, lightweight, mediumweight and heavyweight. On Linux I was consistently getting mediumweight popup, while on Mac the heavy version.
So how to force a heavyweight popup? The answer is non-obvious, I figured by looking at the code. In PopupFactory's createPopup() method don't specify the owner parameter. Passing null will magically create a heavyweight popup and everything starts working.

Hope that helps.

Why do I write about it? Since Mevenide 0.3 (Netbeans version) I've looked up javadocs for project's dependencies in the local repository and made them available to the project. The IDE then can enhance the code completion for the classes of that dependency. Version 0.6 now allows to check the remote repository for the javadocs and downloads them if available. (Screenshot here ) Unfortunately I've written the feature without consulting Google first.

Makes me wonder how many other Maven features end up being unused. Is it because there was no real benefit in uploading them or is the whole repository upload workflow not streamlined enough? Or even flawed?

1. complexity vs. simplicity
How to let the users customize the project? Maven pros have different workflow from the newcomers. The UI support should scale. Exposing all the plugins' properties at once (and there's a *lot* of them) to a user who just wants to build his/her first hello world application is a no-no. So a real simple basic setup is a must, with some basic project templates that work out of the box. At the other end of the scale, allowing to edit the the pom file and all the properties files with appropriate help like completion etc satisfies the demanding users. However what about the average? Coding and designing UI for the average seems to be the hardest task. I haven't really figured that one yet.

2. general vs. specific
The current default Netbeans 4.0 project types are all based on ant. However there's a whole bunch and every one of them is a bit different from the rest. So one has a project type for J2SE apps, web application project type, so called free-form which lets one map existing custom ant scripts into the IDE. With these specific project types one can have targeted UI and workflow for the tasks at hand.
Given the nature of Maven and the limited resources at mevenide, it was decided (by me :) to go ahead with "one project type to bind them all". How will that work? I'm not really sure. The user can basically use *any* maven plugin to build their artifact. And what about deployment, debugging etc. Webapps are debugged differently from a Swing app. And the IDE offers different tools for it as well.

3. Maven vs. Netbeans
This dilemma is best described with an example. Maven doesn't allow to build single file. I can understand why. But then again, Netbeans has this nice action in the popup menu - Compile File. For maven projects it's disabled because it's not implemented. From the user's perspective it looks unfinished or even broken. There's more cases like that: compilation executes tests, which is perfectly ok from maven point of view, but doesn't really match the user experience from other Netbeans project types. What to do here? I tend to be a maven purist "what maven does, is correct for the project type in the IDE as well", but I might just be blindfolded.