Things were going so well... I had created a Java Desktop application, got a desktop pane going, a dialog and an internal pane. It was now time to take a step back, refactor a little and etc.
I renamed my project, created a project group and BOOM! No more code. After a day or so reading about various frameworks, etc. and figuring out NetBeans 6.1 I got the program running in about an afternoon. Now I have nothing.
And now I have to Join Netbeans.org to post a message about this. Forget about it! My joining wiki.netbeans.org apparently wasn't good enough. My subscription to nbannounce was not good enough. FUGGET ABOUTIT!
The GUI builder was fairly good - but I'm going back to IntelliJ.
Tuesday, May 6, 2008
Tuesday, November 6, 2007
Frustrating: GWT InvocationException
I am having some success with GWT - but here's one that took me a couple hours to figure out. I created an asynchronous RPC service. Pretty much straight from the "book". Wouldn't work - wouldn't work. Tore everything back to the bare bones. (OK - the service was taking a user-defined class as an argument and returning a list.) I changed it to take a String and return a String. Still always got the InvocationException - with no cause. Finally also ripped the RemoteServiceServlet back to the basics -- did I mention I implemented the init and service methods to allow setting up other stuff I needed? Lo and behold it started working! Doh!
In the simple minded version I originally wrote it wasn't going to actually service anything, just initialize. By calling super.service(request, response) things went much better. Sometimes it IS just the simple problems.
In the simple minded version I originally wrote it wasn't going to actually service anything, just initialize. By calling super.service(request, response) things went much better. Sometimes it IS just the simple problems.
Interesting: IntelliJ
My IDE travels have taken me back to IntelliJ for a tour with the EAP version of IntelliJ 7.0. So far - very nice! Great Maven integration. Great GWT integration! Only locked up on me once - I had three projects open and went to debug one of them.
Monday, November 5, 2007
Frustrating: Java on Mac OSX
As you probably know, Leopard came out recently. Lots of us have been waiting to upgrade. But it turns out that one of the things *NOT* coming in Leopard is Java 6! Java 6 has been out for other platforms for quite a while. Apple used to be way behind, then caught up, but now is dropping behind again! I got a note from another news group that there is a grass-roots movement going on to demonstrate to Apple that there is a LOT of interest in this. It is in that spirit that I post this secret message to Apple: 13949712720901ForOSX.
Thursday, November 1, 2007
More Frustrating: Eclipse
Why does a "Dynamic Web Project" require javax.persistence? And it seems, therefore can't be deployed to the HTTP Preview (which is Jetty under the covers, right?)? And what is different between HTTP Preview and HTTP Server?
Only two facets are defined on the project: "Dynamic Web Project" and "Java", neither of which it will let me remove. I really *don't * want persistence...
Only two facets are defined on the project: "Dynamic Web Project" and "Java", neither of which it will let me remove. I really *don't * want persistence...
Interesting: Why's (Poignant) Guide to Ruby
If you're interested in languages, learning languages, or Ruby - you have to check this out.
http://www.poignantguide.net/ruby/
http://www.poignantguide.net/ruby/
Frustrating: Subversion / Interesting: Bash
So in the process of messing around with IDEs, I used NetBeans (most likely) to check out my project from Subversion. No problem - I edit my code, actually get my JSP page to work. Let me check it in and deploy! We're sorry - you can't check that in - Permission Denied. We're using svn+ssh protocol and the remote user is wrong - it is my local userid which is not the remote userid. Ok, how could that happen? And what to do?
Turns out the URL is stored in .svn/entries - just have to edit it. Sed to the rescue.
> find . -name entries -exec sed /host/s//user@host/ {} > {} \;
Ran fine - no change. All 'entries' files are read-only.
> find . -name entries -exec chmod u+w {} \;
Re-run sed. No change. Redirect is going somewhere else. Seem the second brace pair is not replaced with the file name. So put the sed command into a script. ~/bin/runsed.sh:
sed /host/s//user@host/ $1 > $1
Ok, let me try this on one file...
> ~/bin/runsed.sh src/main/java/.svn/entries
> ls -l src/main/java/.svn/entries
rw-r--r-- 0 entries
Zero!?? Oops. Change runsed.sh:
sed /host/s//user@host/ $1 > $1.fix
Re-run fine:
> find . -name entries -exec ~/bin/runsed.sh {} \;
Now I just have all these entries.fix files. Let's get rid of the old ones:
> find . -name entries -exec rm -f {} \;
Hmm... now if the curly braces only expand once, we're going to need a new bash script... And I recall there's a bunch of clever stuff bash will do with variables and file names... oh - here it is: "${1%\.fix}" will get rid of that...
~/bin/mvname.sh:
mv $1 ${1%\.fix}
> find . -name entries.fix -exec ~/bin/mvname.sh {} \;
Put them back to r/o:
> find . -name entries -exec chmod u-w {} \;
Done! Subversion now works again! Phew.
Turns out the URL is stored in .svn/entries - just have to edit it. Sed to the rescue.
> find . -name entries -exec sed /host/s//user@host/ {} > {} \;
Ran fine - no change. All 'entries' files are read-only.
> find . -name entries -exec chmod u+w {} \;
Re-run sed. No change. Redirect is going somewhere else. Seem the second brace pair is not replaced with the file name. So put the sed command into a script. ~/bin/runsed.sh:
sed /host/s//user@host/ $1 > $1
Ok, let me try this on one file...
> ~/bin/runsed.sh src/main/java/.svn/entries
> ls -l src/main/java/.svn/entries
rw-r--r-- 0 entries
Zero!?? Oops. Change runsed.sh:
sed /host/s//user@host/ $1 > $1.fix
Re-run fine:
> find . -name entries -exec ~/bin/runsed.sh {} \;
Now I just have all these entries.fix files. Let's get rid of the old ones:
> find . -name entries -exec rm -f {} \;
Hmm... now if the curly braces only expand once, we're going to need a new bash script... And I recall there's a bunch of clever stuff bash will do with variables and file names... oh - here it is: "${1%\.fix}" will get rid of that...
~/bin/mvname.sh:
mv $1 ${1%\.fix}
> find . -name entries.fix -exec ~/bin/mvname.sh {} \;
Put them back to r/o:
> find . -name entries -exec chmod u-w {} \;
Done! Subversion now works again! Phew.
Subscribe to:
Posts (Atom)