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.