Showing posts with label NetBeans NetCAT. Show all posts
Showing posts with label NetBeans NetCAT. Show all posts

Monday, November 26, 2007

NB 6.0 RC2, Getting there... but still WS code generation issues.

Hi,

Recently I blogged about the RC1 of NetBeans I installed and the good and bad of the first release candidate. of NetBeans 6.0. One of the major upgrades of NetBeans since about ever.

I installed RC2 last week right after it came out and started testing the major bug I was experiencing, WS client generation for mobile applications. And the bug I'd found was solved, and I was very happy about that. Although it got a bit of a disappointment not long after this 'Yippie' feeling. Issue 122702 is the new code generation problem around the block when it comes to generating code for mobiles to connect to a WS. The problem is that when a class of my own is the type of a field of another class of my own and that second class is produced or consumed by a WS operation, the code for that class is not generated by NB, at least not by either RC1 or RC2. The class that should be generated is fairly simple to create myself, but that is mainly because it is a simple class, well at least the one I created for this issue. Mobility and WS support are definitely an area not yet much treaded.
There's another issue I have with the whole WS connectivity code generation issue, which is that NB generates code that already exists. So it doesn't have to generate the code at all. From a compatibility concern between WS server and WS client, I use exactly the same code on both ends. Therefore I have a mobile-library project setup that is used by my JavaME project as well as my JavaEE project. In this library all classes are defined that are used in the WS communication layer, thus ensuring that the phone sends across data that can be handled by the server and vice versa. This is probably not necessary, but has saved me loads of headaches, since I am now confident that I only send data across that can be handled by both ends. No classes that are too advanced for JavaME so to speak. All classes are there, but NB refuses to use them and generates classes of its own and uses them.

The interesting part here is that when generating a mobile client to web application, the package hierarchy as well as the classnames generated are the same as those found in my web application, i.e. the shared library mentioned above, so I can just delete these generated versions of my classes and use the right classes instead.
When generating a mobile WS client, the package hierarchy and the class names differ. Which makes it harder to replace the generated classes with my own created classes. Really mind boggling is the fact that the standard naming convention 'MyClass' is donned for 'myClass', which looks exactly like the field naming convention utilized by most developers I know.

But mind, I didn't get any exception pop-ups at all since installing RC2, the IDE is rather responsive, more than RC1 I think. And overall it is becoming a solid product, at least from my point of view. Me being a developer working on a mobile massive multi-user online realtime strategy game (MMMORSG).

Iwan

Tuesday, November 20, 2007

NB 6.0 RC1, more thoughts... some bad ones

... well, for starters I want to just say that the latest bug I found in the code generation of WS support in JavaME projects was fixed, almost immediately after filing it. Let me put it this way, if NB would be in constant beta, in constant NetCAT, I would download the latest dev build every day, use it, report the bugs and continue working with fixes the next day... but that would prevent the team from adding big new awesome features. So I am glad the NetCAT is only at the end of each release cycle and it is to improve the final version's quality.

So what have I been doing lately, to be honest not much. Why? Because the latest dev build of NB screwed up my build files, the build-impl.xml files to be accurate. After installing the build fixing my WS issues, I got build issues in the 'jax-ws.xml' file and the build-impl.xml file.
I think I will file a P1 bug on this, since I don't like tools to just go and 'fix' my files and render them useless without a backup anywhere. In fact the much lauded 'local history' feature is not helping here either, since probably it will only keep track of local history of those files I am editing myself.

Going back to RC1 didn't fix the problem... not immediately. I had to throw away my build-impl.xml and my jax-ws.xml files and have NB regenerate them, after that it all worked again.
B.t.w., I tested the fix by running my JavaEE project in RC1 and generate the WS code in the fixed build referring to the WSDL in the application started in the RC1 started instance of Glassfish.

I found another bug there though, some of the code that was to be generated, didn't generate at all. Weird considering the code, but still not good. So I need to check whether it is my code and otherwise report a bug, once again. With full faith in the NB development team. Sofar, they haven't let me down one bit.

Iwan

Iwan

Friday, November 16, 2007

NB 6.0 RC1, my thoughts sofar

Hi,

It has been a while since I last blogged about NB 6. And for good reason since I used it instead of blogging about it. Which to my defense, means that it was a joy to use NB and our game has progressed considerably.

I had a few problems with the code generation for WS support in mobiles, but these were all fixed within a day. Although today I found another code generation problem in NB 6, but that will probably be fixed soon as well.

A few days ago they released the real RC1 and I installed it as soon as I got my hands on it. Luckily for me, one of the dev builds I was relying on, was already dubbed RC1 and thus I had all the customary folders setup already (/.netbeans/RC1) which was a timesaver, although moving the relevant files and folders from one version to another is a breeze nowadays. The RC1 is really stable and apart from a firewall problem I didn't encounter any serious issues, and to be honest, the firewall problem wasn't a NetBeans issue rather a Java issue. I had to remove all Java.EXE lines in the firewall rules of Symantec and have new rules applied and than open everything up for Java.EXE in Symantec in order to get the Update Centers back to work and more importantly the Collaboration stuff (Why isn't Collaboration not a part of the standard distro?) Because we develop the game while sitting at different locations, Collaboration is a major means of discussing our progress.
The SQE plugins (Findbugs and friends) are back in my installation as well, as they are so cool and great to use.

But back to NB 6 RC1. The major gripe I and others have are erroneous error-badges. I can't care that much about it, but a friend of mine considers this a really bad thing. Might be that he's got less confidence in his coding skills and thinks that when NB thinks something's wrong, it must be although he thinks all is fine :)
The rest is going really smoothly, loading is really fast, unless you have a lot of projects that need to be opened, than it can take for ages. Maybe NB could track the projects I really work on and open them eagerly and the others lazy? The same might apply for plugins. Those I use regularly should be opened right away, those I don't should be loaded lazily. If possible. Still RC1 loads faster than previous builds I feel.

All in all, it's getting there and the level of quality is great, especially since it feels like about all addon packs are updated and better integrated as well. Still some open issues that I would like to see fixed. Maybe those that are more irritating to newbies should be fixed asap in the first few weeks after the release of NB6.

Iwan

Wednesday, October 17, 2007

Three weeks of NetCAT 60 - Back in the saddle

Yes, it has been a while and I am actually longer than just 3 weeks member of NetCAT 60. But last week I was on vacation in Oman, scuba diving all week long. Believe it or not, I haven't thought about NetBeans during that week for a single time.

Now that I am back I've installed the dev build of last Monday. In my mailbox I found some notifications from Issuezilla that some UML bugs where fixed and I was kindly asked to retest. Which I am planning to do asap.
In the meantime, there are some WS-Client bugs that I encountered and am hoping that they were fixed as well. So that is something for me to find out as well. And if not fixed I need to bug a few people, because I need that WS-Client support stuff in NB. That is in fact one of the biggest problems I have with NetBeans; I have no clue as to what I am doing anymore, since NetBeans does it all for me. Creation of a WSDL? No idea as to how to do this. What makes a class a webservice? No idea, because NetBeans just does this for me. And more of the same in all areas. Wouldn't it be nice if there was somekind of 'stupid-mode' in NetBeans, that when you turn it on, NetBeans wouldn't help you at all but for syntax highlighting and compilation and stuff, but none of the code would be generated anymore. Than once you got the stuff done yourself, it would switch to smart-mode again, and you would never have to worry about that generic boiler plating anymore.

Anyway, I installed the dev build of last Monday, and my project didn't build anymore. Something to do with 'build.classes.dir.real' not being defined. This might be due to something I did myself, since I had been experimenting with some stuff related to WS-Client. So I won't report it. A revert to something in SVN fixed the problem, so I am back on track.

Iwan

Tuesday, October 02, 2007

Two weeks of beta1 - Let's get started with the dev builds

So I've now been working with the NB 6 releases beta1 and after, after here being the dev build of last week Monday. My strategy here is to install on Monday the latest dev build I can download and use it for a week, not installing any newer builds unless there's a bug that is holding me up. Sofar, I have one bug that is keeping me from progressing on developing my game and sofar it hasn't been resolved. Unfortunately.

Yesterday I installed the latest dev build, so now it is time to start raving and ranting on last week's Monday dev build. And let me put it this way, NB is really good and shaping up.

So just to re-iterate, what is that bug that is preventing me from developing the greatest mobile game ever produced? WS Client support on J2ME. And with the build of last week, that wasn't resolved. Since I filed a bug, I am waiting for that 'RESOLVED' message out of Issuezilla, which I didn't get yet. But in the meantime I started on developing the second incarnation of our Pong based game, called Mong, from scratch and I noticed some back-end functionality missing in our multi-player strategy game that I need to put in.

So what else is going on? SQE is back in the picture, as the SQE AUC was updated. And gosh, do I have a lot of bugs to be found in my code. Thanks to the modules in the SQE they're all visible now. Hmmm, I guess I should be happy about this. The good thing about something like SQE is that you get good quality plugins with one go, and you don't have to worry, in theory, that you are compromising your IDE.
Something that I really don't like, is the fact that when you have some (possibly crippled) JavaDoc on for example a method, than you need to fix it one step at a time. There's no such thing as 'fix JavaDoc' for crippled or incomplete JavaDoc. Guess the NB developers develop their code by starting of with the JavaDoc and then implement what was documented. Probably the way it should be done... Something I just came across is the lack of something called 'Get JavaDoc from overridden method', which would copy the JavaDoc from the method that I am overriding. In fact, the overriding method should always comply with the documentation of the overridden method, since it is just an alternative implementation of the same functionality. Purity over all.

In last week's status update from Jiri, he mentioned that there was suspiciously little email traffic on the J2ME stuff in NB 6... well Jiri, you have to blame the Mobility guys, since they're doing a great job. Really! I still have to use the databinding they came up with and the game-editor features. Time is here the bottleneck, anybody found a way to cram more than 24 hours in a day?

The coming week is going to be slow, I have to finish some stuff at a customer of mine, I need to do my Q3 taxes, but most important of all. I need to prepare for my trip to Oman. A week of scuba diving it is. I just hope that it doesn't mean that I will be kicked of the NetCAT team because of this.

Iwan

PS: Last week I got some really excellent feedback on my blogs. For one, I was told how to get the libraries from one project to another, and secondly the SQE AUC is fixed and now I got those excellent tools back in NB. Thanks to you all.

Wednesday, September 26, 2007

One week of beta1 - Party time with Web Services.

So yesterday I blogged about installing NB 6.0 beta1. I just installed the dev build of the 25th, but I used beta1 for about a week on our mobile multi-player game. I was developing the backend last week on Glassfish v2b58g.

As with the installation everything runs quite smoothly, although you shouldn't be looking in the messages.log, since it is not stacktrace free. So far I haven't been able to relate these stacktraces to problems in NB. Well maybe, sometimes NB freezes, it just isn't doing anything, not even consuming CPU, not even writing log entries, but when I switch between applications on my XP box, NB doesn't even come up. I do see some stacktraces in messages.log, but since it doesn't have timestamps, I'm not sure where to put them in the time-space-continuum. Killing java.exe works and I can start NB without problems. I don't even get a message stating that NB is still running.

Sofar I've been using NB to develop my JavaEE backend for the game, which is a EJB 3 solution using TopLink and JavaDB for storage, and WS for interfacing with the client app. I'm using the SWING client that NB can pretty much generate for you to test the WS.

That is actually a cool feature, you just import the WSDL files of the WS you want to connect to and than drag-n-drop the operations in the WSDL into your sources and NB will generate all the code. This is pretty magical stuff, and I use the word 'magical' deliberately, since the documentation on this feature is not very clear. Now I must admit that I didn't read the documentation extensively. The thing that is not clear to me is how I can switch from the generated Java classes that make up the arguments and results of the operations I call to the classes that are actually used by the WS. That is how I will use the code in the mobile client, I have a JAR file that contains the classes for interfacing with the backend by the frontend and those classes I want to use in my tests as well, for obvious reasons. The documentation at first and second glance isn't really clear on how to change this behavior.
There's another gripe I have with this feature of NB to generate the code based on the WSDL: When you change the WSDL or rather the interface of the WS and therefore the WSDL, NB doesn't pick this up automatically, instead you have to refresh the WSDL yourself. There is a checkbox unchecked when you refresh the client that allows you to overwrite the local WSDL with the original WSDL, but there's nowhere to be found what this means. What it means to leave it unchecked or to check it. I have no idea what the impact is to leave it unchecked, as you guess, I check it all the time. Guess I'll file an issue on this right after posting this blog.

One other issue I have with the SWING client and its WS support, is with ANT. All ANT code used is generated by NB, yet I see the following warning: Consider using / so that wsimport won't do unnecessary compilation and have no idea as how to respond to this... well I do, I ignore it. I have no clue as to how to change my ANT file in order to prevent wsimport to do unnecessary compilation. So far it hasn't hurt me too much that stuff is being compiled over and over again. It only takes seconds on my box, so why worry.

For some reason the mobile library I created (it's a JAR file) and am depending on in my JavaEE project is not being compiled when it changed. Well NB isn't building that project when it builds my main project, although there is a clear dependency. But I noticed that with a JavaEE project I created in beta1 that depends on this library is building this dependency, so I guess it's an artifact of an older NB version. I have to look into this.

Well sofar for my experiences in the WS area with NB 6 beta1. All in all I am very happy, NB is rather stable, although I need to kill java.exe every now and then.

Iwan

Tuesday, September 25, 2007

One week of beta1 - Installation time

So it has been one week of beta1 usage for me now. I'm participating in the NetCAT 60 program, yup I'm one of the chosen ones so I have to use beta1. And being the person I am, I am using it on a production project... although it is intended to be a project that is going to be highly successful... a mobile game that has a JavaEE backend.

But on to beta1. Having played with the dev builds recently as M10 was really not very useful and it prevented me from going back to M9 because of some installer issue I never tried to fix. The dev builds got fairly stable, but there were some annoying full-stops every now and then, and some of the builds had more error messages popping up than code completion dialogs.
The first thing that struck me after installing beta1 and using it, was how fast it started. That was a lot better than M10 and even better than the last dev build I had installed.
One of the things I change immediately after installing a NB version are the startup params, more precise the memory settings. All settings are tripled compared to the default settings. Starting of with a huge amount of memory allocated to the JVM seems to speed things up. Maybe its just psychological, but hey, if it looks faster it is faster.

Then on to the next steps, installing the plugins you can't do without. First of all I need to say that I downloaded and installed the full version. Everything is installed, although I don't plan to use the C/C++ support, the Ruby support and the profiler. Well maybe the profiler.
I still can't believe collaboration is not part of the standard installation. It is probably the plugin I use most apart from the obvious plugins that are part of the standard install. Collaboration is really important as I develop the game together with a friend of mine. He lives about 100 km away from me, so we meet in NB, discuss our progress in NB etc.

After having that done, well this time, I refrained from installing every other module I could find. I did install the PluginPortal plugin, but that's gone now, because it is not really usable because too often I selected a module that wasn't supporting NB 6, that is something that needs a fix. Only show plugins that are supporting the NB version I use.
I tried the SQE update center, but that is not supporting NB versions after M10, which is too bad, since these are really, and I mean really useful plugins.


Next is copying the Templates directory from my NB 5.5.1 installation. I don't believe in importing settings from a previous version, as I had some really bad experiences with older versions (upgrading from NB4 to 5 for example). I choose to redo the work I'd done in the previous version, and copy happily whatever needs copying.
I still need to find a way to smartly get my library definitions across from one version of NB to another. Fortunately I only have like 3 libraries defined, so that's easy to do by hand. But still...

And that's about it. Well almost. After opening the projects that make up our game, I define a project group as well. That's a feature I learned about just recently, where I had my own game projects (about 7 projects) and I was working with a customer (I did the UML design for them in NB) which had about 27 projects. Using groups made it really easy to switch over from my own work to the customer's projects.

So that was pretty much my installation of NB 6 beta1, quite uneventful, quite boring. Don't you just hate it when everything goes right, and you intended to blog about it. One feature request to the NB team: Don't make it so smoothly with beta2, so there's something to complain about when blogging about the installation.

Iwan