This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
When I was first testing the j2me support I found it pretty broken and had to give up for few days before I found out that the problem was partially in user flow - certain sequence of simple and natural actions leads into unhealthy state of the j2me project and it took me a lot of digging in the project.properties and build files to find out what went wrong. 1. start with sample project It is excelent that one can generate working midlet and immediatelly get something running. That is the way I started as well. I generated application hello.Hello, I've been able to run, debug, change few things, etc. 2. refactor it into serious project I liked what I had, so I decided to turn this into real application. I moved the hello.Hello class into some real package - cz.jtulach.RecordTV and everything seemed to work fine. I could run and debug program. I did few modifications and still ok, but after the set of modifications started to grow I found out that the debugger is broken. Some breakpoints were not reached and line numbers were incorrect. Even stranger, when I changed the UI, my changes were not visible. 3. do clean build I gave up, but after few days I returned back and promised myself to resolve the problem. I did clean build, but the situation got even worse. I could not debug at all. The IDE was yelling at me that the debugger cannot be even started. I gave up once again. 4. the fix After another week I decided to look at the build scripts and finally found out what was wrong. The main class of my project was still hello.Hello. So in the phase #2 I was running already existing class files and none of my changes could affect the application. Breakpoints worked (probably) due to the fact that Line objects refered to new data object - they keep identity. The failures in #3 after the clean build were simply due to the fact that the main class did not exist, however the warning message is too obscure to help me to realize that (definitively different than in j2se project). I am not writing the report to let you laugh to me, but because it shows how a typical sequence of actions - new project and refactor - can lead to completely broken user experience. Btw. this happened to me on the version release with beta1, many things can be better now - I am not going to try, as I have already fixed my project by hand.
It seems as another voice to support "force rebuild" in some situations, I mean in certain situation, the IDE should rebuild even if user only invokes build, or at least display a warning.
Yardo, I've several question about the build process. How it is working for J2SE (or J2EE) and how it should be working: - should be the "clean" forced after any change (rename, delete, move ...) ? - is the j2se main class refernce following the refactoring (rename, move, delete) ? I've already implemented in trunk that J2MEDataObject overrides handleDelete, handleMove, handleRename to forward the changes to the project properties holding the application descriptor. I am considering to clean before every build because of: - reflect changes in the project.properties or private.properties or build.xml or build-impl.xml (this is already handled now) - reflect changes in sources (deletes, renames, moves) - reflect the request for debugging when the project was already built with enabled obfuscation Do you think I should handle all these cases separatelly by some status properties and up-to-date checks or just simply hardcode the "clean" before "build" ?
According to tzezula j2se project listens on OperationListener and updates main class. If this worked in j2me, most of my story would not even happen. According to phrebejk, if the main class is not set or does not exist the j2se project shows a dialog to customize it. That would prevent those ugly messages I saw when I tried to start the debugging. That is what I see from my user point of view. Re. cleaning - I do not know. It would not help in my case, I am affraid.
Now we are listening for changes on any MIDlet and mirroring the changes in the application descriptor - this should solve the most problematic part of this issue. But still wondering if and how to force clean after any rename/move inside project. Please re-open this bug if the problems remain.
verifying all old issues