Maintenance of malabar-mode

As some of my readers may have noticed, not much has happened to malabar-mode in quite a while.  I have simply been too busy, and have started using IntelliJ as my IDE of choice.

So this is a call to interested parties:  If anybody wants to take over malabar-mode, let me know and we'll work out the details.

Gnus, IMAP and Exchange 2007

My workplace upgraded its Exchange installation to Exchange 2007 over the weekend. As usual when Exchange is upgraded, the new and improved version also has a new and "improved" relationship to whatever standards it pretends to support.

In this case it was IMAP that broke.

First problem: During startup of Gnus, my echo area would be spammed with messages saying BAD The specified message set is invalid. Some googling later I had set the variable imap-enable-exchange-bug-workaround to t, which does pretty much what it says on the tin.

So far, so good. But then I opened my inbox. Hm. Weren't there LOTS more mails here on Friday? Did the upgrade blat my mail? Hang on - didn't I see some junk in the echo area while Gnus worked. Let me try that again.

Yes; lots of messages about In imap-parse-body 2. So I have a look at that function; all 90-odd lines of it. Apparently, something Exchange was sending made it fail an assertion.

Unfortunately, the original function was hard to fix, not least because it was hard to tell what was failing. But isn't it really just reading a Lisp list? What if we let the reader help us?

Some hacking later I ended up with this:

(defun imap-parse-body ()
  (when (eq (char-after) ?\()
    (nsubst nil 'NIL
            (imap-normalize-body-sexp (read (current-buffer))))))

(defun imap-normalize-body-sexp (body-sexp)
  (dolist (m (imap-find-message-rfc822-parts body-sexp))
    (setf (nth 7 m) (apply 'vector (nth 7 m))))
  body-sexp)

(defun imap-find-message-rfc822-parts (body)
  (flet ((rfc822-p (body)
                   (and (stringp (car body))
                        (string= "message" (car body))
                        (string= "rfc822" (car (cdr body)))
                        body)))
    (cond ((and (consp body) (atom (car body)))
           (rfc822-p body))
          ((consp body)
           (remove nil (mapcar 'imap-find-message-rfc822-parts body))))))

The imap-normalize-body-sexp stuff isn't really necessary - all it does is turn a list into a vector, and since that vector is accessed using elt it works with a list, too. A vector is just more efficient.

This code, simplistic as it may be, works for me (so far). If it works for you too, good; if it doesn't, there is no warranty.

Fun on the bleeding edge

My pet project jde-mvn depends on bleeding-edge snapshots of Maven 3.0. The reason is simple: MvnServer needs maven-embedder, which pre-3.0 is only available in a buggy and frankly unusable version 2.0.4.

Mostly this is not a problem; however, the recent work Shane Isbell has done on the POM model breaks some existing POMs. Among them, unfortunately, is the CXF parent POM; this means that jde-mvn will choke on any project that depends on CXF (or any other POM that triggers the underlying bug).

I've reported this issue as MNG-3838; no word yet on when it will be fixed (although "sometime before 3.0 goes final" is a safe bet).

Since some of the things I work on in my day job use CXF, I've made my own nastyhack version of Maven and created a "release" of jde-mvn that embeds it; read more about this "release" on the BitBucket site.

More fun with JDEE

With jde-mvn having reached a more-or-less stable point, I've played with some other ideas to make JDEE an even better environment.

One of these ideas is jde-refactor, which has now gotten far enough to unleash upon the unsuspecting masses. Er. Maybe there is one other person in the world who might find this useful?

jde-mvn moves to the bit bucket

Tonight I moved jde-mvn to BitBucket, the Mercurial world's answer to GitHub. Hopefully this will make it easier for other people to contribute (yeah, right); it's also a cool experiment for me to do.

Check it out: http://bitbucket.org/espenhw/jde-mvn/wiki/. Also, please check out the issues list, and report any bugs/comments there.

jde-mvn updates

I just fixed a bug in jde-mvn where nothing would work. But it worked for me last week, honest!

Many thanks to Tilman who made me aware of the problem; hopefully the problem I found is the problem you had...

pom-parser is dead, long live jde-mvn!

As some of you know (I know you're out there, freaks), I'm happily hacking away at my JDEE-Maven integration project. Up to now I have had two separate projects:

1. pom-parser, which dealt with getting information from the POM and into JDEE's variables
2. jde-mvn, which dealt with using Maven as a build tool

This became cumbersome, and got in the way of some cool stuff I wanted to do. So I merged them. :)

pom-parser is now deprecated; if you use it, you should move to jde-mvn.

This shouldn't be onerous for the, like, two people besides me who use it (while I'm on the subject, if you use this please drop me a note!), even though most (all?) of the functions in pom-parser have changed names.

jde-mvn is packaged as a JDEE plugin (for more on this, read about plugins in the JDEE manual), which means that the installation process is both simpler and more complicated, but ultimately I think this is the way I want to go.

Anyway, jde-mvn now supports a server mode, thus amortizing the startup cost of the JVM across calls. Wee! The initial startup cost is quite heavy, though, but there is not much I can do about that.

So. If you want to play with jde-mvn, it is available from my Mercurial repository. I will try to keep even tip fairly stable (I do the major hacking on a local clone), but I will also tag what I consider to be stable revisions with 'stable-DATE'; if you don't fancy life on the severely-hemorrhaging edge, you may want to go with one of these.

Enjoy!

New features in pom-parser

pom-parser just got a bit simpler; I now delegate the work of resolving artifacts to files in the file system to Maven (using the dependency:list goal with outputAbsoluteArtifactFilename=true). Less work for me, more robust system; it should now work out of the box if you have a non-standard local repository location (or if you're on Windows).

There are also three notable bug fixes:

• with-pom will no longer fall over if there is no POM; this allows you to have a single prj.el in the parent directory of all your source dirs without nastiness happening if you need to work on an Ant-based project
• Newer versions of maven-help-plugin have changed the output format; pom-parser should now be able to find the effective POM regardless of the plugin version
• The classpath order (as presented by Maven) is now preserved. This is only relevant if you're using Maven 2.0.9 or later; before 2.0.9, the classpath order as generated by Maven was non-deterministic anyway (!).

Next up: Integrating with Nexus for completion of artifacts (in pom-add-dependency).

pom-parser is, as usual, available from my Subversion repository.

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!

More pom-parser fun

Almost forgot: pom-parser now parses the output of mvn dependency:tree instead of dependency:build-classpath. This means that we can (and do) construct separate compile and runtime classpaths!

Exciting developments in pom-parser

pom-parser.el (http://svn.grumblesmurf.org/svn/pom-el/trunk/) has undergone a major change: It now does all Maven operations asynchronously.

This has its advantages; most important is that Emacs will no longer hang for several seconds the first time you open a Java file in a project. The work to make this happen also makes it easier for me to add more Maven operations.

The first additional Maven operation is already in place: M-x pom-resolve-source-artifacts will ask Maven to download any source attachments it can find in your remote repositories; pom-set-jde-variables will then add those source artifacts to jde-sourcepath (if you pass it :include-dependency-sources t). It sure is nice to do C-c C-v C-y on a class name or variable and have the source for that class pop up...

There is a downside to this asynchronous goodness, though: You must wait for the message "POM parsing done." to appear in your minibuffer before doing anything that relies on the project variables being set. This particularly applies to compiling (as well as anything else that uses bsh).

I have tried various ways to make JDEE wait for Maven, but haven't figured out a working solution yet. Stay tuned, though!

Bug in JDEE with CVS emacs

If you're running CVS emacs and JDEE 2.3.5.1, you'll want to patch beanshell.el with the following:

--- jde/beanshell.el~ 2008-05-15 01:28:59.000000000 +0200
+++ jde/beanshell.el 2008-05-15 01:29:57.000000000 +0200
@@ -341,7 +341,7 @@
 
               (insert output)
               (compilation-handle-exit 
-               'exit status
+               'exit (string-to-number status)
                (if (string= "0" status)
                    "finished\n"
                  (format "exited abnormally with code %s\n"

This avoids jde-compile falling over when the compilation is done (when running with debug-on-error).

Update: Turns out that parse-integer is not core Emacs; string-to-number, however, is.

Fixing emacs startup on Ubuntu Hardy (and Debian?)

Real quick: During emacs startup you may get messages in your *Messages* buffer saying "Error while loading file /etc/emacs/site-start.d/xxx.el". Most likely this is because that file includes a form (symbol-name flavor). Fix it to say (symbol-name debian-emacs-flavor) instead, and emacs will be much happier.

Noticed on Ubuntu Hardy with the emacs-snapshot package; I don't know if it affects any other distributions/versions.

Revisiting Maven + JDEE

I admit it, I've been an apostate. I have been seduced by the flashy pointclickiness of Eclipse, and have thus neglected my beloved Emacs (for Java coding, that is; I would never abandon the glory that is Emacs for reading news and mail, and for editing anything but Java).

However, recently I've come to feel dissatisfied with my heathen idols, and sought to return to the blessed, ever-welcoming arms of Emacs.

At this juncture I must apologize to the people who have commented on (and helped with) pom-parser.el. You have been most foully neglected, but now updates have happened.

http://svn.grumblesmurf.org/svn/pom-el/trunk/ holds the latest, greatest version of the pom-parser; it now correctly deals with all extant versions of maven-dependency-plugin, and adds the correct bits to jde-sourcepath.

Still to come: Separate runtime/compiletime classpaths; we need the runtime classpath to have completion work correctly, but should compile with the compiletime classpath in order to avoid relying on runtime dependencies in our code.

Maven + Emacs + JDEE = coding bliss

If you use Emacs/JDEE and Maven, you may want to look at my pom-parser.el, which lets you refer to information in your POM from your JDEE project files. The code is loosely based on Ole Arndt's work, but works with Maven 2. It delegates much of the work to Maven itself and the help and dependency plugins.