Snapshots of Wave Robot API Now Available

I've Mavenized the Wave Robot API and the Wave model portion of Wave Protocol, a dependency of Wave Robot API and deployed snapshots to my public repository. Currently, I've only deployed snapshots since the use of this artifact is completely untested. I'm working on creating a Maven archetype for Wave robots (which will use this repository until Google uploads it somewhere), and an example using the archetype. After I've done this and am sure it works (and that I haven't done anything stupid with Maven), then I will tag a release and put it on my release repository.

If anyone would like to try it out in the mean time, your feedback would be most appreciated! Here is what you would need in your pom.xml:

<dependencies>
    <dependency>
        <groupId>com.google.wave</groupId>
        <artifactId>wave-robot-api</artifactId>
        <version>20100408-SNAPSHOT</version>
    </dependency>
</dependencies>
<repositories>
    <repository>
        <id>public-repo_maven2-repository</id>
        <url>http://public-repo.googlecode.com/svn/repository/</url>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
        <releases>
            <enabled>true</enabled>
        </releases>
    </repository>
    <repository>
        <id>public-repo_maven2-snapshots</id>
        <url>http://public-repo.googlecode.com/svn/snapshots/</url>
        <snapshots>
            <enabled>true</enabled>
        </snapshots>
        <releases>
            <enabled>false</enabled>
        </releases>
    </repository>
</repositories>

Some stuff I picked up along the way:

• When using the WebDAV wagon with Google Code, make sure you use https, otherwise you're liable to get a 405 method not allowed error on a deploy.
• There's an interesting bug with the Robot API's EventSerializerTest. The behavior is different in Javac 1.5 vs 1.6 but compile fine with the Eclipse compiler. There is bug report for Javac here (fixed in 1.7). I opened a ticket for Google to explicitly cast this in the method so the compiler doesn't have to do any inference, so that way it will build fine with Javac even if they're using JDK 1.6. In the mean time, I've opted to use the Eclipse compiler in the pom rather than altering my local copy of the source. My goal is to make this an exact match to the class files in the zip they've distributed.
• Guava, the successor to Google Collections (as a backwards compatible superset) and dependency of the Wave model API is on Maven central, but not on Google's repository. It's a little odd, but shouldn't cause any issues.

A special thanks to Jurgen and commenters for the helpful post that got me started.

Bots updated to v2 API

I've updated WorldCat-Bot and Yodaspeakify to v2 of the Wave API, which boasts some fantastic new features, including an easier way to do annotations, doing away with Cron, no need for a separate profile servlet, and the capabilities.xml is automatically generated for you using annotations.

One thing I voted for as an improvement was to use regular expressions in this method. I'm not sure what the author of the issue was talking about with iterating over Elements since, as I understand, these don't include text. The artifacts are still not on Google's repository and I'm getting pretty tired of a 5 minute commit time when I change some jars around.  I'm working on using Google Code as a repository and adding these artifacts after I mavenize them, then I'll create archetypes for Wave -- watch for an update on this soon, now that my bots are done this is the next project.

Some snags I ran into:
The .replace() of BlipContentRefs doesn't work the way you'd think it would. I thought I could do

BlipContentRefs content = blip.first(originalText).replace(newText);

But the BlipContentRefs will be empty. I got a hint for how to do this from wadrobotframework's BlipUtils:

public static void replaceBlipContent(Blip bleep, String nextContent) {
    BlipContentRefs bcr = bleep.all();
    if (bcr != null) {
        bcr.delete();
        bleep.append(nextContent);
    }
}

Thanks, wadael!

Another issue was when I used DocumentChangedEvent and then did a .getBlip() it would return a null Blip. My understanding of the JavaDoc was that it would return the root blip if no Blip was associated with that event, but this didn't seem to be happening. So, I opted for a BlipSubmittedEvent instead. Which, now that I think about it, is probably the desired behavior anyway.

Another issue was when I was trying to take advantage of the cool new filtering options. WorldCat-Bot used to surround it's searches with angle brackets (<>), but when I tried to filter on this

@Capability(filter = "<.*>")
@Override
public void onDocumentChanged(DocumentChangedEvent event) {
  ...
}

It didn't work because the capabilities.xml that was generated was not well formed. I also tried the escaped version

@Capability(filter = "<.*>")
@Override
public void onDocumentChanged(DocumentChangedEvent event) {
  ...
}

But this didn't work either, it looked for the entire literal not the unescaped form. I don't think this is currently possible to do, so I now use square brackets ([]) to filter on.

While trying to debug this, I set up logging (GAE supports JUL), but I learned it only logs things with INFO, WARN, and SEVERE levels (though I couldn't get INFO to work even with the logging.properties file with .level = ALL. Maybe something else is misconfigured).

But overall, the new API has been a very positive experience.

GMaven & source encodings

I'm re-posting this because I made some more discoveries after I had initially posted it.

I discovered apparently SourceEncoding is completely broken in GMaven. I tried on Linux where the platform default encoding is UTF-8 and on Windows XP where the platform default encoding is Windows-1252. In both cases, it used ISO-8859-1 as the encoding of the class file it generated, despite the fact the source was encoded in the platform default encoding. I tested this with version 1.2 of the plugin and Groovy 1.7.0. Why this is happening makes no sense to me; I could understand if it used the platform default...but why always ISO-8859-1? I think this is the Jira for this: http://jira.codehaus.org/browse/GMAVEN-13.
I find it shockingly disappointing that a 'critical' issue can go unassigned for almost an entire year. I wonder if it is working in Ant. Their documentation seems to suggest that it does. If that's true, it might tell us something about where the Groovy team's priorities are.

In practice, this often is not problem, since if you're only using ASCII characters in your source code, the first 128 bytes have identical mappings in UTF-8, ISO-8859-1, and Windows-1252, so it won't matter which of those the plugin tries to use. However, I view this as a major obstacle to Groovy's gaining dominance, as it should support Maven (since for better or worst it's become the leading standard) and it should support encodings to support global growth.

Am I missing something? Any good workarounds? I'm also happy to share my experiment project with anyone who wants to play with it.

I've also discovered yet another way in which GMaven's documentation is fail. I was trying to get my project to work with the latest version of Groovy, when I came across this unrelated StackOverflow discussion which use the new 1.2 version of the plugin (which isn't in the archetype or anywhere documented as released -- I thought the artifacts were released by mistake since nothing has even been tagged in their repository for 1.1 or 1.2, although IntelliJ already supports it, plus nabble and some blogs talk about it so I guess it is released). Here are the needed bits from the pom:

<dependencies>
    <dependency>
        <groupId>org.codehaus.gmaven.runtime</groupId>
        <artifactId>gmaven-runtime-1.7</artifactId>
        <version>1.2</version>
    </dependency>
    <dependency>
        <groupId>org.codehaus.groovy</groupId>
        <artifactId>groovy-all</artifactId>
        <version>1.7.0</version>
    </dependency>
<dependencies>
<plugins>
    <plugin>
        <groupId>org.codehaus.gmaven</groupId>
        <artifactId>gmaven-plugin</artifactId>
        <version>1.2</version>        
        <configuration> 
            <providerSelection>1.7</providerSelection>         
        </configuration>
        <executions>
            <execution>
                <goals>
                    <goal>generateStubs</goal>
                    <goal>compile</goal>
                    <goal>generateTestStubs</goal>
                    <goal>testCompile</goal>
                </goals>
            </execution>
        </executions>
    </plugin>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>2.3</version>
        <configuration>
            <source>1.6</source>
            <target>1.6</target>
        </configuration>
    </plugin>
</plugins>

Update: According to this Jira, this is fixed in the 1.3 release. And it appears from my tests that this is the case.