Next step, world domination

My JDEE/Maven integration work is proceeding apace; pom-parser is now learning to modify the POM. The first evidence of this is the command pom-add-dependency, which allows you to add a dependency element to your POM. It even does completing-reads of groupId, artifactId and version!

It doesn't reparse the POM when it changes, though. I know how to do it, I just haven't gotten around to it yet; besides, I'm not sure if I want it to. Maybe it should be a customizable option?

I've also fixed one genuine bug (I only changed the first dot in the groupId to a slash... oops) and one unexpected behavior:

Imagine a file structure where you have a src directory with two Maven projects inside, foo and bar. You have a generic prj.el file in the src directory.

If you visit a Java file from project foo, the foo POM is read and JDEE variables are set correctly; then visit a file from project bar, and the bar POM is read and JDEE variables set.

But if you then switch back to the file from the foo project, you will get bar's variable settings (e.g. classpath). Bummer.

Once I twigged to what was going on, though ("Dude, why is this file not compiling? Hang on, that classpath looks strange...") it was fairly easy to fix.

---

In other news, I have more-or-less ready code to use Maven as a build tool for JDEE (ala the Ant integration); I just want to hammer it a bit more before I make it public.

And I may have a solution for the "making JDEE wait for Maven" issue mentioned a couple of weeks ago. Once again, stay tuned!

Bidirectional Mercurial + SVN

I've been playing with Mercurial lately, and I'm really impressed. However, I still need to interact with Subversion repositories (not least my own), so I thought I'd try hgsvn, which lets you use Mercurial locally on a Subversion checkout. Sweetness!

That is, as long as you remember to tell Emacs that you prefer Mercurial to Subversion by moving the 'Hg' entry before 'SVN' in vc-handled-backends...

One wrinkle, though: hgsvn does not handle pushing changes back to the remote repo...

But that's nothing a little shell scripting can't fix!

hgpushsvn.sh lets you do just that.

Run it like this: hgpushsvn.sh mono[lithic]|single

monolithic (or mono)

Checks in all changes since the last revision in Subversion as one commit. The commit message is the output of hg log --style changelog for the changesets back to the last pulled from Subversion.

single

Checks in each changeset since the last pull as a separate commit. The commit message is still the output of hg log --style changelog. This is a much slower operation!