I discovered this when I changed my build script to only resolve ‘master’ before publishing a snapshot to a local repo, because I wanted local publishes to be extremely fast. I guess it’s ok for local snapshots to carry dynamic revisions, but it’s probably a good idea to always do a full resolve before publishing a release.

To use the class, drop the class on you Ant classpath, then declare the task like so:

It's a standard Ivy post-resolve task. What that means is a) it takes the same common attribute set as any other post-resolve tasks would, and b) it must be run after an ivy:resolve call. For example, every time the following line

executes, the entries in .classpath that were generated from the previous run are removed, and new entries added according to the latest ivy:resolve result on ivy conf "provided" and "testtime". The entries generated by this task are marked with an attribute, ivygen="true", so any entries you manually added are not impacted. Note: if you have added classpath entries manually for the dependencies in ivy.xml, before running this task for the first time ever, it's a good idea to remove all of them, otherwise you'll end up with duplicated entries.

To invoke the source jar attachment support, just add to the ivy.xml references to the source jars. For example:

would add hibernate-core's source jar to ivy conf named "references". Then make sure to include conf "references" in the ivy:resolve call, such as:

The classpath entries updated will then also have the corresponding source jars (if available) attached.

Here's the source code for the task.

_NSJVMLoadLibrary: NSAddLibrary failed for /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Libraries/libjvm.dylib
JavaVM FATAL: Failed to load the jvm library.

As the initial "oh crap now we don't have Bush to blame it on" panic settles in, you realize since the last time Eclipse ran fine, you did go in there and tinkered with that "CurrentJDK" stuff, so that JDK 1.6 instead of 1.5 would be the default.

So you start googling frantically and find, through the first link returned, this neat solution by rkischuk. The only difference is that the file you have to edit is located at:

${ECLIPSE_HOME}/Eclipse.app/Contents/Info.plist


Hmm..., and when Steve Jobs said "Java's not worth building in," you thought he was only talking about the iPhone.

Fortunately I have a Nexus repository as the aggregator/proxy to all the external repositories. Brian from the Nexus IRC room pointed me to this solution/workaround: add the fixed maven-metadata.xml to a repo hosted by Nexus - e.g., the "3rd Party" repo coming out of box in Nexus. Then create a group to aggregate the 3rd Party and the public Ibiblio repos. The "virtual" group repo will automatically create a merged maven-metadata.xml on the fly whenever it is requested.

And it works like a charm. Thanks, Brian!

org.hibernate.MappingException: multiple or zero characters found parsing string

Turns out if the discriminator type is "character", the base class must have a discriminator-value attribute declared, even though obviously due to the abstractness there will never be any row carrying that discriminator value. And apparently for "string" type discriminators, there isn't such a limitation.

After a fresh rebuild and 'make install', git gui upon starting up would insist on making me choose a repository, even when I start it from a perfectly valid git working directory.

So I found out that it was failing to execute "git rev-parse" during startup, which was due to /usr/local/libexec/git-core/git-rev-parse being installed with mode 750. And that was traced back to the fact that I have umask set to 0027, so the locally built git-add would have mode 750. Since git uses hardlinks to install all the built-in commands, everything hardlinked to git-add would have the same mode, and I end up with bunch of git built-ins owned by root and inaccessible to anybody else.

So the workaround is either 'chmod o+rx ${git-source-root}/git-add' before 'make install', or 'sudo chmod o+rx ${prefix}/libexec/git-core/*' after 'make install'.

Anyway, the online upgrade wasn't as slow as I thought - took about 3 hours to download about 1GB data and set up everything. Did run into a couple of minor surprises:

The computer booted up fine... without any functioning dns! NetworkManager apparently decided that it was OK to silently overwrite all the changes I made in /etc/resolv.conf. I have had some history with the Network Manager before, and so was not hesitant to disable it with sudo update-rc.d -f NetworkManager remove.

The only real annoyance was that kde4 stopped honoring ~/.kde4/Autostart, and when restoring a previously saved session wouldn't restore anything on the system tray either. So none of the utility programs I'm used to - klipper, kbiff, etc. - were automatically started any more. It was annoying because I had to restart X over and over to troubleshoot. Finally I spotted the Autostart item in System Settings, which seems to be using ~/.config/autostart (I guess that's part of the freedesktop.org standards?), and works fine.

Then like everyone else I have had to get by with the Eclipse viplugin for quite a while, but that's kind of like... well, three thin slices of turkey ham for lunch for a meat lover. On top of that, the new provisioning system and the countless new plugins bundled in Ganymede has driven me crazy (OK take a deep breath and stop ranting...).

Just a couple of days ago, I decided to give the latest 1.4.2 release another shot. Well, what do you know, I was up and running in no time. It's the best of both worlds - vim's powerful editing and Eclipse's powerful tooling.

I'm also enjoying the bonus that it works just fine even with vim in terminal mode. So I can just ssh to my box at work and start coding away, without having to suffer from VNC or remote X over a slow VPN.

1. Copy freemarker-2.3.13.jar into $ECLIPSE_INSTALLATION/plugins/org.jboss.ide.eclipse.freemarker_1.0.0.GA, and remove the freemarker-2.3.8.jar in there.
2. Edit META-INF/MANIFEST.MF to replace the reference to "freemarker-2.3.8.jar" with "freemarker-2.3.13.jar".
3. Restart Eclipse with the "-clean" command line option. This is important because otherwise the Eclipse OSGI engine will keep using cached bundle data which is stale now.

Jeffrey drives to his point by giving an example:

And then he states:

"This can be a good design or bad design depending on your needs. We are coupling to an interface, INavigator, but we are also coupling to a specific implementation class, MissileNavigator.

"If MissileLauncher can't do its job without MissileNavigator, then this coupling makes sense, and the class should be tested together with MissileNavigator.

Well, I am not sure about that. Looks to me, the commitment of coupling is already made right on the second line of the code above: where _navigator is declared INavigator. It essentially asserts that:

1. The interface exposed via INavigator suffices for MissleNavigator.
2. MissileNavigator makes no further assumptions on the class that actually implements INavigator.

Once that commitment is made, specifically instantiating _navigator to an implementation class buys us absolutely nothing, and loses for us most of the flexibility associated from programing against INavigator the interface. Think about it this way, if MissileLauncher has to use the specific implementation, MissleNavigator, meaning at some point it will have to explicitly cast _navigator to MissleNavigator, then that would be a very awkward OO design, and we might as well declare _navigator a MissleNavigator, and program against that interface to begin with.

So, depending on how people look at it, the hard-coded instantiation in the constructor can be considered part of the design or the implementation. But either way IMHO it's a bad one, and makes some unnecessary coupling.

The general idea of this approach is to maintain two separate branches -- one for synchronizing with the rest of the world, and the other for managing the local changes -- and sync between the two using the powerful git-rebase.

1. Say we have just cloned the team repository:

       master
       v
   A-B-C

2. The next step is getting ready to start hacking locally:

   (Nadeem Bitar points out below that "checkout -b" is a better way. Thanks!)
   $git branch local && git checkout local
   $git checkout -b local
   $make whatever local changes
   $git add <the files changed>
   $git commit -m 'LOCAL_HACKS: my env'

   Now we have (* indicates we are currently on the local branch, and the L? commits are the ones containing local changes):

       master
       v
   A-B-C-L1-L2
            ^
            local*

3. So we stay on the local branch, continue to work on the real cool features that we are here to really implement, and keep committing just like usual. After a while, we end up with:

       master
       v
   A-B-C-L1-L2-E-F
                 ^
                 local*

4. This is where the interactive rebase comes in so we can move the local changes L1 and L2 to the tip of local:

   $git rebase -i master
   (use our favorite editor to rearrange the commit lines)

   Now we have:

       master
       v
   A-B-C-E'-F'-L1'-L2'
                   ^
                   local*

5. The last step is to bring master up to speed with only the commits we intend to publish:

   $git rebase local~2 master  # local~2 is F' in this scenario.

   So the end state is:

            master*
            v
   A-B-C-E'-F'-L1'-L2'
                   ^
                   local

An alternative is use git-cherry-pick to move the non-local commits from local to master. Although it's easier than the approach above only when there is just one or two commits that need to be moved over.

As the latest version number, 0.4, implies, ditz is still at an early stage, but the idea of distributed issue tracking and managing the issues themselves as part of the codebase sounds very interesting to me.

And here comes the second layer of strangeness - I also have an ubuntu virtualbox machine running in the same box, with the same JDK version, same setup, and the same source tree. And it works just fine in there.

So fast-forward through a few hours of hair pulling, the two workarounds I eventually figured out are:

• The /etc/nsswitch.conf file out-of-box has a line looking like this:
  hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
  Apparently the name resolution code in JVM (e.g. InetAddress.getByName() and friends) doesn't like the multicasting DNS (represented by 'mdns4_minimal').
  Move 'dns' up so it looks like:
  hosts: files dns mdns4_minimal [NOTFOUND=return] mdns4
  solves the problem. On the other hand, I haven't observed any negative effect of this change on any of the non-Java applications.
• If you are not comfortable with or don't have control over changing a box-wide config file, another workaround is to set the system property java.net.preferIPv4Stack to true when starting a Java application (maven in my case) which needs to do name resolution.

So how come the default works fine in the virtual machine? My theory is that when running in there, the virtualbox NAT code running in the guest OS is called for name resolution during 'files'-based resolution, and is able to handle it by delegating to the host OS.

The Agp440.sys Hang
Since VirtualBox supports the VMDK file format, it's fairly simple to get started: just create a new VirtualBox vm, make it as close to the Vmware one as possible configuration wise, attach the same VMDK files to the vm as harddrives, and that's it.

Although the first time when you try to boot it up in VirtualBox, Windows is very likely going to hang right away. Trying to boot it into safe mode reveals that the sequence hangs at agp440.sys.

It is easily resolved by following this VirtualBox wiki article. Basically boot into the Recovery Console, and disable the agp440 service.

The Mup.sys Hang
Next Windows hangs at Mup.sys. The same trick from above doesn't help. After disabling Mup.sys, Windows hangs at the driver before it. So it's not Mup.sys itself, but something afterwards. Google finds me this virtualbox ticket. Following the tips, I switch to the PIIX4 setting for the IDE controller, experiment various combinations of APIC and IO ACPI, and am able to get past Mup.sys with both enabled.

Reactivate Windows
Finally I'm able to boot into Windows, but with various new hardware found, the Reactivate Windows screen shows up. I called Microsoft to reactivate, but looking back, I would advise waiting until after you have successfully reconfigured windows, especially the network connection (see below).

Hardware Configuration
Once booting into the desktop, Windows happily reports "new hardware" found and offer to install drivers for them. Always choosing the easiest option (i.e. the one with "automatic" in it) gets me through. If it does not for you, try selecting "Install Guest Addons" from the virtual machine menu first.

Naturally I decide to reboot at this point. Big surprise! Windows hangs up again as soon as the splash screen shows up. Booting into safe mode works, but not the normal mode. After a few tries and some futile digging around, I decide to call it a day.

Well, the next day when I try it again, it just magically works! I still don't know how exactly, except maybe a soft reset in VirtualBox is not such a "clean" restart compared to completely quit VirtualBox and restart from scratch.

Network Configuration
The networking doesn't work after booting into Windows at this point. Try to manually add a network connection manually does not go anywhere. Look through the Device Manager and find that the Vmware network card is still in there, with a big question mark. Uninstall that. Force the Device Manager to detect new hardware. Sure enough the VirtualBox one comes up and the driver gets installed smoothly.

Everything works great now. I'm for sure making a baseline copy of the virtual machine though.

Apparently the GWT compiler tries to assemble some images into the client package, and in doing so triggers some parts in AWT that require an X display if $DISPLAY is set. There seems to be two solutions:

1. Make sure $DISPLAY is unset for your build environment.
2. Define a system property, java.awt.headless=true. The twist here is that if you are using the GWT maven plugin, instead of directly specifying the property on maven's command line, it needs to be defined in the plugin's configuration in the form of:
   <extraJvmArgs>-Djava.awt.headless=true</extraJvmArgs>

1. The sound system in kde 4 appeared to have stopped working. It simply refuses to recognize the onboard sound card. Sound works fine in kde 3, or in kde 4 but through other packages - for instance, amarok and the flash video player can play sound without any problems.
2. The Logitech Marble Mouse would arbitrarily stop responding out of blue, and won't come back without rebooting. Good thing I have two mouses plugged in (the other Logitech with higher precision for games .
3. Firefox 3 Beta 5 crashed the X server once. I'll have to wait and see if this is recurring. So far Firefox has been quite stable otherwise.

Until beta 2, Ivy finds out about the available versions of a module by parsing the directory listing HTML from Ibiblio's Apache server. That doesn't work when there is a proxy server sitting in between, because a) the proxy server doesn't usually proxy directory listing requests, and/or b) the proxy server renders the directory listing in different HTML. Switching to using the structured maven meta data completely eliminated this mess.

Of course, using the maven-metadata.xml files from the official ibiblio repository will subject us to some new hazard - some modules have out-of-date maven-metadata.xml. For instance, by its maven-metadata.xml, the latest version of Hibernate would still be 3.2.0.cr1.

One of those maven proxy servers turns out to be a perfect solution to this problem - we can use them now, remember? In my case, I run an Archiva server proxying the official maven 2 repository. Whenever I run into a bad metadata file, I simply request the missing version through Archiva, and it will fetch it and update the metadata file. For example, in the hibernate case, I would just open up Firefox and try to download http://archiva-server/repository/internal/org/hibernate/hibernate/3.2.6.ga/hibernate-3.2.6.ga.jar. That only needs to be done once, and afterwards Archiva would have updated its local version of the maven-metadata.xml properly.