Last night was the NetBeans IDE 4.1 Release Party. It was held at a bobsled track
here in Prague. I arrived quite late and never got to try the bobsled (okay, so maybe I was chicken) but I can
report that the beer was excellent. Even more excellent were all the fascinating conversations I had about NetBeans -- with
the actual people who make
NetBeans. Apart from the fact that I met several people for the first time (including a few who work in the same building, who I've e-mailed with on a regular basis, but who I'd never actually met
), the things we talked about were truly cool. In between, I jotted down some notes on the back of a beermat (disappointingly, the backs of Czech beermats are not white, like they are in Holland, where I'm from, so I had to write across a Budweiser advertisement). By the way, I'm not sure whether the 'correct' word is 'beermat' or 'beer mat' (I've also heard it being called a 'beer filter') but I guess that's not really relevant. So anyway, here are my notes, exactly as written on my beermat (and more or less in the order that I wrote them), together with some notes to explain them:
- code Java in mobile phone. While walking from the bobsled track to the next pub, I had a really interesting conversation with John Treacy about Mobility (i.e. J2ME MIDP Development in NetBeans IDE). (By the way, John Treacy is something like the main architect in the Mobility area.) There were actually two things that came out of that little talk, for me:
- NetBeans for Pubcrawlers. Just imagine you're sitting in the pub and you suddenly think 'Is my server running?' How cool would it be if you could press a button on your mobile phone that would check the status of the server and display a text saying 'Running' or 'Stopped'? I think that would be pretty cool and completely doable. It just means combining the Mobility pack with NetBeans IDE. You could even start/stop a server from your mobile phone.
- It would be pretty cool if I could do some coding while on the way to work, sitting in the metro. Sure, as John pointed out, the display is small and that would inhibit your programming. But what if we made the font really really small and provided a big bunch of templates? You wouldn't necessarily be making big applications, but you could test a few things out, right? Anyway, I think it could be a cool thing.
- minimum project.xml for Mevenide. I met Milos Kleint for the first time! He was really cool and we had interesting conversations throughout the evening about Mevenide. (Milos is something like the main architect for Mevenide.) I pointed out to him that the only reason I hadn't been using Mevenide in my blog (as much as I had first thought) is because I've been working on transforming existing J2SE applications into modules. These existing J2SE applications do not have their own POM (a Mavenized project.xml file), so I can't open them in Mevenide and so I haven't been using Mevenide at all -- because Mevenide assumes that you already have a POM. But Milos pointed out that one could create a "minimum project.xml file". This minimum file would have only a few details, like the name of the project etc., and you could then just drop it into your application's root directory. And then you should be able to open a J2SE application in Mevenide. Once you've done that, you can just run the Maven commands in the IDE and quickly create your module. However, what I don't like about Mevenide (and Maven), which I also talked about to Milos, is that you don't know what's going on when you run Maven goals (a "goal" is the Maven term for what a "target" is in Ant). Everything is "under the hood" in Maven. No thinking. (That's why it's really a methodology for people who don't want to think about the build-side of their module -- they just want to build.) Anyway, so what I want to do is work out what that minimum project.xml file consists of.
- Mevenide 0.7. Not out yet, but coming soon. I heard this from the source -- i.e., Milos himself! Exciting stuff.
- Ant script for branding. One of the first conversations I had last night was with Charles Beckham (he's something like the main project manager for Java Enterprise Tools). He had a cool idea for some kind of Ant script that would pull out all product-specific texts in the IDE (like titles in dialog boxes etc.) and replace them with something else. Since the IDE is built from an Ant script, this shouldn't be hard to do -- assuming that the IDE is really normalized so that this is possible. It's an interesting idea anyway. It would mean hooking up some Ant scripts to the existing script that builds the IDE and then, when running the script, everything would be rebranded for whatever product is being built from the IDE's sources.
- Software architecture for NBMS. Charlie Hunt (a NetBeans evangelist) has been a great source of information for me recently -- also, NetBeans user William Beebe seems to have profited from his input a week or so ago and wrote Building NetBeans Modules for the Complete and Utter Idiot. I asked Charlie what he'll be working on in the coming period and he said 'software architecture for NetBeans Modules'. That sounds really cool. Not sure my interpretation of the term is the same as his, but it got me thinking about 'what are the basic things needed for a module'? (Yesterday's blog entry goes into this for just one of the API's, but each API should have a basic set of 'things' needed for it.) It also got me thinking about this -- how cool would it be if the IDE provided a sample for each API? Or, better still, two samples per API: one sample that is the simplest possible implementation of the API (for beginners) and another that shows a really advanced implementation of the API. For example, there'd be a simple application that extends TopComponent. This application would dock a 'Hello World' message somewhere in the IDE. That's all. Then there'd be another sample for TopComponent that stretches the API to it's most extreme point so that more advanced users can be inspired to think about other implementations of the API for themselves. And, of course, all the samples would be documented very clearly, simply, and directly. A final point on NBMs: I've realized, from teaching myself about NBMs recently, that there is more documentation on NBMs than on any other area of NetBeans. The only problem is that it is scattered and disjointed. But it's there. It really is.
- XDoclet for all servers, then deploy to all servers. Now that Weblogic, WebSphere, and JBoss are all available as plug-ins, it shouldn't be difficult at all to write Ant scripts (1) that use XDoclet to generate server-specific deployment descriptors (such as jboss-web.xml) and (2) that copy the resulting WAR or EAR file to each of the servers' autodeploy directories. (By the way, Ludo Champenois -- the J2EE Engineering Manager -- told me some interesting things about Annotations in relation to XDoclet. That's definitely something I want to look into.) Once the application is in each server's autodeploy directory, they are automatically deployed by the server in question. And then there'd be an Ant script that opens 5 browsers, each pointing to the URL (which would be the same for each, except for the port number) of the server in question. I remember talking to somebody last night (I think it was the NetBeans evangelist Brian Leonard) about the recent trip of several evangelists to Brazil, after which Charlie Hunt wrote a report that says that people down there are testing J2EE 1.4 compliance by deploying to both the Sun Java System Application Server and to JBoss. (And this is the reason why they wanted NetBeans IDE to support JBoss.) Charlie pointed out to them that the Verifier tool (which is integrated into NetBeans IDE 4.1) has exactly that function -- it tells you whether your application is J2EE 1.4 compliant or not. However, seeing is believing, right? People want to see that their application is portable, they want to see that it runs on any J2EE 1.4 compliant server. So that's exactly why these Ant scripts would be so useful. (But there's another reason, and that's the next bullet in this list.)
- The wow effect. While talking to Brian, Milos, and Patrick Keegan (the principal author of NetBeans IDE Field Guide) about the above scenario, Milos used the term "the wow effect". That's really cool and exactly what the above bullet is all about -- okay, so you can use the Verifier to test J2EE 1.4 compliance. That's all you should need. But it's just cool to be able to deploy to 5 servers simultaneously (all from the Deploy Project menu item, bacause all the above Ant scripts would be hooked up to the web application's version of the J2SE -post-jar target in standard projects or to a project-level menu item in free-form projects). The "wow effect" is really important -- regardless of whether anyone is actually going to use it, it's just cool to know that you are able to... (And all thanks to Ant integration in NetBeans IDE 4.x!)
- Server plugins as education. Anyone learning about NetBeans Modules (see previous blog entries on this subject) should check out (in both senses of the term) the sources of the new plugins for WebLogic, WebSphere, and JBoss. Then compare the sources and look at what's common to them and what's different. Look at the layer file, for example. Install the plugins and look at how everything looks in the IDE and then go back to the layer file and see what impact each of the entries has. Also look at the Action classes. Also (this is what I am most interested in right now) look at how the server is started. There's something going on there with Cookies that I want to learn about. In short, those plugins are fantastic learning opportunities.
Apart from the above things, I had a lot of other interesting conversations. For example, I met Roumen for the first time (even though he works two floors above me)! He's so enthusiastic about NetBeans. And his blog is fantastic. (Also, see the current 'Spotlight Feature' on Javalobby.) Also, Brian Leonard (who I first learnt about after reading this great article) had some interesting things to say about his eBay article as well as pointing out (it seemed like a confession!) that the JBoss deployment descriptors in his Integrating NetBeans with other J2EE Server Vendors aren't actually needed. I'd kind of guessed that (and that's why I wrote Easy JBoss Connection Pooling with NetBeans IDE 4.1 and XDoclet) because you only need server-specific deployment descriptors when you're dealing with server-specific things like connection pools and CMP beans. At least, that's the case with JBoss. Defaults are provided, which means that JBoss will deploy an application that has descriptors for Tomcat or the Sun Java System Application Server (or anything else), except when its own resources (e.g., connection pools) are needed. That's when you need deployment descriptors like jboss-web.xml.
So, anyway, that release party was a very productive time and I'll be blogging about some or all of the above points in the coming weeks and months.