Hands-free Flyway and jOOQ
Recently, I started working on a new project and I wanted to give Jooq a go. I also wanted to integrate Flyway: I wanted jOOQ to generate its various classes based off the database schema, and I want to Flyway to create that schema. That’s all easy enough, but I’m resisting, right now, committing the generated classes to source control (to avoid the churn and additional maintenance), so how do I make that happen with as little work as possible? How do I make it work in a CI environment? Thanks to Maven, the answer is lots and lots of XML. :) Let’s take a look…
Custom Maven Packaging Type
As I’ve noted in a previous post, I recently moved my blog from Awestruct to JBake. This also allowed me to migrate the building and publishing of the blog contents to the toolchain that I know pretty well (Maven). What bothered me, though, was that my POM defined the project as a
jarpackaging type: the build produces no jar file and, in fact, doesn’t process any Java at all. What I wanted, then, was to be able to define the lifecycle in such a way the the
compilephase didn’t try to compile anything, and the
installphase didn’t try to put anything in my local repo. Unfortunately, either I’m a bit dense, or the documentation wasn’t very clear (it’s likely a combination of both :). At any rate, I finally had a eureka moment late last night and figured it out. Here is a distillation of my findings.
JavaFX and Maven
I’ve been tinkering with a couple of different JavaFX projects for a while now. Due to other commitments, they’ve been largely ignored recently, but I made some time this weekend to return to them. Since I last looked at them, Java 8, and, thus, JavaFX 8, have been release, so I decided to see how the tooling in NetBeans has changed to stay apace with the development of the libraries. While there are certainly updates, it seems new projects are still built using Ant. Yuck. :P I knew Adam Bien had a Maven archetype for his igniter.fx project, so I took a look to see what that POM does to support JavaFX. As it turns out, it’s pretty simple. For those interested, I have extracted here the basic POM:
Import Maven Artifacts to Ceylon Repos
In trying to come up to speed on Ceylon, I’ve run into some issues with module import dependencies. I’m pretty sure they’re all pilot error, but it was suggested that I import the jars into the Ceylon repository and specify the dependencies between the modules. This would, effectively, be functionally the same as the
<dependencies>element in the Maven POM. In classic geek, over-engineer-the-solution fashion, I cobbled together this shell script. It could be more elegant, but it seems to work, and it was much simpler than a Java implementation using the Maven APIs. :)
Testing Android Applications with Maven, Android-x86 and VirtualBox
For a few months now, I’ve been working on a small application called Cub Tracker which is designed to help Cub Scout den and pack leaders track the progress of the scouts assigned them. I’m a big fan of testing, so I’ve done my best to follow TDD as I’ve worked on the app. Early on, it became clear that I needed a better way to test, as the official Android app is slow and unreliable at times. Via Twitter, I was turned on to Android-x86 and after a couple nights of hacking, I think I have a usable installation of Android-x86 under VirtualBox that has sped up my testing considerably. In this article, I’ll show you how I did it.
Mojarra 1.2_15 Now In Maven Repo
Way back in July, Ed Burns released and announced Mojarra 1.2_15, which is mostly a backport of performance fixes from the 2.0 branch. Given recent changes on the Mojarra team1, there was some confusion and difficulty getting the jars published to the java.net Maven repository. I’m happy to report, though, that we’ve gotten those kinks worked out, and that this new release of the 1.2 branch of Mojarra is now available for your Mavenized pleasure. Note that this is the Maven 1 repository, and it’s not in central. Those are separate issues on which we’re still working.
1 Many, many thanks to you, Ryan, for all of your hard work over the years, and best of luck in your new position. :)
The Maven Release Plugin Is Pretty Slick
Maven catches a lot of flak from a lot of people. I’ve even been known to bemoan some its eccentricities from time to time. Over the past year and a half, though, I’ve done more and more with Maven, and I’m to the point now where that’s all I use. In fact, Maven and Ant have traded positions in my praise and scorn playbook. At any rate, in releasing FacesTester 0.1 yesterday, I was shown how to use the release plugin (which, by the way, has no parallel in Ant-space that I can see). This plugin helps in releasing a version of a project, updating all the version numbers as appropriate. Here’s a rough blow-by-blow of what happened:
Maven and Annotations: Not as Easy as It Should Be
Over the past year or so, I’ve been slowly migrating — somewhat accidentally — to Maven. I had even begun migrating the build environment for Scales from Ant to Maven, but hit a huge roadblock: annotation processing. Scales depends heavily on compile-time annotation processing, and the only thing I could find on the web was other people with the same problem. As I was working on some of my JSFOne examples, I really wanted to use Maven, as the NetBeans support is a lot cleaner with Maven versus an externally maintained Ant build file, so I set to with renewed purpose. Finally, I seem to have found the right query string, as I appear to have solved my problem. The solution? Ant.
A Seam+JPA/Hibernate on OC4J Maven 2 Archetype
As a follow-up to my entry on getting a Seam and JPA/Hibernate application running on OC4J, I now have an alpha release of a Maven 2 archetype available for use and testing, with heavy emphasis on testing.
OC4J Seam Archetype Update
Well, that wasn’t hard. I think I have the redeploy issue fixed, and a shared library was the trick.
Seam and JPA/Hibernate on OC4J 10.1.3
On a recent project, the architecture we settled on included JavaServer Faces (no surprise, there, I guess:), JBoss Seam and JPA. The production environment is Oracle’s OC4J, so the stack we chose has to deploy (easily) to that container. While I did get it working, it wasn’t easy, nor was it easily reproducible. Now that the pressures of deadlines have passed, I took the time to track down what exactly needs to be done to make the application deploy and run on OC4J. In retrospect, it doesn’t look that hard, but, knowing the pain I went through to make it work, I thought I’d share what you need to know if you’re in a similar situation.