I’ve spent a lot of time on the boxes, and unfortunately, the time I spent fixing seems to have eclipsed the time I spent playing.

The thing I’ve found most fascinating about the process is that, while buggy, the 360 hardware is quite resilient.  With enough twiddling of screws, I can get a box up and running quite consistently.

The Company was pleased with our performance last year.  So they went against everything we’ve been teaching our kids, and gave us candy pills.

That’s Jelly beans on the left, mints on the right.  Or so I hope.

One bad thing about Buzz: Those replies are on the Buzz server, not here.

I’ll try to scale back the user requirements for posting, as I have gotten complaints about that.  But if spam gets too high, I’ll have to turn it back on.

Another way of putting it is that I’m ashamed of the state of our industry, in these cases.  It may be inertia, or the teams I’m on, or anything, but I still have to fight it, understand it.  These things are what we should be laughing about, when talking about the bad old days.

I have some thing swirling in my head… part of this may be the continuation of the Java Build Systems posts I had earlier, and more.  Next two entries, I think: Java and ORM, Java and the Web.

• How Gamestop ruined my Valentine’s Day
• Gamestop Made Me Do It
• I’m an Idiot

The wife lovingly bought me a copy of Mass Effect 2 for Valentines Day.  In fact, she told me she was going to, hence my desire to get my Xbox working.  She gives it to me, and the first thing out of my mouth is “Oh, you bought this used?  I’ll have to pay $15 to be able to download the free stuff for it.”

I always do this.  My wife could buy me the coolest toy, phone, gadget, or netbook, and I’ll mention how much I like it, and oh did you see the deal on it last week where it was half off?  I make the lovely wife feel like an idiot, and the gift seem cheap and poorly thought-out.

That’s my personal demon to remove.  The real enemy here?  Gamestop, for knowingly selling my wife a game for $55 (a five-dollar discount off new retail price) without even mentioning this to her.  They made a ton of money off the deal, probably way more than they would have from selling the game new.  It was very well publicized in gaming circles that this was coming down the line, there’s no way they were innocent.

I’m putting them on my list of most hated companies.  Companies I won’t go to or buy from.  Congrats, guys — you just joined the ranks of Best Buy and Sony!

I just picked up three books on Design, based largely on the recommendations in the JavaPosse Roundup 09 sessions on the topic.  I haven’t read them yet, but just perusing them makes them look to be a lot of fun.  First, the Amazon links:

1. The Design of Everyday Things by Donald Norman
2. Don’t Make Me Think!  A common sense approach to Web Usability by Steve Krug
3. The Non-Designer’s Design Book by Robin Williams

Everyday Things is actually about physical, industrial design, but a lot of the anecdotes, photographs, and diagrams seem to apply just as well to software design.  The Design Book steps a bit closer to my familiar software realms by covering general graphic design principles, largely for print media.  It covers the basics of Proximity, Alignment, Repetition, and Contrast, and a host of other things including color and type (font to us normals).  And lastly, Don’t Make Me Think! covers style and web patterns.  It has juicy bits on brevity, breadcrumbs, scanning patterns, and tons more.

I can’t wait!  Practical design has always been something I like.  I want to learn the best patterns.

Oops, it happened again.  There’s no free lunch this time.  Even if I paid the $100 to MS to repair it, they would only give a 90 day warranty on their work.  So, either buy a new one (with a massive extended warranty, of course) or try to fix it myself.  After attempting to buy a new Arcade unit for $200 at K-Mart twice, but failing both times because they were out of stock, I went the fix route.

Oooh, that’s a dark and scary part of the internet.  Everyone’s trying to sell you their $40 guide on how to fix it like the pros.  Plus they tout how their guides are not scams (a good indication of scamminess), and how they will make you a better person.  I kept digging, though, and found help on my brother’s recommendation:

YouTube – How To Fix the Red Ring of Death #1 (Penny Trick)

It actually worked.  I used the video as a general guide.  The only thing I had to do “off the books” was convince the xbox to get out of the three red rings mode.  I’m not sure I did this the best way, but I unplugged the fan and powered up for about 2 minutes.  Even though the three red rings keep flashing, all the parts warm up decently (but can get too warm, that’s the part I’m not sure about). After a 30-minute cooldown, the xbox booted just fine.

Along the way, I came across these other reputable/useful links:

• Fixing without towels
• Llamma’s X-Clamp fix
• X-Clamp fix 2
• Mario’s Repair Guide

I played Gears of War 2 for 30 minutes, no problems.  It logs onto Xbox Live just fine.  And, we’ve gone through the movie Dinosaur today with no issues.  Perhaps it will live long enough for me to play up some Mass Effect 2!

Update:  Not long enough for all of Mass Effect 2… see also this new post.

This is my current gold-standard set of podcasts:

Podcast / RSS Link	Category	Average Length	Description
Major Nelson Radio	Gaming	1:15 - 2:00	Gaming podcast, focussed almost exclusively on the Xbox 360. Interviews and news.
IGN Games Podcasts	Gaming	0:40 - 1:15	I listen to the following podcasts from this RSS: Game Scoop (all around gaming news) Three Red Lights (ostensibly 360, often silly) Nintendo Voice Chat (Wii / DS) Command Prompt (PC Gaming)
IGN Entertainment Podcasts	Television / Movies / Technology	0:40 - 1:00	I only currently listen to Channel Surfing, but occasionally there are other interesting podcasts
Bungie Podcast	Gaming	1:30 - 2:00	Bungie studios talking mostly about Halo. Note: Not bleeped, not filtered.
Anger, Sadness, Envy	Gaming	1:15 - 1:45	Rampancy.net's podcast discussing all things halo. Fun deep dives into story and gameplay.
The Dealnews Podcast	Technology, Consumer News	0:40 - 1:00	A medium-length, somewhat lighthearted take on tech news and product deals.
The Java Posse	Programming	1:00 - 1:30	Java and JVM news and sessions

Here are some podcasts I’ve just started listening to and am still evaluating:

This could be a cool way to develop/test the GamesByEmail game I’ve been fiddling with, perhaps.  I don’t think code-completion is in there, yet, which will ultimately be a must-have, but I can play for now…

Big bonus:  the editor is high-performance, and is implemented with my favorite, the HTML5 Canvas tag.  See also my experiments right here (I’d recommend planetaryZ2, and don’t forget to mouseover/click a planet).

There is some work going on integrating eclipse with this… not sure exactly what, yet, though.  See Eclipse in the Cloud and E4/Bespin.

• buff
• debuff
• tank
• aggro
• DPS
• AoE
• Bonus:
  • Tapping
  • Untap

In some cases, you may even be fooling yourself that you’re playing a game.  Seriously, though, I’m a nerd, and listening to people talk like the above makes me want to take their lunch money.

The discussion that spawned this was an article on Slashdot about breaking up some of these concepts, so that MMOs don’t all end up the same.  I’m in full agreement… I want to have fun playing, and I want to at least pretend that it’s not all numbers in a computer somewhere.

(I had to throw in the M:tG terms just because playing that game causes you to talk especially nerdy.)

Buy.com recently had a great deal on some games and battery packs.  One of the games included was Crackdown.  Here’s a quick review, after playing about half the game.  I get the feeling that Crackdown is one of those games everyone’s heard of, but few have played.  It’s never had a mega promotional campaign, but it’s a solid, well put-together title.  To sum up my feelings about the game: it’s a blast.  And it gets blastier the farther along you get.

This is clearly an open-world title.  The city, its people, and its gangs and cars all go on without your intervention.  They even get into traffic accidents and pile-ups, all by themselves.  There is a light, guiding hand as to the first few missions to undertake, but the order of everything is optional.  You can go almost anywhere in the city right from the beginning, sort of… more on that in a bit.

What do you do?  Well, basically, you can drive, shoot, punch, detonate, and jump.  In fact, doing those five activities nets you better abilities resulting in a stronger ability.  For example, the more you drive a car, with drifting, stunts, and checkpoint races, the better the car handles and performs.  Likewise with shooting, punching, and explosives.  Higher skill levels will give you faster aiming, additional health, and larger blasts.

And lots of jumping gets you, well, nothing, by itself.  Jumping is improved by picking up Agility orbs, placed all over the city.  With some clever jumping, you can pick up a ton of orbs.  Once you have enough for the next level, you are rewarded with a major boost to your jumping height and running speed.  After a couple of levels, you are crossing the city by leaps and bounds.  You might find yourself orb hunting rather than playing the game.  It’s almost peaceful… until you miss that jump and land on the highway and get run over.  Such is life, though.

Taken all together, you have a pretty fun game.  You begin to feel like a superhero, throwing barrels, jumping to the top of tall buildings, punching guys into next week.  And you have guns and cars, which make everything better.  And, you can play two-player co-op.

This is a violent game — you’ll be running people down, punching guys off buildings, and lighting people on fire via explosives.  The game has some minor flaws, and archaic-feeling menu system, some odd button choices for actions, and targeting and camera issues.

• How much would I pay for the game? Despite its second-generation mistakes and issues, I can say this game would be worth buying at least $50, possibly a full retail of $60.  The fact that I paid about $6 for it is just gravy.
• How many times would I replay it? I’m absolutely going to play this one through to the end, and gather all 800 orbs if I can.  I could see myself playing it again, especially if I can find a co-op buddy to do it with.

I had just been pricing out Android phones at T-Mobile last month, so I was a bit interested.  Here’s a quick breakdown of the options, buy-first, or 2-year contract:

You’ll notice the subsidized plans are not the same — the Nexus’ plan includes unlimited text messages.  If they allowed you to drop that, the subsidized Nexus 2-yr price would be about $1860, not too bad.  I kinda doubt they’d let you drop that, though.

Also, I’m a bit curious what the plans look like family-style.  Again, can you change the Nexus plan to be a family plan?  A casual glance generally shows a 750 minute minimum, and another $20 baseline, and $10 per extra phone.

And finally, some crazy folks propose dropping voice altogether, and going data-only, for an apparent $40 / month + a Skype subscription for $3 a month.

Recently, our AT&T GSM reception at home has improved from 0 to 1 or 2 bars… I wonder how T-Mobile would perform?

One solution: ntlmaps — NTLM Authorization Proxy Server. Roughly following the guide here, it’s pretty quick to get done. You will want to replace the URL in “Step 1″ with a recent one, such as (for 9.10) http://packages.ubuntu.com/karmic/all/ntlmaps/download.

The beauty of this is that, since Firefox can get past the NTLM proxy, you can download the ntlmaps package directly and install it. After it is set up, reconfigure System > Preferences > Network Proxy to localhost:5865, restart all apps (including terminals), and everything should be ready to go.

The one concern I have is that it stores my password in plain text at /etc/ntlmaps/server.cfg — granted, you must have sudo access to read it. You can apparently have it prompt when it starts up, but I’m not sure how this impacts the UI.

From reading the config file, it appears you can at least use the browser to store the password, in the basic auth scheme. It is possible you could even use the system preferences to do so, which is at least a bit more user-friendly. You will still have to remember to change the password, though.

Chickens are delicate creatures, sometimes dying for no good reason.  Unfortunately, they are also delectable creatures, and find themselves in harm’s way.

Our chickens have been cooped up in their, er, coop for several days now.  We’d lost 1-2 chickens a day last week.  Several of the abductions seem to happen during the middle of day, unusual for us.  Raccoons and possums (technically, Opossums, but that’s beside the point) are nocturnal, and do their worst work if we haven’t locked up the coop by 10 PM.

So that probably leaves a dog.  Not ours — they’re cooped up in the house while we’re gone.  A month ago, though, we had a couple of dogs in the yard; maybe they’ve returned.  We haven’t seen the afternoon striker yet, though, so it is hard to tell.

I’ve put up live no-kill traps, and after 2 apparent escapes and one time catching our out cat, I got a racoon last night.  Adorable little guy.  We’ll give him to someone in the country who doesn’t much like his neighbor, so it should have a happy life elsewhere.

We saw a possum two nights ago, but the dog let it run off somewhere… perhaps we’ll get it next time.  And no ETA on the dog thing, either.  But at least one perp is out!  Thanks, wikipedia, for the image!

This game makes me so happy.  Did I mention that I got all 1250 achievement points in Mass Effect?

Memorial day weekend, we broke the ban on Wal-mart.  Why, you might ask?  Because of Nibbler.

We were in Blytheville, AR over memorial day for the Hudson family reunion.  Lots of food, visiting, long-lost relatives, and, this year, rain.  After the reunion and 2 hours of swimming in an indoor heated pool, we headed out to Pizza Hut for some high-quality food.

We couldn’t find it.  Actually, if I remember right, we set out for a Mazzio’s Pizza, which was long gone, so we stopped at a parking lot to locate (& verify) a Pizza Hut.  But I digress.

It was a heavy downpour, and in a flat place like north-eastern Arkansas, that means something, since there’s nowhere for the water to go.  There was 1-2 inches of water basically standing in the lot, with more coming down every minute.  Suddenly, my wife jumps out of the car, and starts looking underneath.  She then runs around to my door and opens it, asking for beef jerky.

I had a pretty good idea what was going on… an animal.  A minute later she jumps back in the car with a shivering chihuahua, emaciated, missing hair, and with some scabs from the harness it was wearing.

We run back to the hotel, get my wife changed, and head to pretty much the only operating store in the county, Wal-mart, to pick up some basics for the dog.  There, we met an officer who told us to just take care of the dog, animal control was full.  We left some messages with folks down there, and still haven’t heard back.

So, that’s my path to destruction.  The real question:  should I go back?

What Maven does right

Maven teaches us several important things about what we need from a build system.

• Convention over configuration. Maven strongly encourages developers to put source files, resources, tests, and project metadata in standard locations.  Maven make life very difficult for anyone deviating from the norms.  In general, this is good, helps teamwork and collaboration, and helps for picking up a project cold.
• Defaults just work. Similar to the last entry, if you follow maven standards, then it works fine and has a reasonable assumption of defaults.
• Dependency Management. Probably the single best feature of Maven and modern build tools.  This allows a developer to specify requirements for a project without having to directly specify the physical location of those library dependencies.  This frees the build system to resolve from the network, automatically check for updates, and manage multiple versions of libraries.
• Plugins.  Easy extensibility is key to Maven.  In fact, most of its internals actually exist as plugins, from compilation to Ant support to deployment.  The ability to add new, custom behavior and have it tie into your builds is fantastic.

What Maven does wrong

There are some pretty big gotchas in Maven.  Nothing insurmountable, but frustrating nonetheless.  And before you say “It’s open source, fix it yourself!” know that it is not that simple.  There may be resistance to a certain change, for example, from “the establishment” or some issues and Maven’s solutions are fundamentally tricky.

• Outside the ordinary is very hard. Doing anything beyond the standard use cases requires an arcane knowledge of plugins.  All of a sudden, Maven’s configuration-based approach falls down, and things become easier to do in code — ie, you have to write a plugin.  But don’t think you can use the nifty ant-scripted mojos for that plugin– for example, for compilation, there isn’t a standard way to get the classpath into the ant script.
• Dependency Management. Yep, the same benefit is a detriment.  Or, at the very least, Maven’s handling of it.  Several things fall in here.  The ones I can recall are:
  • Transitive dependencies prove very tricky and make for lots of classloading troubles.  Adding a single dependency to a POM can really change the entire dependency graph of  a project.
  • There is no way to simply say “I want the latest of library XX”.  On the one hand, Maven makes sense here; you should usually know exactly which version of software you are building against.  But there are cases, for example, due to a lack of maturity, where having to know that version number is just an annoyance.  Ivy apparently has an intermediate option here, where you can specify latest, but when a build happens, it records what that version was.
• Long-standing bugs. Maven suffers a bit from what other mature open-source products hit upon.  Whether it is loss of momentum for something that works well enough or that too many are depending on the quirks, there are lots of oddities and issues left in core plugins.  A perfect example is maven-antrun-plugin, which only sets its classpath once per maven run, regardless of how many POMs reference it.
• Documentation bugs. Some of the Maven docs are a bit light on details.  Part of it may be Maven’s built-in site creation, which leads to some sites that have lots of links but are pretty information-sparse.  Other times, many common scenarios are presented, but some of the edge cases are glossed over.  Related:  looking for a list of available Maven properties for use in your POM is tricky because of Maven’s dynamic nature.  But a simple guide describing common ones and how to construct others would be great.

Summary

Generally, what Maven teaches us is that you need to fully embrace Maven to get the full benefit of Maven.  Once you get the hang of the Maven way, things go much more smoothly.  That is not unexpected, but it is uncomfortable.  But there are times where you have to fight — deploying to multiple load-balanced servers, for example, and you end up with some nasty scripts and configuration on top of a previously elegant solution.

The important thing is, though, that Maven does work.  It’s not too much of a bear to get started with, has great defaults, and it has some compelling solutions to annoying problems.

So, can Maven be fixed?  Should it be fixed, or should a build system start from scratch?  More on that next time.

! With JavaFX 1.2, some of the steps have changed. I will post a new entry covering the differences shortly.

Build / Compile

We use Maven as our build system, so JavaFX compilation must coexist with these.

Upload Dependencies to a Maven repository

First, we took every single Jar file in the JavaFX SDK 1.1 and uploaded them into Nexus, our development Maven repository. We took all jars from lib/shared and lib/desktop, uploaded them with groupID of javafx, artifactID matching the Jar name, version 1.1.

Building alongside Java code

To combat an explosion of modules, we determined that we wanted to have a src/main/fx source folder that is compiled and used right alongside src/main/java and src/main/resources. Furthermore, the JavaFX code needs to be able to refer to classes and interfaces in the same module as well as in any maven dependencies.

Our first attempt was to use the seemingly perfect fit, the m2-javafxc maven plugin. Early attempts seemed workable, but things started to fall apart and we had to abandon. Here are some of the issues:

1. m2-javafxc is based on the maven-plexus-compiler. This compiler will only run once per module. So we were unable to have src/main/java and src/main/fx side-by-side
2. m2-javafxc filters out anything other than .fx files. So we couldn’t have java and fx intermingled inside a single source folder.
3. Unfortunately, m2-javafxc is supported by only one individual, and barely used by the community. While the codebase is not large or complicated, this does represent a bit of a risk.

Next, we we noticed that the SDK includes an ant task, something easily runnable in maven. So, we built up a working ant script. If you look carefully, you will notice it takes three parameters. These are covered below.

<project name="compile-jfx" basedir="." xmlns:artifact="urn:maven-artifact-ant">
 
	<target name="compile.jfx" depends="check-if-should-build" if="should-build">
		<path id="javafxc.class.path">
			<fileset dir="${localRepo}">
				<include name="javafx/**/${javafx.version}/*-${javafx.version}.jar" />
			</fileset>
			<pathelement path="${compile.classpath}" />
		</path>
 
		<echo message="localRepo: ${localRepo}" />
		<echo message="jfx ver: ${javafx.version}" />
		<property name="compiler.class.path" refid="javafxc.class.path" />
 
		<echo message="jfxc classpath: ${compiler.class.path}" />
 
		<!-- create output directories: -->
		<mkdir dir="target/fxclasses" />
		<mkdir dir="target/classes" />
		<mkdir dir="target/clover/classes" />
 
		<taskdef resource="javafxc-ant-task.properties" classpathref="javafxc.class.path" />
 
		<javafxc srcdir="src/main/fx" destdir="target/fxclasses" includes="**/*.fx" compilerclasspath="${compiler.class.path}" />
 
		<!-- copy output files to two places to deal with clovery issues: -->
		<fileset dir="target/fxclasses" id="fxclasses" />
 
		<copy todir="target/classes">
			<fileset refid="fxclasses" />
		</copy>
		<copy todir="target/clover/classes">
			<fileset refid="fxclasses" />
		</copy>
	</target>
 
	<target name="check-if-should-build">
		<available file="src/main/fx" property="should-build" />
		<echo message="should-build: ${should-build}" />
	</target>
</project>

To integrate into maven, we use the following snippet. It ties into the standard lifecycle, as you see, and happens just after src/main/java is compiled. It supplies three parameters to the ant script:

• compile.classpath — the modules’s dependecy classpath
• localRepo — the root of the local repository
• javafx.vesion — the version of JavaFX to build with.

The last two parameters are used in the script to build the classpath to insure all the JavaFX libraries are present during compilation.

            <plugin>
               <groupId>org.apache.maven.plugins</groupId>
               <artifactId>maven-antrun-plugin</artifactId>
               <version>1.1</version>
               <executions>
                   <execution>
                       <id>ant-process-classes</id>
                       <phase>compile</phase>
                       <configuration>
                           <tasks>
                            <property name="compile.classpath" refid="maven.compile.classpath"/>
                            <property name="localRepo" value="${settings.localRepository}"/>
                            <property name="javafx.version" value="${javafx.version}"/>
 
                            <ant antfile="javafxc.build.xml">
                                <target name="compile.jfx" />
                            </ant>
                           </tasks>
                       </configuration>
                       <goals>
                           <goal>run</goal>
                       </goals>
                   </execution>
               </executions>
               <dependencies>
                    <!-- needed to compile javafx -->
                    <dependency>
                        <groupId>javafx</groupId>
                        <artifactId>javafxc</artifactId>
                        <version>${javafx.version}</version>
                    </dependency>
                    <dependency>
                        <groupId>javafx</groupId>
                        <artifactId>javafxrt</artifactId>
                        <version>${javafx.version}</version>
                    </dependency>
                    <dependency>
                        <groupId>javafx</groupId>
                        <artifactId>scenario</artifactId>
                        <version>${javafx.version}</version>
                    </dependency>
               </dependencies>
           </plugin>

Working Around Bugs

Ant Mojo

Next, we tried to wrap the above into a Maven plugin via the nifty Ant script-driven Mojo concept. However, I could not specify dependencies as I could with a Java mojo, and I was unable to get maven to pass the compile classpath into the script

maven-antrun-plugin

It turns out, if you have a multimodule project (we do) and you have multiple invocations of maven-antrun-plugin, the classpath gets set once, by the first run. We had the choice of putting every dependency on every antrun, or the light hack of having an empty antrun in the parent project with every dependency specified.

Clover

When doing a build that includes Clover numbers, clover changes the build classpath to include the artifact with the clover classifier instead of the regular one. We were putting our result classes directly into target/classes

javafxc crash

A dependency on org.apache.felix:org.osgi.compendium will cause the javafxc ant task to crash, hard, with a JVM dump. I suspect it is the javax-servlet 1.0.0, but I’m too lazy to prove that.

+- org.apache.felix:org.osgi.compendium:jar:1.2.0:compile
|  +- org.apache.felix:javax.servlet:jar:1.0.0:compile
|  \- org.apache.felix:org.osgi.foundation:jar:1.2.0:compile

OSGi / Runtime

The above gets us to a compiling and building state. However, our target platform is OSGi, specifically the Felix implementation. We need to be able to supply the JavaFX runtime classes to other bundles.

The javafx-runtime bundle

Rather than packaging each SDK jar individually into a bundle, we just dropped all of them into a single mega bundle. The following POM accomplishes this:

 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <parent>
        <artifactId>PT2</artifactId>
        <groupId>org.bjc.es</groupId>
        <version>1.11.0-SNAPSHOT</version>
    </parent>
 
    <modelVersion>4.0.0</modelVersion>
    <artifactId>org.bjc.pt2.javafx-runtime</artifactId>
    <name>org.bjc.pt2.javafx-runtime</name>
 
    <!-- the <packaging> pulls bundle from the parent's properties -->
    <packaging>${packaging}</packaging>
 
    <properties>
        <packaging>bundle</packaging>
        <clover-percentage>-100</clover-percentage>
    </properties>
 
    <description>
        This bundle simply wraps the various javafx-compiled jars as a bundle.
    </description>
    <dependencies>
        <dependency>
          <groupId>javafx</groupId>
          <artifactId>decora-d3d</artifactId>
          <version>${javafx.version}</version>
        </dependency>
        <dependency>
          <groupId>javafx</groupId>
          <artifactId>decora-hw</artifactId>
          <version>${javafx.version}</version>
        </dependency>
        <dependency>
          <groupId>javafx</groupId>
          <artifactId>decora-ogl</artifactId>
          <version>${javafx.version}</version>
        </dependency>
        <dependency>
          <groupId>javafx</groupId>
          <artifactId>javafx-swing</artifactId>
          <version>${javafx.version}</version>
        </dependency>
        <dependency>
          <groupId>javafx</groupId>
          <artifactId>javafxc</artifactId>
          <version>${javafx.version}</version>
        </dependency>
        <!--
        <dependency>
          <groupId>javafx</groupId>
          <artifactId>javafxdoc</artifactId>
          <version>${javafx.version}</version>
        </dependency>
        -->
        <dependency>
          <groupId>javafx</groupId>
          <artifactId>gluegen-rt</artifactId>
          <version>${javafx.version}</version>
        </dependency>
        <dependency>
          <groupId>javafx</groupId>
          <artifactId>scenario</artifactId>
          <version>${javafx.version}</version>
        </dependency>
        <dependency>
          <groupId>javafx</groupId>
          <artifactId>jogl</artifactId>
          <version>${javafx.version}</version>
        </dependency>
        <dependency>
          <groupId>javafx</groupId>
          <artifactId>jmc</artifactId>
          <version>${javafx.version}</version>
        </dependency>
        <dependency>
          <groupId>javafx</groupId>
          <artifactId>javafxgui</artifactId>
          <version>${javafx.version}</version>
        </dependency>
        <dependency>
          <groupId>javafx</groupId>
          <artifactId>javafxrt</artifactId>
          <version>${javafx.version}</version>
        </dependency>
    </dependencies>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.felix</groupId>
                <artifactId>maven-bundle-plugin</artifactId>
                <extensions>true</extensions>
                <configuration>
                    <instructions>
                        <Bundle-SymbolicName>
                            ${pom.artifactId}
                        </Bundle-SymbolicName>
                        <!-- embed all compile and runtime scope dependencies -->
                        <!-- <Embed-Dependency>*;scope=compile;artifactId=!log4j|javafxc</Embed-Dependency> -->
                        <Import-Package>
                            com.sun.imageio.plugins.gif;resolution:=optional,
                            javax.imageio.*,
                            javax.swing.*,
                            javax.sound.*,
                            javax.xml.parsers,
                            javax.media.*;resolution:=optional,
                            javax.script.*;resolution:=optional,
                            netscape.javascript.*;resolution:=optional,
                            sun.*;resolution:=optional,
                            com.sun.javafx.api;resolution:=optional,
                            com.sun.javafx.runtime.adapter;resolution:=optional,
                            org.jdesktop.applet.util;resolution:=optional,
                            org.jdesktop.animation.timing.*;resolution:=optional,
                            org.xml.sax.*;resolution:=optional,
                        </Import-Package>
 
                        <Export-Package>
                            com.sun.gluegen.*,
                            !com.sun.javafx.runtime.adapter,
                            !com.sun.javafx.runtime.liveconnect,
                            !com.sun.javafx.runtime.provider,
                            !com.sun.javafx.api.*,
                            com.sun.javafx.*,
                            com.sun.embeddedswing,
                            com.sun.media.*,
                            com.sun.medialib.*,
                            com.sun.opengl.*,
                            com.sun.scenario.*,
                            com.sun.stylesheet.*,
                            javax.media.opengl.*,
                            org.jdesktop.layout,
                            !javafx.fxunit,
                            javafx.*,
                        </Export-Package>
                    </instructions>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

You can alternately use Eclipse to export a bundle like this, see the post Running a JavaFX script from an OSGi bundle– generally a good article, but slightly skewed from our purpose.

The bundle created above is not quite perfect; some imports marked optional are probably not optional, but are for parts we aren’t using just yet, like sound, or applets. It is missing all the native code shipped with the SDK, which probably has a performance impact. We also haven’t tested a fully-featured screen yet. Finally, there is another problem, which we’ll see in the next section.

Integrating JavaFX into a Swing Application

I can’t create a Scene!

There is a pretty nice article called How to Use JavaFX in Your Swing Application on the main JavaFX blog. It gives details for how to convert a Scene subclass into a JComponent for use in a swing app. The only problem with that: With the javafx-runtime bundle above, I always get a NullPointerException during some StyleSheet intialization. Even when we do it from the command-line, the result is the same. Again, the javafx-runtime bundle is not quite perfect, and I think that this bears that out.

Getting the JComponent

So, we had a workaround: Extend CustomNode, then create a Scene in Java and inject the custom node in. The class below has a field called node, which is of type javafx.scene.Node, set in by Spring (see next section). We steal some of the code from the above link to help with the final extraction. Also note, we had to duplicate SingletonSequence.java in our package, since it is package-protected in the SDK.

        Scene scene = new Scene(true);
 
        Sequence<Node> seq = new SingletonSequence<Node>(TypeInfo.getTypeInfo(Node.class), node);
        scene.get$content().setAsSequenceFromLiteral(seq);
        scene.initialize$();
 
        // stolen from JFXPanel.java by Richard Bair and Jasper Potts:
 
        String helperName = "com.sun.javafx.scene.JSGPanelSceneImpl";
        FXClassType type = FXContext.getInstance().findClass(helperName);
        FXObjectValue panelSceneImpl = type.allocate();
        panelSceneImpl.initVar("scene", FXLocal.getContext().mirrorOf(scene));
        panelSceneImpl.initialize();
 
        FXValue jsgPanelV = type.getVariable("jsgPanel").getValue(panelSceneImpl);
        JComponent jsgPanel = (JComponent) ((FXLocal.ObjectValue) jsgPanelV).asObject()

Working with Spring

The last piece of the puzzle is the ability to allow Spring to create JavaFX instances and set properties on them. Here is an example JavaFX class:

package whatever;
 
import javafx.scene.*;
import javafx.scene.paint.*;
import javafx.scene.shape.*;
import javafx.scene.text.*;
 
public class EDText extends CustomNode {
    var text:String = Dialog.MESSAGE;
 
    override public function create():Node {
        return Group {
            content: [
                Rectangle {
                    width: 300
                    height: 200
                    fill: Color.BLUE
                },
                Text {
                    x: 20
                    y: 20
                    content: bind text
                    fill: Color.WHITE
                }
            ]
        }; // endgroup
    }
 
    function setDisplayString(newValue:String) {
        text = newValue;
    }
}

It has a single operation, setDisplayString(). Then came this Spring config snippet to access it:

    <bean id="edNode" class="org.bjc.pt2.authentication.ui.EDText">
        <property name="displayString" value="set a value from spring!"/>
    </bean>

… which of course doesn’t work. JavaFX infers that the setter has a return value because none was specified. Spring is looking for public void setDisplayString(String) but finds public string setDisplayString(String) and complains. Minor tweak to the JavaFX code for the function declaration:

 function setDisplayString(newValue:String):Void {

And it’s all happy!

Maven Adoption Curve (Alex Miller, coworker at MetaMatrix)
Maven and Ivy (Ryan Senior, coworker at BJC)

I was trying to think of the ideal build system.  I won’t pretend that I’m going to get there in this post.  Instead, I’ll enumerate what we do every day and what we need from a build system so as to start thinking about the ideal system.

So, to the brainstorming.  Here’s what we do in the regular process of our osgi bundle development:

1. Obtain dependencies
2. Compile java source
3. Compile javafx source
4. Generate metadata / configuration data
5. Make jar files
6. Upload jar files to central repository
7. Upload jar files to deployment location
8. Update remote (OBR) xml file with information about uploaded jar
9. Generate reports about the quality of the source (clover, PMD, checkstyle, etc)
10. check out from CVS / source control
11. check in to CVS / source control
12. tag CVS / source control
13. manage versions and releases

I’m sure there are more.  Obviously, under web development, you’d deal with wars and their deployment.  We have ssh tasks to run code on the server.  We even have some install/run stuff that works pretty well.

You may have guessed we use maven.  Maven is so close, but just not there.  It is frustrating, performs a lot of magic, and just falls down in annoying ways.  We have gotten it to do all of the above, some of it is just not pretty.

Next episode, I’ll go into Maven and what it does well and what it does poorly.  Stay tuned!