Archive for June 2007
My first official self-commit to an open source project.
I’ve just checked in my GWTJSF patches to the Ajax4JSF trunk. You can now get the GWT 1.4-compliant GWTJSF project by following these directions.
No word yet from the Exadel guys; I’m 99% sure I didn’t break anything but they’ll tell me if I did, they’re not shy :-) I do hope they will update their labs.jboss.org documentation to mention this project again, now that it actually builds in their tree. We’ll see.
I included a reference to the googlecode repository in the gwtjsf pom.xml, so it should have no problems pulling GWT 1.4.10 (which it needs).
The old GWTJSF examples (which are not on labs.jboss.org anyway yet) no longer work, mainly because the Maven build (as my last post discussed) splits the sources into a separate jar, so the old build files break. I’ll likely land at least one of my modified samples in the Ajax4JSF tree in the next couple of days, so people will have a reference point.
After that I’ll get back to finalizing my Seam/GWT example and submitting that to the Seam project. Hopefully in another week, or two at the most, I’ll have this whole thing wrapped up and then I can get back to the Gears/GWT offline Blogger editor project!
Nothing like using something for yourself to clue you in to the buzz around it.
The buzz around Maven 2 is pretty negative. And now I’m seeing why. As my last post mentioned, I’m working on fixing the Maven build in the GWTJSF source tree. (Right now that source doesn’t build at all.)
I got the basic Maven compile working. Spent tonight on trying to get the tests working. Finally gave up when it turned out there were two critical problems:
- The GWTShell doesn’t like the Maven classloading pattern. Charlie Collins has a patch for this but it didn’t make it into GWT 1.4.
- Running GWTShell requires access to the OS-specific GWT native libraries. The current means for doing that is with system dependencies in Maven, e.g. download the appropriate GWT version and point your Maven POM at it. This is totally contrary to the entire point of Maven, which is supposed to download everything for you. Will Pugh is working on GWT-Maven support for downloading the whole native GWT archive and expanding it locally, but it’s not done yet.
So, fine, I gave up on getting the tests to run. Now I just want to verify that I actually have a working .jar file.
Turns out that I don’t, because the GWT compiler needs not just the .class files but also the .java files to be in the gwtjsf.jar file. The original Ant build for the GWTJSF project had no problem doing this, it was totally obvious and trivial how to do it. So, it should be trivial in Maven 2, right?
I found the plugin documentation page for Maven 2. This led to the documentation page for the jar plugin. Hmm, pretty sparse. How about the usage examples? Nope, nothing there about what the actual configuration options are, just some examples of signing (which isn’t at all what I want to do). But look! At the top, it says this:
If you want to use advanced configurations you should have a look at the Javadocs for MavenArchiveConfiguration.
Oh joy! But wait. If you click on that link, what do you get? You get a page titled “Maven – Page Not Found”, which amusingly enough includes a tag saying “Built by Maven”.
That’s what I call bad — when your own javadocs for your automated build tool have automatically generated broken links!
It turns out that I missed a plugin that was actually already in the POM for the project, namely the maven-source-plugin. This generates a separate JAR file containing the sources for the project. That’s not what I want — I want the JAR file to contain both the sources and the classes — but it seems to be the best I can get Maven to give me.
Overall, it really seems that Maven has an incredibly fragmented configuration model, plugins with very, very specific functionality that is hard to override, and documentation that is scattered and broken. Sigh. Oh well, once I land this I’ll do my best to be done with it. Here’s hoping the Maven team can fix some of this.
Edit: I will say that I like what Maven is trying to do. This POM Reference makes a lot of sense… having a higher-level description of your project is not a bad concept. But the execution and the documentation are fraught with peril.
Many people love Perforce. That includes me.
What a lot of people don’t realize, though, is that if you are an individual programmer working on your own personal projects, Perforce is free.
See, you can download the latest release of Perforce and use it in an evaluation mode, where it’s limited to two users and two clients.
If you’re only using it to maintain your own local changes to one or more open source projects (say, GWT and Ajax4JSF and Seam), then that’s all you need. There’s no limit on the number of files or branches, and all Perforce features are 100% functional.
Right now on my Windows PC, I’ve got a Perforce depot which has:
– a complete download of the GWT Subversion tree
– a complete branch of that GWT tree, with my changes in it
– a complete download of the Ajax4JSF Subversion tree
– a complete branch of THAT Ajax4JSF tree, with my changes in it
– a copy of the Seam booking example
– a branch of the Seam booking example, with my changes in it
Setting my Windows Perforce client to use Unix line endings means that Perforce doesn’t screw up the Subversion metadata.
The workflow is:
– check out from Subversion
– check in to Perforce
– branch in Perforce
– edit like mad in the branch, committing at will
– once done, integrate back to the Subversion copy
– check out the whole Subversion copy for edit
– svn update, svn patch, svn commit
– revert unchanged files in Perforce
– re-commit to Perforce
The truly wonderful part is that I can take changes from the Subversion copy to my dev branch, or vice versa, as circumstances warrant. Basically, it’s the full power of Perforce branching, used to manage my personal development alongside the concurrent development of everyone who’s landing in Subversion.
I can’t recommend it too highly. Totally brain-saving compared to keeping multiple local Subversion working copies or whatever. Try it, you might love it.
As aforementioned here, I’ve spent a good chunk of this year integrating GWT, JSF, and Seam. The current fruits of that labor are here.
The original GWT-JSF integration was done by the Ajax4JSF guys. The code is hosted in the JBoss Ajax4JSF Subversion repository. The main problem is that they’ve converted the entire repository to use Maven, except for the GWT-JSF code.
So I’m fixing that. This post documents how. I’m going to try your patience by giving the blow-by-blow in real-time as I work on this. Consider this an object lesson in how to bang your head against a brick wall with MAVEN spray-painted on it.
First, get the Ajax4JSF code building with Maven, by following these directions from the Ajax4JSF guys.
Second, integrate a pointer to the GWT-Maven repository, along the lines of these instructions from the GWT-Maven team. Specifically:
– Add the gwt-maven repository to conf/settings.xml:
<!-- add gwt-maven repository -->
– Update the GWT dependencies in the main project POM to 1.4.10.
to the gwt-user dependency, to keep it out of the WAR file. (gwt-user.jar is only for compile time; gwt-servlet.jar is all you need in your deployed GWT webapp.)
Why can’t the gwt-maven repository live just inside the GWT-JSF POM? In fact, why don’t ALL the necessary repository definitions just live inside the top-level trunk POM for Ajax4JSF?
Third, run “mvn install” in the ajax4jsf/trunk/gwtjsf directory. See it blow up because it can’t find the 2.0 version of jsp-api.jar.
Wonder why this is, since the top-level trunk build has no problem finding it. Flail around adding a <profile> to the POM and watch it die in all kinds of other interesting ways. Back that change out again. Realize that you really have no idea how Maven works. Look at the base dependencies again…
… Turns out to be because the gwtjsf POM has the wrong groupId for jsp-api — it should be javax.servlet.jsp but it was just javax.servlet.
And with that, the frickin’ thing compiles! That’s progress :-D
What’s more, it’s almost 1 AM and my baby daughter wakes up at 6:30 AM. (Get used to me saying that.) But hey, something works now that didn’t work when I sat down here tonight. That’s what hacking is all about: getting something new working. Get enough new things working, and anything’s possible.
Time to commit all this to Perforce (see my next post) and then off to bed. Next hack night probably on Saturday, or if not, next Monday. Hopefully I’ll be able to land this sucker, and then maybe even land my actual changes to the project! What a concept!
Well, Rob Hanson is as good as his word, and has a draft GWT ORM for Gears implemented. Meanwhile, the GWT Maven guys have put the latest GWT 1.4 RC into their Maven repository.
And me… well, I’ve been busy with the grandparents :-) Gonna get cracking again this weekend.
Sorry for the hiatus of the last few days. My parents are in town and there’s been lots of grandparental fun, and I’ve also been kind of blocked on posting here.
I’ve been in a quandary about this blog, which is that I have too many topics I want to blog about, and not all of them are actually software-related. Should a blog titled robjsoftware.org have posts about religion, or family, or whatever else I might want to say that isn’t really code-related?
After getting a lot of advice from various people (thanks Bill Harris, Francis Potter, Bob Lee, and my father Norman), I decided that no, it shouldn’t. Part of blogging is developing an audience, and I’m not (quite) egocentric enough to think that everyone who’s interested in my programming posts will share all my other interests. I’d rather have opt-in than opt-out, in other words.
So I’ve started another blog — blog.robjthoughts.org. That’s where all the non-software topics will go. I’ll occasionally crosspost, but it’ll be very much the exception. I’ve also cleaned up the labels on this blog to avoid the weirdness of a “non-software” label on a blog named “robjsoftware” :-)
Thanks for your patience. Now that my definitional issues are sorted, content will resume flowing shortly. (And I promise I’m done making new blogs now!)
Mark Pilgrim rants quite cogently about the evils of Flex, Apollo, and Silverlight.
I admit it. We’re using Flex at my day job. We need to build a whole huge pile of rich client interfaces to our existing production system. And you know what? Flex simply has the best designer tools of anything we’ve looked at. We’ve got some great designers who are able to build interfaces in Flex that have real navigation and real interaction behind them, without needing more than a few smatterings of Actionscript. Flex Builder is just a good tool for building interactive UIs. Then the developers take those designer prototypes and refactor them into the actual application.
Designer-developer roundtripping is what Adobe calls it, and it’s just not currently doable in the “web that works.”
None of that has anything to do with the things Pilgrim is ranting about, and yes, proprietary is bad. I think Pilgrim missed that Flex, which Apollo is based on, is open source now. Not sure how effective or real that is, but it is technically true. And, of course, my company is building intranet apps, with only limited customer exposure, which is pretty much the ideal case for Flex right now.
Anyway, there’s my stake in the ground: I’m not religious about open source, and I’m willing to use closed source tools when they’ve got compelling advantages. (But in my spare time, it’s open source all the way!)
Also, so Pilgrim can laugh at me: how in the world do you subscribe to his RSS / Atom feed? I CAN’T FIND IT ON HIS SITE. Which means I must clearly be very dumb in some really basic way.