Eclipse will not build from source on PowerPC Linux

Back in June of this year when I made my last attempt to use Debian GNU/Linux as my primary operating system, I was unable to build Eclipse 3.0 Release Candidate 3 from source, even though it's specified as a supported platform. Alas, it seems the problem has persisted. Eclipse Bug #57897 shows that folks are still having trouble with this. My experience this weekend confirms it.

I suppose this is an opportunity to help out and get involved with Eclipse. Once my Linux install is a bit more settled in, I will look into it.

Migration to Debian Linux as primary OS, phase 1

Well, so far I have my old Titanium PowerBook G4 500MHz running with Debian GNU/Linux with 802.11b wireless working in place, Thunderbird for email, and Firebird for a browser. OpenOffice installs and runs like a dream, so the major office apps are in place as well. This migration coupled with my current workload and its associated study have been a handful. That stinks, too, because there have been several things I would like to write about. Choices, choices...

One big step is going to be getting the Bluetooth GPRS working. I would predict that it is going to eat up some time.

Cover me, I'm going back in

Well, I have decided to get back into Linux. The difference this time is that I am going to be doing it on my first PowerBook, the old Titanium PowerBook G4 500MHz. After watching Revolution OS a few times, I guess I am fired up, like

when short white guys watch Rocky movies. Hopefully my enthusiasm is not as ill-placed as theirs.

That being said, I will most likely be scarce on this thing for a while. More to come.

Rethinking Linux versus FreeBSD

Bruce Perens said something in Revolution OS that I had not thought of before. It has to do with the GPL versus the BSD license. He talks about how that the GPL is a partnership license, whereas the BSD license is not a partnership license. He goes on to say the BSD license (and the MIT license by extension) were created at universities through the funding of U.S. government grant programs and industry consortia.

Huh. I think that is probably a pretty accurate observation, and it's a bit unsettling.

Persevering through technical issues

I just wrapped up a painful 4-hour lesson is self-discipline. While working through James Holmes' Struts The Complete Reference, I found that my ActionErrors collection did not seem to be getting passed back to the JSP view was supposed to render them. I spent hours debugging in Eclipse, attaching the Struts source code to the project so I could see just what was going on. (Isn't it funny how after you have been frustrated by a problem for a while you begin to wonder if it's the framework/language/operating system? Blame-shifting is a funny thing.)

After I could not figure out the problem for a couple of hours, I decided to download the sample code from the website for the book. Sure enough, once I had James' code in an Eclipse project, it ran fine. I even opened all related source files and did a line-by-line comparison of the code to ensure that I hadn't mis-coded anything.

It ended up that I had wrongly placed an exclusion filter on my source folder to not place any *.properties files into the build folder. Since my initial properites file had the form labels, it would run, but there were no error messages for it to display, even though I had added them - to the copy of the file in the source folder. Egad! As soon as I rectified that, all was right. It took forever to figure out what I had done wrong, but I doubt I will repeat that mistake anytime soon.

That sort of time-devouring learning experience is part of the price for mastering a technology. Until you have gotten your hands dirty and really screwed up and had to recover from it, you can only know so much. The books seldom cover all the mistakes outside the code that you can make.

The Pragmatic Programmer series talks about technical debt, a concept that the technical issues you don't resolve never really go away. Rather, they accrete into an ugly mess that you will eventually have to face. Establishing that discipline starts small. When you hit a snag, work through it. Struggle with it. Don't fag out (that is not a homosexual reference, for those who just executed that sharp intake of breath); work the problem.

Mailing lists for various technologies get peppered every day with folks who don't want to work through issues. They would rather flail their arms and post messages with subject lines like "URGENT HELP NEDED - PLS RESPOND!!!" or "SOMEONe HELP PLEASE!" that offer little to no insight on the problems they face than wrestle with what is most likely their own careless error. As one who makes those errors regularly, I can say that the majority of the time, it's not the language, it's not the server, it's not the tool - it's probably you.

Don't give up; push through to a solution. Sure, you may need help. Try it on your own first, with a good reference or even TFM. You'll grow from it.

I think this post primarily serves to help me not feel like my evening was a total loss. 8^)

The Spring's Source

As I have begun checking up on Spring, it has been interesting to trace its origin. I have ended up learning that Rod Johnson is a driving force of Spring. His book Expert One-on-One J2EE Design and Development has a first chapter that was revolutionary for me in terms of laying out the realities of J2EE and EJB development. That writing was a real light bulb for many of the folks in the AJUG SCEA study group that I participated in over the past several months.

My interest was piqued when I saw another book by Rod Johnson with a title almost identical to the other book, Expert One-on-One J2EE Development without EJB. I mean, that pretty much lays it out there, huh? When the topic of not using part of a platform merits a book by the same author who has a not-so-old title on the platform at large, that's something to look into. Finding out that Rod is behind Spring bolstered my resolve to give it a go.

Once my shipment from Amazon arrives, I will have all three of the books for Spring that are referenced on the project website. I am willing to bet that this framework and others like Hibernate will become disruptive in the J2EE circles. And quite honestly, until Enterprise Java Beans gets its overhaul that we are all hoping for in the 3.0 specification, we need some disruption.

The Spring framework; hope for the J2EE developer

At the AJUG meeting tonight, Mark Eagle presented the Spring framework for J2EE application development. Mark has a recent O'Reilly article titled Wiring Your Web Application with Open Source Java that covers usage of Spring in Java web applications. The presentation was based on the article, and was quite thorough. It was a great presentation, and it cemented my desire to use it for the business logic tier of my current work project.

I am going to check out the Bruce Tate articles on Spring that are based on his upcoming O'Reilly book with Justin Gehtland titled Better, Faster, Lighter Java. He had mentioned Spring along with Hibernate in a blog post of his on java.net back in June.

For those who want a viable alternative to Enterprise Java Beans, this could be your ticket.

Vegetarianism and Desktop Linux

After another foray into desktop Linux, I am back to OS X. I have burned 18 hours this week just getting my email to work at a mediocre level without junk mail filtering and failing to get Bluetooth GPRS working on a Linux 2.6.7 kernel that seems to be all set to go for Bluetooth. I was searching for some resource links for a guy when I came upon an entry in Jeremy Zawodny's weblog entry titled "I'm sick of doing things the hard way".

Yeah, me too. I am sick of it after only a couple of weeks.

You know, alpha geek tendencies toward doing hard things even when they are unpractical reminds of some of my vegetarian friends. When I first moved into the city, I found that lots of the new people I met were vegetarians. At first I thought this must be something with a really great health benefit. So I asked them, but most of them said that they have to eat things to supplement the protein they do not get by eating meat. Some also informed me that their diet starves their bodies of other key things that it needs like amino acids, etc. So, they have all these quite convoluted ways to supplement the very thing they are abstaining from, with no direct benefit.

Desktop Linux is alot like that, especially when you are running on a hardware platform other than x86. If you don't believe me, browse on over to the Debian PowerPC port mailing list archives. Mac OS X does everything I need in open source development, and most of what I need for Java development except WebSphere. And, like Zawodny says, it "just works". Do not underestimate the value of an operating system that is powerful, highly open source friendly, and does what it is supposed to do.

Moving past the scars in Linux migration

There have been several points where I tried to move to Linux as my primary operating system. Once was in the Spring of 2001 when I bought my first PowerBook and Mac OS X was not out yet. Those were some of the early days for PowerPC Linux; nightmares with the XFree86 installation finally led me to give up. During a season of great frustration with my Mac hardware and agreeing to try and get on the .Net bandwagon and be happy about it, I had purchased a PC laptop in January 2002. By Spring I had begun to try dual-booting and running RedHat Linux. Things started well; I had actually moved to Ximian evolution as my primary email client, etc. One day my Red Carpet package manager really messed up some library dependencies and I spent several days trying to back out of the problem. It got to where Mozilla and Evolution would either crash or not come up at all, then my menus started getting all wacko. I bailed.

By that time, OS X had made great strides. MySQL and PHP could be compiled from source without any special gymnastics, and each revision of OS X became more Unix-savvy, right down to the choice of default shell (bash instead of tcsh; it felt good to finally have a shell that agreed with most code samples found on the Internet) with the advent of Panther. And that was great for a while, but the call of Linux still tugged at me.

And now here I am, once again at the point where I have turned back in the past. Overall my Debian experience has been vastly superior to the distributions I used in the past. However, some library dependency has got my current Mozilla and Evolution installs freaked out. I am also unable to get my Bluetooth adapter working with my current kernel. I have also been having so XFree86 wierdness that is tenuous but livable. These types of issues have always been the point where there was enough pain to make me turn back. Yet, I always return to try again.

What will this time bring? Will I persevere and pass these obstacles, or will I once again flee for the safe cover of a proprietary operating system? Time will tell.

For the record, I don't really like that phrase. It's unnecessary. Doesn't time always tell? It's not like there is an alternative.