• First of all, NetBeans IDE has bumped up its version number to 6.8, including (not too much of a surprise, I guess…) seamless and production-ready support for Java EE 6 and Glassfish v3, along with improved or newly added toolings and plugins for maven2 (very impressive), Project Kenai, JavaFX, PHP and a whole bunch of other technologies. Adding to that, asides “just” being another multi-language/-technology IDE, NetBeans RCP also is likely to get more support as an RC platform, which surely is a good thing.
• Then, Java Enterprise Edition is available in version 6 (JSR-316), aiming at making Java EE development more slim, more easy and, thanks to the newly added “profiles”, more adaptable to given use cases than ever before. Along with this, there are a bunch of improvements in technologies such as Java Servlets (3.0), EJB (3.1), persistence (JPA 2.0), JCA and, especially notable from my point of view, support for RESTful web services (JAX-RS 1.1).
• Finally, in addition to that, along with Java EE 6 comes Glassfish v3 as its reference implementation and the “open source” platform Suns Java System Application Server is based upon. Along with (obvious) support for all the Java EE technologies, just the last couple of weeks I experienced during FishCAT that GFv3 is a pretty good platform, providing all the strengths so far provided by its predecessors, yet being updated to reflect the changes in Java EE 6 and also providing hosting for in example JRuby applications out of the box. Adding to that, Adam has a more in-depth list of goodnesses that come with GFv3.

So, overally, a lot of great technologies and tools to play (or eventually work :) ) with, but also a moment of thought: Maybe not for NetBeans, but I am pretty sure at the very least for Java EE and maybe Glassfish, this could be the last release made by Sun as an independent business entity, the last releases related to these technology before Sun gets acquired by / gets merged with Oracle, leaving their products end up in the ever-growing Oracle product and services portfolio, some driven forth maybe more enthusiastically, others maybe left out in the cold and eventually discontinued. No matter how, I guess the next year might be crucial to all of these technologies: It will show how Java EE 6 can come up against or side-by-side with latest and upcoming Spring releases, with the whole OSGi movement in general and, especially, the environment to be set up by Eclipse RT project. And it also will show what NetBeans, as an IDE, as a platform, as a community, can come up with to provide viable alternatives and approaches to a load of (unquestionably good) features provided by Eclipse ecosystem, like the whole Eclipse Modeling toolbox or the upcoming XWT and declarative UI technologies in e4. Or maybe (which eventually could be the best of all outcomes) it might show that there is a good reason for different alternatives existing to address different requirements and use cases.

And, overally, no matter how things will move on: At the moment, congratulations to all the engineers, writers, tech people behind these three releases! You did a rather great job again…

First impressions

Starting with the good things… By now, using Sonatype m2eclipse, Eclipse maven2 support has somewhat improved the last couple of years:

• Asides “Run as” -> “maven …”, Eclipse now seems to be able to build maven2 projects along with a straightforward workspace build / cleanup, which is really rather helpful (and actually something one would expect… :) ).
• There now is a quite powerful editor for maven2 pom.xml files which, as I have to admit, in some situations even outperforms the tooling provided by NetBeans especially when it comes to displaying dependency graphs and dependency hierarchies. The various visual editor pages also help getting closer to the full maven2 feature set if you do not want to dive all too deep into the pom.xml syntax and/or are just learning…

Likewise, there is a whole bunch of features how to “import” maven2 projects into Eclipse, also (as I think) partly due to the fact that Eclipse, unlike NetBeans, can’t simply “open” a maven2 project simply using pom.xml as the only piece of relevant information but rather requiring its custom configuration files in the project structure to be happy. So, I tried to import and get started with my maven2 projects… So far, this is an SVN trunk consisting of about 55 mvn2 jar/war/pom artifacts, which I was about to check out and import into Eclipse.

Second impressions

And this prove to be fun, for sure. First shot, most straightforward, using “Import” -> “Maven” -> “Check out Maven2 projects from SCM”. Browsed to the repository trunk, let it check out all the project, and they’re here… and they’re all red? Well. It seemed that, with checking them out of SVN, Eclipse did for each project assume to enable project specific Java Compiler settings, thus forcing them to be Java 1.4 compliant each (and ignoring what’s stated in pom.xml explicitely). Fine. Resolving this was work no less than manually changing this setting for each of the projects in question. Following this, at least some of the projects didn’t have problems anymore. The whole mess built until I eventually trashed one of the project. Well, no problem – delete it, check it out again – and see the main project failing to build?

It took a few moments to resolve what happened: My main project is a maven2 pom project containing modules like this:


<modules>
<module>../moduleA</module>
<module>../moduleB</module>
<module>../moduleC</module>
</modules>


and is referring to modules living in the same folder on the same level as this core / build pom. However, Eclipse maven2 tooling did check out all the projects initially to a folder like workspace/maven.1259135232603, thus having them all in one place. Deleting the project (not much of a surprise) removed it from this folder. Checking it out again, however, created a new folder in workspace (workspace/maven.1259151842736) and checked the project out to there. Well… I have no real understanding why this happens, and so I wouldn’t want to say it simply dumb, but at the very least in this situation it’s a behaviour highly undesirable, and I really would want to at least be capable of having this configurable. Yet, so far I fail doing so. Did, however, commit the changed projects to at least hope to have the Eclipse metadata relating to the Java Compiler settings stored along with the project.

Anyway, so let’s test another stragety: Eclipse also allows for importing existing maven2 projects, which basically just does create project related metadata in the workspace but keeps the project code wherever it is. So, manually checked out the SVN trunk to some arbitrary folder, used Eclipse to import things, saw my projects, did the same settings as above (setting Java Compiler to not be project specific… – so obviously they are kept elsewhere but in the actual project itself), built. Worked. Tried to commit the projects to SVN – to see that, this way, even though there are .svn metainformation in any of these project folders, Eclipse fails to recognize these projects as “versioned” so the only thing to be found in “Team” menu is the usual standard (“share projects” / “apply patch”). No way of reconnecting, no way of committing. Of h***. :/ So back to the initial approach, let’s just hope we don’t have to delete and checkout any project anew…

A few hours later, I am frustrated beyond belief as many features one simply takes as granted in NetBeans don’t seem to work in Eclipse:

• Even though some of the maven2 artifacts are war applications, Eclipse WTP obviously fails recognizing this out of the box, i.e. without fiddling with the project metadata, so all the code in src/main/webapp is just available via generic folder browsing and there is no real meaningful webapp tooling available to these projects.
• Classpath detection seems somewhat broken: In many situations, maven2 projects (and Java classes inside) are marked as broken because classes can’t be found, yet running a maven2 build on these projects works flawlessly and the project also has the required dependencies at hand.
• In some situations, even though I am not sure who’s to blame for that, projects checked out of SVN were listed as “unversioned” in the project explorer, yet the SVN metadata were there and trying to share them ended in a reconnect (no surprise).
• In another peculiar situation, the pom.xml editor kept me from deleting a dependency – no matter how often I tried to cut the corresponding <dependency> section – it always got back inserted into things. Resolved this by deleting and checking out the project again, see above.
• Having some projects that generate code off WSDL (JAX-WS) or XSD (JAXB) using corresponding maven2 plugins, it seems even though after adding the folder where the generated sources ended to the list of project source folders in Eclipse, the IDE seemed unable to actually find the generated classes on the classpath.
• There seems to be a general problem in redundancy of Eclipse metadata vs. pom.xml, ending up in information (Java Compiler level, “Java Project Facet” level, …) being entered more than once where, actually, pom.xml itself should suffice…

So here I am… my maven2 projects all in Eclipse, a bunch of them marked red, the whole mess building regardless of this but (obviously) code editing being somewhat difficult with not all classes correctly found on the classpath, and I know things feel somewhat non-deterministic. Maybe I have not completely understood how m2eclipse does a bunch of things. Maybe I’ll take a dive deeper to learn more about how it works, later… but now, and first off, I need to get work done, and by now I know the dissatisfactions arising from using two different IDEs are easier to address than the various troubles and issues arising from importing a complex maven2 project structure into Eclipse. Agreed, maybe most of my project structure could be set up more straightforward and “better”… but it works flawless in maven2 (which is at the core of it), and it works flawless in NetBeans maven2 tooling (which is on top of it), so it can’t be all that bad. And, in maven2, I just don’t want any more essential information (like Java Compiler version, …) placed anywhere but in the pom.xml, no matter which IDE in use… I’m off now to get all these .project files out of my SVN trunk…

Assumptions regarding community documentation…

Initially, as one might expect reading the name, “NetBeans Community Docs” was a project initiated to collect any documentation (articles, FAQs, tutorials, …) provided by NetBeans users for the sake of helping other users. This, and I still and firmly believe so, is a good idea from various points of view:

• First and foremost, it is an easy way for everyone to contribute back to an open source project without being a developer or “code hacker”.
• Then, of course, documentation provided by those who build a tool is rather different to documentation provided by those who use a tool; from that point of view the “community documentation” approach seems sane regarding the idea of gaining “user” documentation of actual use to someone as it addresses the way a potential user would see a given problem (both in terms of content and of style of documentation – thinking of “learning trail” vs. “short, to-the-point” articles).
• Last but definitely not least: Community contributed documentation, to developers and “tool makers”, seems a good thing as it exposes how end users do think and work, thus it eventually might help making a given tool better by having a better understanding for end users needs and wishes.

… and voluntary contributors in special.

Of course, community documentation doesn’t come “from out of nowhere” but has to be written by some actual contributor. And a contributor is likely to, well, contribute documentation in a given way which I quickly want to outline using an example rather familiar to me: Myself. I started using NetBeans earlier because I was searching for a quick, “intuitive”, usable IDE to do server sided / web Java development using maven2. Eclipse maven2 tooling sucked at this time (at the very least), and NetBeans came in rather handy here. In course of adopting the tool, I read some documentation, tried out a lot of things, and eventually wrote a bunch of articles on issues I stumbled across during this process… and time passed, with a few things happening:

• Generally, the IDE saw some more releases along the way, each one a little better regarding technologies I am working with, each one requiring a little less “additional” documentation than its predecessor.
• Same way, I somehow “consolidated” in my everyday work using the IDE, I finally got it working as an unobtrusive, highly productive tool not coming into my way anymore (mostly at least). The situations in which to really “hit a wall”, assuming a given solution to be worth writing an article or even a short tutorial about, are becoming less and less frequent and eventually disappear.
• And, last but not least, a bunch of things addressed in (community) documentation articles earlier by now either are addressed by the IDE itself (which has changed in some aspects to indeed be what it should be – an intuitive tool) or by “official” NetBeans documentation or it simply is “not an issue” anymore in everyday work, which makes it rather likely that community contributors won’t bother updating any “old” contributions as soon as it is not an issue to them anymore.

So, assumptions from that are that, having a “limited” set of contributors, it is rather likely to see the amount of new contributions reduce to somewhere next to Zero sooner or later, which actually might be good (as it is an expression that, overally, the tool has become convenient enough to most end-users and it allows end-users to simply and productively get their work done without bothering too much about the tool), but then again is a problem for the “community documentation” approach itself (which, as stated above, is generally a good thing).

Conclusions and ideas

How to deal with such a situation? How to resolve the problems outlined above without completely ending the project altogether? As stated, I just have a couple of vague ideas…:

• Attracting more users is an essential and important approach. Given the above assumption that “contributors” are likely to become less active as soon as they are perfectly happy working with the tool, a continuous stream of “new volunteers” addressing new areas of technology, providing new needs and wishes regarding working with the IDE or “just” running into problems no one has seen so far (because no one so far tried) seems the way to go. Is anyone using NetBeans along with, say, Python or PHP or Scala or Groovy in a production environment, or making use of its JavaFX tooling? So far, there are obviously few people on the community docs team dealing with these aspects enough to write “real-world” documentation (i.e. doing “productive everyday work” using the IDE).
• Making things more “responsive”, interactive. As soon as contributors are ready to write documentation on their own – fine. But after all, some day it might be difficult to contributors to figure out whether an issue they just stumbled across is actually worth documenting or “just” something every other user would immediately figure out taking a closer look. Maybe, from this point of view, the project itself should grow to not just be “contributor-driven” but more than that “user-driven”, allowing end-users to better state which documentation formats they like (which is surely likely to differ – i.e. /myself prefers short, to-the-point written articles on given topics and strongly dislikes screencasts and/or long, time-consuming “learning trails”) and on what issues / topics / aspects they would like to see documentation on. Maybe this also would be the way to deal with updates – a contribution being reviewed by its original contributor or someone else who is qualified enough to do so only on user demand.
• “Linking” the world together better. Using a wiki, a dedicated blog or whatever centralized structure for keeping community contributed documentation is a good idea to some extent, but then again: Isn’t a single blog entry written by someone somewhere around the world also “community contributed documentation”? Maybe taking more care of these contributions (and/or encouraging people to contribute this way) would be a way of addressing those who aren’t part of the “documentation-writing community” at the moment…

However I still think there’s quite a lot of questions unanswered, and, at this point, I see that these questions would be addressed and eventually answered best by those using NetBeans community docs… so, what are your thoughts on that? Have you ever read a NBCD article? Have you even contributed one? How did you like the project, the documentation structure, …, if you did? Share your thoughts…

After more or less loosely following Geertjans blog I rather early found out about the jvisualvm tool that comes with recent versions of Sun JDK 6, but so far I haven’t really seen any use cases for it in my environment. However, at the very least now I have figured out that this is rather good a solution for tracking down weird NetBeans behaviour by providing more reliable information, i.e. thread dumps. And there’s even more…

Dealing with NetBeans…
Indeed, my first obvious idea was trying to figure out what’s goin’ on inside a running NetBeans environment. Doing thread dumps is also possible in other ways, but at least the jvisualvm approach is pretty straightforward. On Unix systems, jvisualvm is found in the same place your java binary lives, so if you’re capable of running java -version from within a terminal, you’ll also be capable of running jvisualvm from there.


[kr@n428 7:56:18] ~> java -version
java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) Server VM (build 11.3-b02, mixed mode)
[kr@n428 7:56:23] ~> which jvisualvm
/home/kr/kontext/runtime/linux/java/bin/jvisualvm
[kr@n428 7:56:26] ~> which java
/home/kr/kontext/runtime/linux/java/bin/java


Once you started the application simply using the jvisualvm command, you’ll end up with a main application screen like this:

If you are a NetBeans user, the user interface pretty quickly will look familiar to you as jvisualvm basically “just” is an application based upon NetBeans RCP. Asides this, you will see an “Applications” window. In my case, the NetBeans I want to debug being already running, I can see the NetBeans process (pid 4974, in this example) below the “Local” node, so by now I am ready to get going:

Double-clicking the “NetBeans 6.7″ icon in “Local” will make jvisualvm connect to this process which might take some time but in the end provide me with a brief diagnostics overview showing basic information about the NetBeans process and its environment:

Right now, you have quite an amount of helpful tools at hand trying to figure out where your problem is, like doing CPU or memory profiling (analogous to the feature set already offered in NetBeans for developing Java applications), analyzing memory consumption and garbage collection, and, as desired in my situation, looking at threads and doing a thread dump. For that, the “Threads” window is what you want:

By now, there’s a button labeled “Thread dump” (the same can be achieved by right-clicking the application in the “Applications” window and choosing “Thread dump” from the context menu). Doing so will result in, obviously, jvisualvm generating a thread dump for the running application. As soon as this is finished, it both will appear opened in a new editor on the right side of the window and, as a child node below the application (NetBeans, in my case) in the “Applications” window:

By now, you can merrily browse through the dump and see what might be flaky in your current situation. Another good option, if required: In case you are about to file an issue against NetBeans regarding this behaviour and/or want to attach yourself to an existing issue, you might want to add this thread dump simply to provide developers with additional information to track down the problem. To do so, right-click the “[threaddump]…” node in the “Applications” window, choose “Save as…” and enter an appropriate name. This will result in generating a plain text file ending in “.tdump” containing the full thread dump as displayed in the jvisualvm window. This file, by then, might be attached to an issue filed against any application you’re likely to debug, or it might be sent to your application developer helping them getting your tool improved. The same procedure can be used i.e. for generating heap dumps or application snapshots, which all in itself is rather valuable while knee-deep into debugging work.

…and beyond.

So far, we’ve been looking at a Java application running on the same host jvisualvm runs on. While this is fine for desktop and overall development debugging, in a real-world environment your applications might run on some sort of application server, Glassfish in our case. Fortunately, jvisualvm also allows for working with remote applications i.e. making use of JMX. Masoud Kalali has written a quick guide on how to set up jvisualvm to work with Glassfish and, after goin’ through this procedure, indeed I am capable of doing more or less the same I previously did dealing with a local application now interacting with my remote production Glassfish:

So, overall conclusions and hints:

• If you ever filed an issue against NetBeans, eventually were asked to attach a thread or heap dump and have absolutely no clue how to do so, jvisualvm is a very helpful friend helping you getting this done.
• I like the chance of doing application debugging, but the capabilities in dealing with remote servers surely will make jvisualvm a tool I do not want to miss in my everyday tool box.

I will keep myself from speculating aloud which of these projects might be continued and which ones might be stopped sooner or later, but rather want to come up with another thought on this: Product strategy. I know quite some people who chose the BEA WebLogic Java EE server for various reasons (including not depending upon a global “software super power”) and were quite happy with this. Some time earlier however, BEA also was acquired by Oracle, and even though Oracle product managers decided to discontinue their own application server in favor of WebLogic, these customers by then still ended up being customer of a company they never wanted to work with. Same way, some of the BEA products simply were discontinued, like some of the Oracle ones, in favor of having migration paths offered to alternate products virtually replacing them. This also might not always be desirable as, even though having a migration path available is a good thing, eventually one doesn’t want to migrate as product decisions also might have happened out of technical preferences for the product initially chosen – from that point of view being forced to migrate to something you didn’t initially choose for sane reasons doesn’t seem all too compelling.

So, after all: How to get out of this mess? How to be capable of doing sane strategic product decisions without having to worry that, sooner or later, your product might be discontinued in favor of another one after some company, service provider, … has been acquired by someone else? For that, I see just one solution really practicable: Go for Open Source software, and not just for sofware being open source but also for software being open source and maintained, developed, driven forth by some kind of foundation or consortium rather than just being a former product released under an open source license but still developed and maintained mainly by one single vendor. Examples for these things include:

• The ObjectWeb Consortium is an open source development and support community, a consortium with an impressive list of members, offering a wide range of infrastructure and development platforms like the JOnAS Java EE server (which by now also is Java EE 5 certified – maybe a likely replacement when and if Oracle might decide to discontinue Glassfish?), the XWiki Java based wiki application, the Orchestra BPEL platform and a bunch of other things.
• The Apache Software Foundation, maybe the most prominent of these communities because of the Apache httpd server, then and now one of the most widely used web servers, also offers a whole load more than this. Projects hosted at apache.org include the Geronimo Java EE 5 application server, the tomcat Java EE servlet container, the James Java based e-mail server project, an extensive set of technologies related to Web Services development, a fully-featured Java Server Faces implementation named ‘myfaces’, the ServiceMix ESB platform and really way more than that…. The ASF also consists of members representing virtually all companies important in software world. And, as an interesting liner note, even Microsoft at least partly is supporting ASF, for whatever this is worth. :)
• Important as well is Eclipse Foundation, hosting the Eclipse IDE and a bunch of other projects focusing both on IDE and on general Java application development, including the Equinox OSGi implementation, the jetty Java EE servlet container, the EclipseLink reference implementation of EJB3 JPA (formerly contributed by Oracle, actually…) or the SOA Tooling Platform. Eclipse Foundation obviously has a strong support by various commercial and non-commercial entities, contributing code and development effort as well as supporting Eclipse based applications or using them in their own (proprietary?) application platforms.
• Smaller than that yet too interesting to go unnoticed, there’s also Codehaus out there, a small yet creative community hosting projects like ActiveSOAP web services framework, the XSite web site generation tool, the xstream Java-to-XML serialization library or dynamic languages like Groovy (for Java/JDK) and Boo (for CLI/.NET).

So, overally, what to learn from all this mess:

(1) Despite all dedication, keeping a little independence pays off from time to time: Using maven2 as build tool, so far we really did enjoy the clean, usable, straightforward tooling NetBeans offers for this tool, while at the same time making sure our source structures and projects aren’t tied to the IDE like, in example, they would be while using stock Eclipse projects. From that point of view, in worst case we even could go on doing development work with a tool as simple and straightforward as jedit comes the need. Likewise, keeping applications as compliant to Java EE standards (and as independent of a given Java EE implementation) as possible will, assuming worst case (which is not what you do as a technology enthusiast but definitely is what you gotta think about when you have to make strategic decisions) ease migration to another target platform. Both things aren’t on our list at the moment however, and hopefully they’ll never will. The Glassfish/NetBeans tool chain is way too convenient and powerful to be abandoned without a fight. ;)

(2) Generally, even though (in worst case) the Oracle/Sun merger might change things for people so far into using Sun-contributed open source projects, there still will be alternatives at hand, if they don’t want to go with the offerings Oracle by then will be providing to them. This is, of course, a good thing as it makes dealing with the uncertainty obviously caused by such a strategic (corporate) move a little easier. And, after all, being acquired by some “strong” company still might be the best to happen to Sun given the current business situation of the company in order to let at least part of its technology survive (I will contribute more time to using OpenSolaris from now on).

(3) Despite their brave moves in releasing a great set of technology under open source licenses, it overally seems Sun didn’t completely “do this right” in the end. I remember that, a while ago, another good Sun-based open source project, the JSF component collection labeled Project Woodstock, after a period of silence and uncertainty for its adopters ceased to exist, now “just” offering a migration path to IceFaces JSF library. For quite a while it seemed there was just an awful load of open source projects appearing on the scene, providing great technology yet leaving users unsure about the actual nature of its community: How many people are there actively developing it, how many of them are full-time Sun employees and how many are open source volunteers and/or employees of partnering companies, how many of them are enthusiasts and small-time developers? Who does make strategic decisions about project roadmap, new features, …? Who, overally, has to decide what to be done and what not to be done? This, in my opinion, is the worst to add to the momentary uncertainty about Glassfish, NetBeans, … despite the fact of these all being open source projects: Of course, being by its very nature open source projects, they don’t generally to depend upon a very company to survive, virtually anyone could to a fork and drive forth development on her/his own. But yet, at least to me it’s absolutely unclear what will remain of, say, Glassfish in case Oracle might decide to suddenly withdraw all Java EE developers in order to make better use of them in any of their existing Java EE related projects – will there be anyone left to keep up developing an “open source Glassfish” without Sun? From that point of view, there would have been a better way initially if Sun just had made, say, java.net an open source foundation similar to Apache, Eclipse, …, contributed all of its open source code to this foundation and aggressively invited third party corporate and freelance developers to contribute and participate. This, asides all other business implications (like matters of education and support offered for these technologies) at least would have made things easier by having these projects “safe”, their technical development and progress reliably outlined no matter what eventually would happen… Then again, maybe it’s not yet too late for… Apache NetBeans? Codehaus Glassfish? O’w2′penDS? What are your thoughts?

Anyway, after writing all this text, what are my personal conclusions of this? For now, I will keep sticking to “business-as-usual” of course, keep on promoting the use of NetBeans, Glassfish and related technologies. From my point of view, they’re way too valuable to be ignored and abandoned without too much ado. Especially relating to NetBeans, there’s quite a clear road ahead, with 6.7 development nearing its end, providing an impressive list of changes and other things noteworthy compared to its predecessors. Along with this, we’re also at the moment trying to, as seamlessly as possible, take the NetBeans Community Docs project to a new shape, structure and performance, hopefully making this a resource valuable to the NetBeans community as a whole. As for anything else… time will tell. Maybe “being prepared” never is a bad thing, being prepared both for keeping everyday business going and, given this might be necessary, participating in one fork or the other…

Update 2009-04-22: As there are quite some people (obviously) dealing with this issue, I have decided to collect some of these resources that seem worth reading to me here:

• Oracle folks themselves have put up an FAQ collection[PDF] addressing some of the questions for sure to arise from this merger. Not all questions are left answered, though, and one might eventually see the absence of the term “open source” throughout the whole of the document…
• Masoud Kalali, Jave EE developer, technical writer and author of an upcoming book on Glassfish v3, has done an interview with opensourcereleasefeed.com on Glassfish and NetBeans in light of the Oracle/Sun future perspective.
• As to be expected, there is a whole load of coverage relating this issue on java.dzone.com, most notably a rant basically outlining Java EE on its way to ‘Java Technology Museum’, a collection of responses on the Sun/Oracle deal throughout the web and of course a set of personal opinions mainly related to what’s in the Sun/Oracle deal for Java as a language and platform. Worth reading, most of it.
• There’s a lengthy yet interesting analysis of the implications of the Sun/Oracle deal to be found on redmonk.com as well, outlining a few options of what might be up next.
• Also an interesting statement by Cay Horstmann on this. Some of his predictions surely seem reasonable, though, then again, still not more or less vague than others of course.

Let’s hope for the best and see what will grow out of this. At the moment, I am once again planning to do something both enjoyable and (in this context) useful in travelling to Prague once again, hope to meet some of the guys over there and see what can be done. In this “new phase” of its doings, I think the Community Documentation project basically should / could aim at a bunch of interesting goals:

• Of course, it should as good as possible “spread the word”, do its part to extending the NetBeans user base first and foremost as an IDE but of course beyond that. From this point of view, one of the most important things in my opinion is to raise awareness that NetBeans IDE is a rather good foundation for virtually any developer, be that in open-source projects or wherever, to build custom tooling for her/his shiny new framework, application server, … upon, thus also extending the feature set of the IDE, making this a tool even “sharper”.
• Asides the Community Docs, NetBeans also has an excellent Knowledge Base to offer (honestly, like most of the Sun related technologies and platforms do), providing insights and documentation on most if not all aspects interesting about the NetBeans platform, partly also filled by documents off the Community Docs program, partly written by full-time technical writers. Providing high-quality “real life” documentation and tutorials eventually could be a way for Community Docs authors to actively support the NetBeans team, eventually allowing for full-time internal writers located “near” the NetBeans core team to focus on in-depth covering technical details and all these aspects that would require documentation created along with the very authors of the code, while the Community Docs folks take care of most of the “user space” work which in many respects just seems “a load of work”. Maybe this way we all could do our best making NetBeans even better by making it one of the best-documented pieces of software available out there. :)

By now, I invite anyone interested to join the project, join the program, offer feedback, hints or comments or whatever. Same as the IDE itself, or the platform at the foundation of it, the documentation only will be as good as those using it, reporting their needs, providing comments and requesting new articles. Let’s get goin’ then…

At the moment, this hasn’t really changed… right now, we’re into doing a project using a Java EE backend (created / built using NetBeans+maven) and a frontend / user interface making use of Eclipse RAP. By the way I am torn here: Despite my preferences for using and working with NetBeans, I have to say that the single-sourcing – approach of building desktop and web applications with Eclipse RCP / RAP is quite a good thing in a project like ours. At the moment I am looking into qooxdoo framework which obviously is the foundation of Eclipse RAP to see how this could eventually be used standalone along with NetBeans; so far I simply haven’t found any UI framework, even for web-only (no single-sourcing) development on NetBeans on par with RAP here. While dealing with RAP development in Eclipse, once again I had to learn that, in general, tooling there could be better, and Maven2 integration in Eclipse is still absolutely horrible. In case of that RAP application, we actually gave up on using Maven2 as a build environment as integrating Maven2, Eclipse target platforms and OSGi bundles has proven to be pretty ugly and add quite some complexity to the tooling environment even while not providing any additional benefit (thanks to the requirement to have “standard” Maven2 jar artifacts packed up in new custom artifacts to make them OSGi bundles even eliminated the possibility to use Maven2 for transitive dependency management here).

But that’s eventually a different story… So, looking at what NetBeans 6.7 has in store related to Maven2, it’s likely to excel here even more in comparison. As Maven2 support in NetBeans has been strong at the very least since early 6.x releases, it seems most of the features listed here are just “minor improvements” but, overally, these definitely add to the ease of use doing Maven2 based development using NetBeans…

pom.xml completion

Some time ago, CTRL+SPACE – based code completion has been introduced to NetBeans’ pom.xml editor which, of course, includes the different elements allowed to appear by the pom.xml schema definition:

So far this is not too much of an “uncommon” feature and yet way more helpful than any visual editor eventually would be. Even better, however, is that by now, while editing pom.xml, there also is code-completion support for groupId, artifactId and version content, practically allowing for browsing your repository from within the pom editor in a pretty straightforward manner:

This, eventually, so far is my most excessively used feature provided by the new Maven2 tooling…

New “Add Library” dialog

… but for all those who don’t want to use this, there also is a new way to “add libraries” to Maven2 projects from within the Project Explorer:

Basically, this also has most one could eventually wish for, including group / artifact / version code completion and a powerful search facility.

Repository Browser and Dependency Graph

More for those of us who want to “see something” on the screen: The Repository Browser window, as the name implies, allows for easily browsing different (local, remote) Maven2 repositories to get a glimpse of what’s inside. Looks good, feels good, even though I never so far used it:

Eventually more compelling is the Dependency Graph feature, which, invoked on some Maven2 project, does draw a dependency hierarchy outlining how artifacts are wired up:

This is something I do use a little more excessively in order to tell people how things in our local projects are linked; this kind of visualization at the very least is good for documentation purposes; having this image exported and somehow added to a maven2-generated project specific site would be pretty impressive…

Goal Completion

As Maven2 in Netbeans (opposing the Eclipse approach where there is a dedicated “maven2″ menu to invoke mvn-specific actions on Maven2 projects) is tightly integrated with the IDE and used as the only build mechanism in case of Maven2 projects, menu actions like “Clean” and “Build” do what they obviously should do in such a case. In situations in which “custom targets” are required, there always has been a wizard to set up such custom target actions, allowing for defining targets to be invoked as well as profiles to be used. Quite powerful, this wizard now also offers code-completion for targets and profiles available in the environment given:

This, also, is rather useful and heavily used in my environment.

Project maintaineance

In NetBeans 6.7, also the amount of Maven2 project types to be added via the “New Project…” wizard has been extended by adding new archetype templates most notably for supporting the creation of Java EE and EJB projects:

This, again, makes me want to point out that, in NetBeans, there fortunately is no need to carry around other project/build specific informations than just the pom.xml, which, compared to Eclipse, just incredibly eases dealing with loads of Maven2 projects. Asides this, the tooling now also offers a “Build with dependencies” option allowing for, well, building a Maven2 project along with all of its required local artifacts which is rather nice a feature. Eventually, the only thing still missing about project management is the ability to simply create an “empty maven2 project” (pom.xml pre-loaded with artifactId/groupId/version and nothing else, along with a simple, empty folder structure – src/main/, src/resources/ … in place). Maybe later. :)

Conclusions

So, to overally look at it, mkleint and the NetBeans Maven2 team has been pretty busy doing an impressive piece of work for what is likely to be NetBeans 6.7. And, looking at the fact that Maven2 projects in NetBeans still are plain, simple Maven2 projects easily to be built / used from the command line mvn as well, and looking at the fact as well that developers here try to implement features like the “build with dependencies” using Maven2 features not IDE related code makes NetBeans 6.7 so far the most reliable and most powerful frontent / tool for Maven2 development available to date. Good job, folks.

…
Well, Java on Ubuntu was pretty much the hands-down winner compared to Microsoft Windows Vista Premium SP1. Running the Java tests on Ubuntu had experienced significant advantages when it came to file encryption, Fast Fourier Transforms, Successive Over Relaxation, Monte Carlo, and the composite Java SciMark performance. In only the Sunflow test were the results between Ubuntu and Windows even close. With the Java 2D Microbenchmark, Windows was faster but that likely falls on the Intel Linux graphics driver having little in the way of performance optimizations and Java on Linux not yet utilizing the X Render extension.
…

Maybe this eventually could be extended in the future to (a) also include OpenSolaris and MacOS as platforms and (b) also feature performance tests of a full-blown Java EE server environment. But then again, maybe at some point it simply will become way too complex and unmanageable. Maybe a first good variation of this comparison already would be using operating systems optimized and tweaked by administrators who know their job rather than going with the “default” settings. But overally, of course, I like the outcome so far. ;)