Hi,
Yesterday I finished my 'assignment' on the UI of our game IFF. I completed the the registration form and added a form including tabs for maintaining other relevant user data. I then incorporated it all in the game itself. Unfortunately, the book ("LWUIT 1.1 for Java ME Developers") doesn't really elaborate on this topic. It doesn't tell you in so many words how to combine your LWUIT based parts and your old fashioned LCDUI based parts into one MIDlet.
Since we're working with SVG in the actual game and we use LWUIT for the various forms this is relevant. But it all worked out nicely. Replacing our SVG based forms with the LWUIT version was almost without problems. We had an issue with the Display class, but the info in the book was sufficient to fix it. As it turned out, initializing LWUIT's Display in the startApp of the MIDlet was sufficient to get it all working. Probably more so because I created a separate source file containing all code for the LWUIT Form. Hence LWUIT didn't interfere with the rest of the code.
There's a lot more on LWUIT than meets the eye, but I'm actually quite confident that the book can and will help out. But that sounds like an overall summery, something I was planning to write up in a week or two, after I get back from a weeks vacation at the Red Sea, Egypt.
As we will be leaving on Thursday, I've got a few days left to get it all together and have the game available on the website. Which is currently optimized for a 240x320 screen.
Iwan
PS: IFF is tested on a Nokia N85 and an N95. I'm going to test it on a SE W595 as well and a Nokia 6300 is in the pipeline as well. If you have a recent model phone, mid or high-end, you're invited to join our beta test.
Showing posts with label NetBeans. Show all posts
Showing posts with label NetBeans. Show all posts
Tuesday, September 29, 2009
Tuesday, September 22, 2009
Review of "LWUIT 1.1 for Java ME Developers" by Packt Publishing [part 03 - first uses]
i,
So the last few days I have been struggling, not with LWUIT but with my health. But I made some progress.
As I stated last time, I think the book "LWUIT 1.1 for Java ME Developers" is more of a reference than a tutorial and while working on the screens for our game, I found that this is true. I still need to download all source-code from the Packt Publishing site, but I think it is safe to say that I won't learn programming using LWUIT with this book.
The route I took is that I have the design of the screens I want to redo in LWUIT available as SVG screens (see for yourself at the left). Like I said before, the support for these SVG forms on my N95 and my N85 is disappointing to say the least, so we chose to use LWUIT instead.
I recreated the form in LWUIT as well as the code behind it, so the components on the form are bound to some attributes in the form. That all worked very nicely. (see at the right)
The book was very helpful in this perspective. It showed me very clearly how to create a form, use different layouts and how to add components to the form. The book doesn't degrade itself to a printout of the JavaDoc, it actually provides a very good mix of API and context.
But you should be aware that unless you know what you want and how it should look like, there's not really a point in opening the book.
As you can tell from the screenshots in this post, the screens have the same fields, but the design is completely different. Fortunately the book has quite a bit on the topic of themes and resources. That's my next mission; Figure out how I can make them look a like, meaning the LWUIT screen to look like the SVG screen. Expect to read about this in the next post.
Iwan
So the last few days I have been struggling, not with LWUIT but with my health. But I made some progress.
As I stated last time, I think the book "LWUIT 1.1 for Java ME Developers" is more of a reference than a tutorial and while working on the screens for our game, I found that this is true. I still need to download all source-code from the Packt Publishing site, but I think it is safe to say that I won't learn programming using LWUIT with this book.The route I took is that I have the design of the screens I want to redo in LWUIT available as SVG screens (see for yourself at the left). Like I said before, the support for these SVG forms on my N95 and my N85 is disappointing to say the least, so we chose to use LWUIT instead.
I recreated the form in LWUIT as well as the code behind it, so the components on the form are bound to some attributes in the form. That all worked very nicely. (see at the right)
The book was very helpful in this perspective. It showed me very clearly how to create a form, use different layouts and how to add components to the form. The book doesn't degrade itself to a printout of the JavaDoc, it actually provides a very good mix of API and context.
But you should be aware that unless you know what you want and how it should look like, there's not really a point in opening the book.
As you can tell from the screenshots in this post, the screens have the same fields, but the design is completely different. Fortunately the book has quite a bit on the topic of themes and resources. That's my next mission; Figure out how I can make them look a like, meaning the LWUIT screen to look like the SVG screen. Expect to read about this in the next post.
Iwan
Monday, September 14, 2009
Review of "LWUIT 1.1 for Java ME Developers" by Packt Publishing [part 02 - initial feelings]
Hi,
Last week I posted about the context of my review, I want to use the book "LWUIT 1.1 for Java ME Developers" on a real project in which I start of using LWUIT without know it at all, and see if the book helps me in achieving my goal(s). While doing so I'll be posting my findings as a series of posts resulting in the complete review.
Well my first impression of the book once I opened the box it came in was: "Hmmm, one of those computer books". Which it is of course, so no judging there. Although I find the yellow flower on the cover thought provoking. Why did they choose a yellow flower? If you know the answer, let me know. I haven't gone into the book to find out why.
First of all, the book is on LWUIT 1.1, I'll be using LWUIT 1.2. I want to post about the differences sometime soon, but this is relevant information for you as a reader. Where I think the book is outdated, I'll let you know.
The Table of Contents is straight to the point, it is complete and there is only one. I don't like books where they have a TOC that only covers the high-level chapters and then one that covers all chapters, sections, paragraphs and what not. Waste of paper and my time. Here they've used fonts and styles to make clear what the main sections are and what the subsections are. After reading through the TOC I got the feeling that I'm dealing with a Reference Guide instead of a book to learn LWUIT.
The Preface is doing what it is supposed to do, provide you with all kinds of information not related to the topic of the book, but still you need it while 'using' the book. And here it becomes apparent that I'm dealing with a reference guide. Not a book for the real fresh fish in the LWUIT pond. No problem, I've got Google in my toolbox.
It is also stated that I need the Sprint Wireless Toolkit, which is derived from I believe the Sun WTK, and customized and all by Sprint. Since I'm using the JavaME SDK 3.0 for my LWUIT development or NetBeans 68 (dev builds currently) I might run into somethings here. But maybe not. Since Sprint is an US based mobile provider, I assume that those who're looking to deploy in the US are familiar with the SDK, the rest of the world is probably more WTK (or JavaME SDK) oriented or looking into SDK's by the phone manufacturers/
I've decided not to install the Sprint Wireless Toolkit and will let you know what you can expect when you also follow that route.
So here's how I proceed: I'll find a decent tutorial to get the hang of LWUIT and get it to run in NB and the JavaME SDK by Sun. Then I'll design my screens and will then get back to the book to implement them. Meanwhile I will be reading the book and adjust my plan if I think that makes more sense.
Iwan
Well my first impression of the book once I opened the box it came in was: "Hmmm, one of those computer books". Which it is of course, so no judging there. Although I find the yellow flower on the cover thought provoking. Why did they choose a yellow flower? If you know the answer, let me know. I haven't gone into the book to find out why.
First of all, the book is on LWUIT 1.1, I'll be using LWUIT 1.2. I want to post about the differences sometime soon, but this is relevant information for you as a reader. Where I think the book is outdated, I'll let you know.
The Table of Contents is straight to the point, it is complete and there is only one. I don't like books where they have a TOC that only covers the high-level chapters and then one that covers all chapters, sections, paragraphs and what not. Waste of paper and my time. Here they've used fonts and styles to make clear what the main sections are and what the subsections are. After reading through the TOC I got the feeling that I'm dealing with a Reference Guide instead of a book to learn LWUIT.
The Preface is doing what it is supposed to do, provide you with all kinds of information not related to the topic of the book, but still you need it while 'using' the book. And here it becomes apparent that I'm dealing with a reference guide. Not a book for the real fresh fish in the LWUIT pond. No problem, I've got Google in my toolbox.
It is also stated that I need the Sprint Wireless Toolkit, which is derived from I believe the Sun WTK, and customized and all by Sprint. Since I'm using the JavaME SDK 3.0 for my LWUIT development or NetBeans 68 (dev builds currently) I might run into somethings here. But maybe not. Since Sprint is an US based mobile provider, I assume that those who're looking to deploy in the US are familiar with the SDK, the rest of the world is probably more WTK (or JavaME SDK) oriented or looking into SDK's by the phone manufacturers/
I've decided not to install the Sprint Wireless Toolkit and will let you know what you can expect when you also follow that route.
So here's how I proceed: I'll find a decent tutorial to get the hang of LWUIT and get it to run in NB and the JavaME SDK by Sun. Then I'll design my screens and will then get back to the book to implement them. Meanwhile I will be reading the book and adjust my plan if I think that makes more sense.
Iwan
Friday, September 11, 2009
Review of "LWUIT 1.1 for Java ME Developers" by Packt Publishing [part 01 - context]
Hi,
Yesterday I got my review copy of Packt Publishing's book on "LWUIT 1.1 for Java ME Developers" and as promised before I'll post a review as I am reading and more accurately experiencing the book.
I'm currently working together with friends of mine on a free multi-player online realtime strategy game for mobiles. It's called IFF: Identification Friend or Foe and we're in a private beta stage. The reason why we're in private beta is that our sign-up screens in the client aren't working... on all phones. Our major concern while working on the game was related to screen resolution, since all manufacturers of phones have their own specific set of supported resolutions scaling is an important aspect of our GUI. Obviously the choice fell on SVG (Scalable Vector Graphics).
NetBeans has excellent support for SVG and really helps in designing SVG based UI's including forms. So we went working on it and within a few hours we had our prototype of the registration form, to be used in for signing up. All worked fine until we deployed the client to our Nokia phones. The SVG forms don't do well on an N95 or an N85. The actual game UI does excellent on these models but no chance for the forms. So I went installing various Nokia emulators on my Vista box and started debugging. As it turned out, the SVG support on Nokia devices is not to be used for forms, period.
Here comes LWUIT to the rescue... and together with it JavaME SDK 3.0. Marcel and I thought for a moment to do the UI ourselves, but after about 20 seconds we were convinced that it would turn out to be a LWUIT-like framework, so LWUIT it would be.
Around the same time I was approached by Packt Publishing asking if I was interested to review their book on LWUIT 1.1. So we waited to work on the forms in LWUIT until the book arrived and yesterday it did.
What you'll read in these series are my impressions on the book, the quality of the information in it, the usefulness of the book for somebody who knows Swing but not LWUIT and how the book relates to LWUIT 1.2, since that is what I will be using.
Iwan
I'm currently working together with friends of mine on a free multi-player online realtime strategy game for mobiles. It's called IFF: Identification Friend or Foe and we're in a private beta stage. The reason why we're in private beta is that our sign-up screens in the client aren't working... on all phones. Our major concern while working on the game was related to screen resolution, since all manufacturers of phones have their own specific set of supported resolutions scaling is an important aspect of our GUI. Obviously the choice fell on SVG (Scalable Vector Graphics).
NetBeans has excellent support for SVG and really helps in designing SVG based UI's including forms. So we went working on it and within a few hours we had our prototype of the registration form, to be used in for signing up. All worked fine until we deployed the client to our Nokia phones. The SVG forms don't do well on an N95 or an N85. The actual game UI does excellent on these models but no chance for the forms. So I went installing various Nokia emulators on my Vista box and started debugging. As it turned out, the SVG support on Nokia devices is not to be used for forms, period.
Here comes LWUIT to the rescue... and together with it JavaME SDK 3.0. Marcel and I thought for a moment to do the UI ourselves, but after about 20 seconds we were convinced that it would turn out to be a LWUIT-like framework, so LWUIT it would be.
Around the same time I was approached by Packt Publishing asking if I was interested to review their book on LWUIT 1.1. So we waited to work on the forms in LWUIT until the book arrived and yesterday it did.
What you'll read in these series are my impressions on the book, the quality of the information in it, the usefulness of the book for somebody who knows Swing but not LWUIT and how the book relates to LWUIT 1.2, since that is what I will be using.
Iwan
Monday, August 31, 2009
Review of "LWUIT 1.1 for Java ME Developers" by Packt Publishing [part 0]
Hi,
Last week I received and answered an email from Packt Publishing. They wanted to know if I was interested to review their book on LWUIT called "LWUIT 1.1 for Java ME Developers". And I said yes, so the book is on its way to me.
Now the interesting part is that we, Marcel and myself, just recently decided to do all the dialogs in our game IFF using LWUIT instead of SVG. Most important reason is that we just can't get dialogs (forms) to work correctly on our N-Series phones. The cursor in edit fields doesn't move correctly, editing only works by switching to the ugly normal text-area input of MIDP.
Although the actual game graphics will remain in SVG, the dialogs (forms) will all be in LWUIT.
Marcel already followed the tutorial on the LWUIT site and is the expert between the two of us, I'm the novice. So I'll be looking at the book from that point of view. Without having written a single character of code that is supposed to use LWUIT I will start on the book and see if it helps me accomplish the tasks at hand... which will result in a series of blog posts.
Hopefully in the end you'll have
Now the interesting part is that we, Marcel and myself, just recently decided to do all the dialogs in our game IFF using LWUIT instead of SVG. Most important reason is that we just can't get dialogs (forms) to work correctly on our N-Series phones. The cursor in edit fields doesn't move correctly, editing only works by switching to the ugly normal text-area input of MIDP.
Although the actual game graphics will remain in SVG, the dialogs (forms) will all be in LWUIT.
Marcel already followed the tutorial on the LWUIT site and is the expert between the two of us, I'm the novice. So I'll be looking at the book from that point of view. Without having written a single character of code that is supposed to use LWUIT I will start on the book and see if it helps me accomplish the tasks at hand... which will result in a series of blog posts.
Hopefully in the end you'll have
- A comprehensive book review on LWUIT
- A more complete version of IFF, which is now in beta if you're interested.
A little annoyance that's groing bigger by the day
Hi,
Promise: Right after publishing this post, I'll file an issue!
So I have setup NB such that the import section and all JavaDoc is collapsed by default when opening a file. Why? Because it clutters my screen and I don't find it helpful to see all that code and documentation.
Since the IDE is doing such a great job in managing my imports and the code-completion shows all JavaDoc when I need it, I don't find it beneficiary to have it in plain sight when I don't need it.
But here's the catch. NB doesn't update the 'focus' of a file when I open it. What I mean is that when I CTRL-Click something in an editor and the source file is not yet opened, NB will open the file, jump to the correct location, make sure that the location is in the visible area on screen and then collapse all editor folds... moving the location of screen. And I need to scroll window to show what I want to see.
This is on NB 6.7.x on Vista at least. Latest updates of the JDK installed of course.
Update: It is filed as issue 171149.
Iwan
Promise: Right after publishing this post, I'll file an issue!
So I have setup NB such that the import section and all JavaDoc is collapsed by default when opening a file. Why? Because it clutters my screen and I don't find it helpful to see all that code and documentation.
Since the IDE is doing such a great job in managing my imports and the code-completion shows all JavaDoc when I need it, I don't find it beneficiary to have it in plain sight when I don't need it.
But here's the catch. NB doesn't update the 'focus' of a file when I open it. What I mean is that when I CTRL-Click something in an editor and the source file is not yet opened, NB will open the file, jump to the correct location, make sure that the location is in the visible area on screen and then collapse all editor folds... moving the location of screen. And I need to scroll window to show what I want to see.
This is on NB 6.7.x on Vista at least. Latest updates of the JDK installed of course.
Update: It is filed as issue 171149.
Iwan
Wednesday, August 19, 2009
Why Netbeans rules Glassfish... racing got me to this conclusion (part 2)
Well, last time I used this title I got some useful comments. Meanwhile I fixed my problems and in fact it was a race condition that I couldn't fix by using locks.
The problem I was facing had to do with the fact that I have a graph of objects that I maintain in a database. Adding a new object to the graph, means that certain objects would point to it as being a new neighbor. Which objects in the graph would get a new neighbor is determined by an algorithm that ensures that this process is 'fair' to the other objects in the graph.
When two or more objects are added more or less simultaneously to the graph, my algorithm would do the same thing and select the same objects that would receive a neighbor. One might argue that the system on this topic is truly stateless.
Anyway, I tried to fix my algorithm to not always pick the same neighbors, that didn't work. I tried to change my datamodel such that the system would be a little more lightweight, that obviously didn't work either. I tried to work with locks which ensured consistency in my model, but still no scalability on this end. I did some tweaking with transaction-scope and that fixed some issues. But finally I realized that I needed the EJB 3.1 Singleton which is not available in 3.0 so I mimicked part of its functionality by introducing a synchronized block on the smallest piece of code that suffered from the concurrency. This together with a smaller transaction scope fixed the problem.
But since that doesn't give me that warm and fuzzy feeling. Especially not since I know there's a solution in EJB 3.1, I'm now considering moving to GF 3 and use EJB 3.1 features. Of course all thru NetBeans' support for GF3 and EJB 3.1.
I'll keep you posted.
Iwan
The problem I was facing had to do with the fact that I have a graph of objects that I maintain in a database. Adding a new object to the graph, means that certain objects would point to it as being a new neighbor. Which objects in the graph would get a new neighbor is determined by an algorithm that ensures that this process is 'fair' to the other objects in the graph.
When two or more objects are added more or less simultaneously to the graph, my algorithm would do the same thing and select the same objects that would receive a neighbor. One might argue that the system on this topic is truly stateless.
Anyway, I tried to fix my algorithm to not always pick the same neighbors, that didn't work. I tried to change my datamodel such that the system would be a little more lightweight, that obviously didn't work either. I tried to work with locks which ensured consistency in my model, but still no scalability on this end. I did some tweaking with transaction-scope and that fixed some issues. But finally I realized that I needed the EJB 3.1 Singleton which is not available in 3.0 so I mimicked part of its functionality by introducing a synchronized block on the smallest piece of code that suffered from the concurrency. This together with a smaller transaction scope fixed the problem.
But since that doesn't give me that warm and fuzzy feeling. Especially not since I know there's a solution in EJB 3.1, I'm now considering moving to GF 3 and use EJB 3.1 features. Of course all thru NetBeans' support for GF3 and EJB 3.1.
I'll keep you posted.
Iwan
Wednesday, August 05, 2009
NetBeans 6.8 M1... first issue right after starting up
Hi,
Thrilled after installing M1 of NB68 I fired it up and the first dialog was a disappointment. It didn't see that I have a NB67 installation, instead it asked if it was okay to import the settings of my NB65 installation. Bummer.
I reverted back to NB671 and will give NB68M1 a second try later today. Recreating all settings myself and will file a bug on it.
Iwan
Thrilled after installing M1 of NB68 I fired it up and the first dialog was a disappointment. It didn't see that I have a NB67 installation, instead it asked if it was okay to import the settings of my NB65 installation. Bummer.
I reverted back to NB671 and will give NB68M1 a second try later today. Recreating all settings myself and will file a bug on it.
Iwan
Monday, July 27, 2009
Why Netbeans rules Glassfish... racing got me to this conclusion
Hi,
Last weekend I ran into this race-condition on the server side of our game IFF (plug: http://www.sticktailgames.com:8080/IFFMobile/). I was stress testing the server and what do you know, all crumbled into a pile of rubbish as soon as, dare I say, more than one person at a time registered for the game. Now I do have made some short-cuts in the server code to circumvent some code because I want to test a lot, and don't want to have to wait if I don't have to. So entering an activation code on your mobile was taken out of the equation. Anyway, the problem is there and since I do expect some time in the future that two or more people register at the same time, I wanted this to be solved.
As it turned out, there was a race-condition; two processes were fighting for the same record in the database and that turned into an inconsistent state of the data. And since inconsistency in the database is worse than a crashing system that at least is consistent so I can start it up again... It turned out that this little piece of concurrency could be turned into a little piece of sequency and all would work out really nice. So how do you control this? I thought about using a queue to list the requests for a unique record in the database. Since the requests would be handled sequentially I would be out of the woods. A message queue is easily created and NB created all code, including the creation of the server resources for my MDB, queue etc.
Proper code generation is sooooo convenient.
But I needed to revert a lot of code this weekend to a state prior to the weekend, and that included my messaging stuff. Turns out, the resources NB generated in Glassfish v2.1 didn't want to move. Every attempt to delete them turned into an error message, stating that the resource could not be deleted as it was used in server server.
From the GF output in NB: Validation error: [ADMVAL1052: Element connector resource 'jms/iffBaseGenerationTopicFactory' can not be deleted because it is referenced from server 'server']
Not from NB nor from Glassfish' own admin console I couldn't delete the created ConnectionFactory. I had to open domains/domain1/config/domain.xml and delete the lines referring to my ConnectionFactory.
Once I found out how to remove the JMS resources I could get back on track. Now I'm back at solving my race-condition. Still thinkering on how to handle this. Probably I need to ensure that there'll be only one connection possible to the queue. So only one MDB can access the queue and handle the message. Any other approaches are appreciated in the comments of this post.
Iwan
Last weekend I ran into this race-condition on the server side of our game IFF (plug: http://www.sticktailgames.com:8080/IFFMobile/). I was stress testing the server and what do you know, all crumbled into a pile of rubbish as soon as, dare I say, more than one person at a time registered for the game. Now I do have made some short-cuts in the server code to circumvent some code because I want to test a lot, and don't want to have to wait if I don't have to. So entering an activation code on your mobile was taken out of the equation. Anyway, the problem is there and since I do expect some time in the future that two or more people register at the same time, I wanted this to be solved.
As it turned out, there was a race-condition; two processes were fighting for the same record in the database and that turned into an inconsistent state of the data. And since inconsistency in the database is worse than a crashing system that at least is consistent so I can start it up again... It turned out that this little piece of concurrency could be turned into a little piece of sequency and all would work out really nice. So how do you control this? I thought about using a queue to list the requests for a unique record in the database. Since the requests would be handled sequentially I would be out of the woods. A message queue is easily created and NB created all code, including the creation of the server resources for my MDB, queue etc.
Proper code generation is sooooo convenient.
But I needed to revert a lot of code this weekend to a state prior to the weekend, and that included my messaging stuff. Turns out, the resources NB generated in Glassfish v2.1 didn't want to move. Every attempt to delete them turned into an error message, stating that the resource could not be deleted as it was used in server server.
From the GF output in NB: Validation error: [ADMVAL1052: Element connector resource 'jms/iffBaseGenerationTopicFactory' can not be deleted because it is referenced from server 'server']
Not from NB nor from Glassfish' own admin console I couldn't delete the created ConnectionFactory. I had to open domains/domain1/config/domain.xml and delete the lines referring to my ConnectionFactory.
Once I found out how to remove the JMS resources I could get back on track. Now I'm back at solving my race-condition. Still thinkering on how to handle this. Probably I need to ensure that there'll be only one connection possible to the queue. So only one MDB can access the queue and handle the message. Any other approaches are appreciated in the comments of this post.
Iwan
Tuesday, July 21, 2009
JavaME in NB 6.7
NetBeans 6.7 has been out in the wild for a while now and... well and then there's the JavaME stuff, which is kinda important to me since we're developing mobile games (we = Sticktail Games). JavaME SDK 3.0 is finally out the door and pre-packaged with NB 6.7, but still no support on other platforms than Windows. Which until last Christmas wasn't a big deal, but I got a MacBook 13" from misses Santa and would've liked native support for all my tooling... bummer. I'll have to invest in some VirtualBox stuff to get the ME parts running. Any tutorial to get this going is appreciated, but please JavaME SDK 3.0 Team: Get the other platforms done as well. PLEASE.
There's another gripe with the new tooling: I can't open my NB mobility projects in the SDK tooling, since the NB libraries for SVG and others aren't included in it. And there's no easy way to get those libraries in. Major bummer in my opinion, especially since the SDK 3.0 tooling supports for example the WURFL database. Which is nowhere to be found in NB 6.7 although the SDK 3.0 is included and supported as the default emulator, replacing the WTK.
While using the SDK I ran a couple of times in the issue that there wasn't enough memory for my MIDlet suite to be installed, although it installed nicely in the WTK 2.5.2 emulator. And there's no option to increase the size of the emulators heap.
But all in all, the new tooling is superb. Debugging is going a lot smoother now and especially the hot-deploy support is excellent. A real time saver. But ultimately nothing beats testing on an actual device, and the promise of better on-device-debugging support is great. Now we just need to get it working. In a usable fashion. So:
Nokia, Sony-Ericsson, Samsung, LG, HTC and all of you other vendors, please work on this. As long as you're putting in those nasty bugs in your JavaME implementation, we need to test on your devices. I'm okay in getting some different phones to test on, but help me out here as well.
Iwan
There's another gripe with the new tooling: I can't open my NB mobility projects in the SDK tooling, since the NB libraries for SVG and others aren't included in it. And there's no easy way to get those libraries in. Major bummer in my opinion, especially since the SDK 3.0 tooling supports for example the WURFL database. Which is nowhere to be found in NB 6.7 although the SDK 3.0 is included and supported as the default emulator, replacing the WTK.
While using the SDK I ran a couple of times in the issue that there wasn't enough memory for my MIDlet suite to be installed, although it installed nicely in the WTK 2.5.2 emulator. And there's no option to increase the size of the emulators heap.
But all in all, the new tooling is superb. Debugging is going a lot smoother now and especially the hot-deploy support is excellent. A real time saver. But ultimately nothing beats testing on an actual device, and the promise of better on-device-debugging support is great. Now we just need to get it working. In a usable fashion. So:
Nokia, Sony-Ericsson, Samsung, LG, HTC and all of you other vendors, please work on this. As long as you're putting in those nasty bugs in your JavaME implementation, we need to test on your devices. I'm okay in getting some different phones to test on, but help me out here as well.
Iwan
It's been a while, we're now at 6.7
Hi,
It's been a while since I've been posting about NetBeans, all kinds of reasons, but mainly because I just couldn't give blogging enough priority. But today I've got some spare minutes.
NetBeans has been growing tremendously since the last time I blogged about it, we're now at 6.7.
I think last time I was blogging about NetBeans I was working on a game, for mobiles. I should check my posts... anyway, what I can tell you is that other than previous experiences with new versions of NB, I've been able to open the project in new versions, even daily builds without experiencing major incompatibilities. Once or twice I wasn't able to also open the project in the old version again. This is of course a major achievement but more over, it makes testing NetBeans a better experience.
So what else are some highlights:
- When uninstalling, there now is an option to also uninstall the userdir. Excellent.
- UML support is about to be dropped, at least it's no longer maintained according the WIKI. Boooh
-The GF2.1 installation from previous versions of NB is no longer recognized and you'll be asked to install a new version. When not selecting to do so, NB does see your old installation and it all works. Confusing
- Woodstock is dropped (JSF components that at least look decent) and is (going to be) replaced by IceFaces. Mildly boooh.
Iwan
It's been a while since I've been posting about NetBeans, all kinds of reasons, but mainly because I just couldn't give blogging enough priority. But today I've got some spare minutes.
NetBeans has been growing tremendously since the last time I blogged about it, we're now at 6.7.
I think last time I was blogging about NetBeans I was working on a game, for mobiles. I should check my posts... anyway, what I can tell you is that other than previous experiences with new versions of NB, I've been able to open the project in new versions, even daily builds without experiencing major incompatibilities. Once or twice I wasn't able to also open the project in the old version again. This is of course a major achievement but more over, it makes testing NetBeans a better experience.
So what else are some highlights:
- When uninstalling, there now is an option to also uninstall the userdir. Excellent.
- UML support is about to be dropped, at least it's no longer maintained according the WIKI. Boooh
-The GF2.1 installation from previous versions of NB is no longer recognized and you'll be asked to install a new version. When not selecting to do so, NB does see your old installation and it all works. Confusing
- Woodstock is dropped (JSF components that at least look decent) and is (going to be) replaced by IceFaces. Mildly boooh.
Iwan
Wednesday, December 05, 2007
My NetBeans, has changed its appearance...
... and it has the same bright look and feel as the new NetBeans website. Which is fresh, but to be honest, I liked the other more darker look and feel with all its transitions better.
The home page title is set to HP, why? Probably it's short for 'Home Page'?
It all works better now and I was able to add a picture to my profile, which wasn't possible in the previous version, at least I got an error all the time I tried it.
There are some minor issues that need ironing out and some bigger issues that need to be fixed, but all in all it is a great website.
Still, seeing that my NetBeans Collaboration buddies are online (in NetBeans Collaboration) might be a great addition. Have them added as friends automatically would be fun. Something like Xbox Live.
I noticed that you can't remove friends anymore, or at least it is not very obvious how to do so. I have Lukas added twice as a friend, and I think once is sufficient. Free up some screen real-estate for other friends.
I guess I start filing some issues on the site and see it improve quickly to a really nice community website. Social NetBeaning.
Iwan
The home page title is set to HP, why? Probably it's short for 'Home Page'?
It all works better now and I was able to add a picture to my profile, which wasn't possible in the previous version, at least I got an error all the time I tried it.
There are some minor issues that need ironing out and some bigger issues that need to be fixed, but all in all it is a great website.
Still, seeing that my NetBeans Collaboration buddies are online (in NetBeans Collaboration) might be a great addition. Have them added as friends automatically would be fun. Something like Xbox Live.
I noticed that you can't remove friends anymore, or at least it is not very obvious how to do so. I have Lukas added twice as a friend, and I think once is sufficient. Free up some screen real-estate for other friends.
I guess I start filing some issues on the site and see it improve quickly to a really nice community website. Social NetBeaning.
Iwan
Tuesday, December 04, 2007
NB 6 was released, I almost went back to RC2... really.
Hi,
As you know, NetBeans 6 has been officially released yesterday, and as a true NetCAT member I was feeling rather proud because I was an active member of the team that used NB6 in it's final stages before going gold.
So I downloaded it and installed the real deal, and fired it up and rediscovered my JavaME emulators and opened my projects. And than it struck me, it was really the same thing. Not noticeably faster than RC2, not slower. Same colors everywhere. Just the same.
So I started up my project, deployment to Glassfish, the same instance I had used throughout the NetCAT period and guess what. Nothing happened but a big fat stacktrace in my OUTPUT window, in NetBeans. Referring me to the server logs, which didn't say anything more than that the app server was running fine. Yipes! That's not good.
Quickly firing up RC2 and trying the same thing, and it all ran fine. Double Yipes! That's really not good at all.
So I was thinking: Do I go back to Rc2 and work with that version, waiting for the first service pack, or uninstall everything, including Glassfish and Tomcat and reinstall NB6 and try it all again. I opted for the latter and fortunately, all is working fine now.
And guess what; it is really as good if not better than Rc2.
Iwan
As you know, NetBeans 6 has been officially released yesterday, and as a true NetCAT member I was feeling rather proud because I was an active member of the team that used NB6 in it's final stages before going gold.
So I downloaded it and installed the real deal, and fired it up and rediscovered my JavaME emulators and opened my projects. And than it struck me, it was really the same thing. Not noticeably faster than RC2, not slower. Same colors everywhere. Just the same.
So I started up my project, deployment to Glassfish, the same instance I had used throughout the NetCAT period and guess what. Nothing happened but a big fat stacktrace in my OUTPUT window, in NetBeans. Referring me to the server logs, which didn't say anything more than that the app server was running fine. Yipes! That's not good.
Quickly firing up RC2 and trying the same thing, and it all ran fine. Double Yipes! That's really not good at all.
So I was thinking: Do I go back to Rc2 and work with that version, waiting for the first service pack, or uninstall everything, including Glassfish and Tomcat and reinstall NB6 and try it all again. I opted for the latter and fortunately, all is working fine now.
And guess what; it is really as good if not better than Rc2.
Iwan
Friday, November 30, 2007
My NetBeans, or your NetBeans?
Hi,
Dit you already register on My.NetBeans.org? A new social networking site specifically for the NetBeans community (disclaimer: this is my own definition of the site, not reflecting anything officially stated). Anyway, I did register as soon as I got onto the site. It, by the way, looks really good. I like the fading effects.
The only thing I don't like at the moment is the fact that it doesn't log me in automatically. I keep on clicking links having to login first before it does something. But hey, it's only a beta.
I am missing the contact option to add my share.java.net collaboration account next to my Skype and MSN to be contacted. And than have it integrated with NB Collaboration to see who is developing in NetBeans while I am surfing. Something like Xbox Live integrated with MSN and Windows Media Center. But hey, it's only the first incarnation.
Anyway, it's a great addition to the NB universe and definitely worth my while... eventually I think.
Iwan
Dit you already register on My.NetBeans.org? A new social networking site specifically for the NetBeans community (disclaimer: this is my own definition of the site, not reflecting anything officially stated). Anyway, I did register as soon as I got onto the site. It, by the way, looks really good. I like the fading effects.
The only thing I don't like at the moment is the fact that it doesn't log me in automatically. I keep on clicking links having to login first before it does something. But hey, it's only a beta.
I am missing the contact option to add my share.java.net collaboration account next to my Skype and MSN to be contacted. And than have it integrated with NB Collaboration to see who is developing in NetBeans while I am surfing. Something like Xbox Live integrated with MSN and Windows Media Center. But hey, it's only the first incarnation.
Anyway, it's a great addition to the NB universe and definitely worth my while... eventually I think.
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
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
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 (
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
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
Monday, August 27, 2007
An anoying difference between NB 5.5.1 and NB 6.0
Hi,
It's been a while since I've blogged, and I won't say that'll change. I've made that promise too often without being able to live up to it. But enough about that.
Last week I reported a bug (113543) about that I couldn't use the visual designer for changing a persistence.xml file. There was a workaround; changing the file in XML view, so the P1 was set to a P2. As it turned out, the JPA provider class in NB5.5.1 had changed from oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider to oracle.toplink.essentials.PersistenceProvider and NB 6.0's visual designer for persistence.xml files couldn't handle this.
It was a really annoying bug, this difference between the NB versions. But changing the provider in the persistence.xml did solve the problem.
Iwan
It's been a while since I've blogged, and I won't say that'll change. I've made that promise too often without being able to live up to it. But enough about that.
Last week I reported a bug (113543) about that I couldn't use the visual designer for changing a persistence.xml file. There was a workaround; changing the file in XML view, so the P1 was set to a P2. As it turned out, the JPA provider class in NB5.5.1 had changed from oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider to oracle.toplink.essentials.PersistenceProvider and NB 6.0's visual designer for persistence.xml files couldn't handle this.
It was a really annoying bug, this difference between the NB versions. But changing the provider in the persistence.xml did solve the problem.
Iwan
Monday, July 09, 2007
I ditched NB6 M10 for NB5.5.1, because I'm developing some EE stuff on Glassfish.
Last Wednesday and Thursday I spend most of my time on rebuilding my NB5.5 project in NB6 M10. The reason for this was that I couldn't successfully open the 5.5 project in 6M10 and deploy it. Opening was possible, compiling was possible, but I couldn't deploy it. Note that I'm deploying to Glassfish v2b53 that comes with NB6M10 and is called in there Sun Application Server 9.
So what I did was creating a new Enterprise project in NB6, and create all SessionBeans, Entity classes, servlets and webservices with the exact same FQN's as I used in my original project. Then I built the application and deployed it, just to verify it was working. After that I copied over the sources from my original project and deployed that and that worked... well almost.
For one, the servlet I have used local interfaces and that resulted in a deployment error. Interestingly the error was also reported when deploying to other Glassfish based AppServers, although it worked in NB5.5.
So I replaced the local interfaces with the remote interfaces and that solved the issue. Then I ran into a WS issue, which I can't recall, but that was fixed after creating a new WS with an operation on it and build that version of the project.
The most annoying of this whole process is until now left unsaid. The most irritating of the whole exercise was that I created a brand new Enterprise project deployed it and than EJB by EJB, servlet by servlet, WS by WS . With every change I deployed the project again.
As long as this resulted in a deployed application, all was fine, but as soon as something went wrong I got either an error stating that the created archive was invalid, or that there were no EJB-refs in the project, or that a pool was not defined and therefore not available. This wasn't fixable, instead I had to stop the App Server, delete the projects from NetBeans, one by one because due to some issue, you can't delete the Enterprise project which consequently deletes the EJB- and WAR-projects.
And then it was a matter of recreating the initial empty project and start all over again. I found out that I could zip a working project, delete the project from NetBeans, delete the folder on my filesystem, recreate the empty project, deploy it and then unzip the zipped project and deploy that one. Mind that I had to deploy the empty project or else it wouldn't work.
So finally I had a completely working project containing all components of the original NB 5.5 project that deployed. But as soon as I would hit the servlet, it wouldn't work. The problem has something to do with WS calling EJB's. Perfect... NOT.
So Friday night I spend on doing this whole exercise in NB 5.5.1, adding the Glassfish v2b53 to the servers and recreate a new Enterprise project. And then I added the sources from the faulty NB 6 project. I was feeling brave and I just moved all files at once instead of going through this tedious exercise that kept me busy for two nights already.
And what do you know, it all works nicely. No errors and all deploys wonderfully on Glassfish v2b53. Best of all, the issues I blogged about previously on the subject of deploying and debugging are non-existing in this release of Glassfish.
The bad about this is that NB 6 is so much better with regard to the editor and everything that relates to it, that it is really unfortunate that I have to go back to NB 5.5.1. I will try to get a clear view on the whole issue and report the proper findings in Issuezilla sometime this week.
I don't have that much time the next few days, as I am helping out a friend of mine securing his laptop and tomorrow I'm going to see Transformers. So maybe Wednesday I get around to it.
Iwan
Last Wednesday and Thursday I spend most of my time on rebuilding my NB5.5 project in NB6 M10. The reason for this was that I couldn't successfully open the 5.5 project in 6M10 and deploy it. Opening was possible, compiling was possible, but I couldn't deploy it. Note that I'm deploying to Glassfish v2b53 that comes with NB6M10 and is called in there Sun Application Server 9.
So what I did was creating a new Enterprise project in NB6, and create all SessionBeans, Entity classes, servlets and webservices with the exact same FQN's as I used in my original project. Then I built the application and deployed it, just to verify it was working. After that I copied over the sources from my original project and deployed that and that worked... well almost.
For one, the servlet I have used local interfaces and that resulted in a deployment error. Interestingly the error was also reported when deploying to other Glassfish based AppServers, although it worked in NB5.5.
So I replaced the local interfaces with the remote interfaces and that solved the issue. Then I ran into a WS issue, which I can't recall, but that was fixed after creating a new WS with an operation on it and build that version of the project.
The most annoying of this whole process is until now left unsaid. The most irritating of the whole exercise was that I created a brand new Enterprise project deployed it and than EJB by EJB, servlet by servlet, WS by WS . With every change I deployed the project again.
As long as this resulted in a deployed application, all was fine, but as soon as something went wrong I got either an error stating that the created archive was invalid, or that there were no EJB-refs in the project, or that a pool was not defined and therefore not available. This wasn't fixable, instead I had to stop the App Server, delete the projects from NetBeans, one by one because due to some issue, you can't delete the Enterprise project which consequently deletes the EJB- and WAR-projects.
And then it was a matter of recreating the initial empty project and start all over again. I found out that I could zip a working project, delete the project from NetBeans, delete the folder on my filesystem, recreate the empty project, deploy it and then unzip the zipped project and deploy that one. Mind that I had to deploy the empty project or else it wouldn't work.
So finally I had a completely working project containing all components of the original NB 5.5 project that deployed. But as soon as I would hit the servlet, it wouldn't work. The problem has something to do with WS calling EJB's. Perfect... NOT.
So Friday night I spend on doing this whole exercise in NB 5.5.1, adding the Glassfish v2b53 to the servers and recreate a new Enterprise project. And then I added the sources from the faulty NB 6 project. I was feeling brave and I just moved all files at once instead of going through this tedious exercise that kept me busy for two nights already.
And what do you know, it all works nicely. No errors and all deploys wonderfully on Glassfish v2b53. Best of all, the issues I blogged about previously on the subject of deploying and debugging are non-existing in this release of Glassfish.
The bad about this is that NB 6 is so much better with regard to the editor and everything that relates to it, that it is really unfortunate that I have to go back to NB 5.5.1. I will try to get a clear view on the whole issue and report the proper findings in Issuezilla sometime this week.
I don't have that much time the next few days, as I am helping out a friend of mine securing his laptop and tomorrow I'm going to see Transformers. So maybe Wednesday I get around to it.
Iwan
Tuesday, July 03, 2007
Developing the JEE application, how tears disappeared from my eyes...
Hi,
It has been a while since I blogged, and that is mainly due to the fact that I didn't work on my project for quite a while. Why? Because I was too busy with all kinds of other stuff, like auditing an architecture for a start-up here in the Netherlands, setting up and implementing a QA process for a customer of mine and spending time in the UK on a JCAPS training and visiting JavaOne 07.
Between my last blog and now, I discovered some interesting things about NetBeans. I was using NB5 for my development until I installed NB6 M9 (got it on NetBeans Day 07 on a memory stick) and since the editor in NB6 is soooo much better than in NB5 that became my preferred IDE. Note that before I used M8 which was fairly stable, but the Java EE 5 support in M8 was not that good. So I used NB5 for JavaEE 5 code generation etc and NB6 for editing.
What was interesting was that my projects would only build in the IDE I started last. NB ammends the build files as it seems to reflect the changes of the new release. This took about an hour to register.
Last week I downloaded Glassfish v2b51 and configured NetBeans to use it. And all issues I had with Sun AS and Glassfish that I blogged about previously about not being able to debug my enterprise app disappeared. I can now succesfully start and restart my app in debug mode. Not that I am able to debug my application, since for some reason the datasources I need to connect to are not defined in Glassfish. But that's probably a problem in the build files or something. I noticed after a file-compare that my build files originating from NB5 are fairly different from the files that NB6 would generate. So I think I'll just create a new project and put my sources there. I'll keep you posted.
So for now: Use the latest version of Glassfish, I'm using v2b51. That should help.
Iwan
It has been a while since I blogged, and that is mainly due to the fact that I didn't work on my project for quite a while. Why? Because I was too busy with all kinds of other stuff, like auditing an architecture for a start-up here in the Netherlands, setting up and implementing a QA process for a customer of mine and spending time in the UK on a JCAPS training and visiting JavaOne 07.
Between my last blog and now, I discovered some interesting things about NetBeans. I was using NB5 for my development until I installed NB6 M9 (got it on NetBeans Day 07 on a memory stick) and since the editor in NB6 is soooo much better than in NB5 that became my preferred IDE. Note that before I used M8 which was fairly stable, but the Java EE 5 support in M8 was not that good. So I used NB5 for JavaEE 5 code generation etc and NB6 for editing.
What was interesting was that my projects would only build in the IDE I started last. NB ammends the build files as it seems to reflect the changes of the new release. This took about an hour to register.
Last week I downloaded Glassfish v2b51 and configured NetBeans to use it. And all issues I had with Sun AS and Glassfish that I blogged about previously about not being able to debug my enterprise app disappeared. I can now succesfully start and restart my app in debug mode. Not that I am able to debug my application, since for some reason the datasources I need to connect to are not defined in Glassfish. But that's probably a problem in the build files or something. I noticed after a file-compare that my build files originating from NB5 are fairly different from the files that NB6 would generate. So I think I'll just create a new project and put my sources there. I'll keep you posted.
So for now: Use the latest version of Glassfish, I'm using v2b51. That should help.
Iwan
Subscribe to:
Posts (Atom)