initially, i just followed the simple starting instructions, which don’t use the –prefix option to git svn init.

it wasn’t long before i saw someone’s suggestion to add a svn prefix to the remote branch names.. as a way of segregating the namespace, and to easily allow me to have local branches that have the same name.

i searched around, but there weren’t any explicit instructions on how to add the prefix post-init. well, you can. here’s how.

in your .git/config, there will be a block for the SVN configuration:

[svn-remote "svn"]
	url = http://example.com/your/repo/root
	fetch = trunk:refs/remotes/svn/trunk
	branches = branches/*:refs/remotes/svn/*
	tags = tags/*:refs/remotes/svn/tags/*

what you will want to do is edit this file and add the /svn entries that i have in bold.

then, re-run git svn fetch. this will populate the new branches. thanks to the metadata git-svn keeps, its aware that there are already local commits that correspond to specific SVN revisions.

finally, you can delete all of the old branches using something like git branch -d -r | grep -v svn | xargs -n 1 git branch -d -r

then sit back and bask in your new prefixed life

i needed to publish a jar containing the asdocs, but alas, the asdoc plugin doesn’t contain an equivalent to the javadoc:jar goal from the javadoc plugin.

needing something immediately, GMaven to the rescue!

the below profile will generate an attached jar when running mvn -P release

<profiles>
    <profile>
        <id>release</id>
        <build>
            <plugins>
                <plugin>
                    <groupId>info.flex-mojos</groupId>
                    <artifactId>asdoc-mojo</artifactId>
                    <executions>
                        <execution>
                            <phase>package</phase>
                            <id>attach-asdocs</id>
                            <goals>
                                <goal>asdoc</goal>
                            </goals>
                        </execution>
                    </executions>
                </plugin>
                <plugin>
                    <groupId>org.codehaus.groovy.maven</groupId>
                    <artifactId>gmaven-plugin</artifactId>
                    <version>1.0-rc-3</version>
                    <executions>
                        <execution>
                            <id>package-asdoc</id>
                            <phase>package</phase>
                            <goals>
                                <goal>execute</goal>
                            </goals>
                            <configuration>
                                <classpath>
                                    <classpath>
                                        <groupId>org.codehaus.plexus</groupId>
                                        <artifactId>plexus-archiver</artifactId>
                                    </classpath>
                                    <classpath>
                                        <groupId>org.apache.maven</groupId>
                                        <artifactId>maven-archiver</artifactId>
                                    </classpath>
                                </classpath>
                                <source>
                                    import org.codehaus.plexus.archiver.Archiver;
                                    import org.codehaus.plexus.archiver.jar.JarArchiver;
                                    import org.apache.maven.archiver.MavenArchiver;
                                    import org.apache.maven.archiver.MavenArchiveConfiguration;

                                    File asDocJar = new File(project.build.directory, "${project.build.finalName}-asdoc.jar")

                                    if( asDocJar.exists() ) asDocJar.delete()

                                    archiver = new MavenArchiver()
                                    archiver.archiver = new JarArchiver()
                                    archiver.outputFile = asDocJar
                                    archiver.archiver.addDirectory( new File(project.build.directory, "site/asdocs") )

                                    archive = new MavenArchiveConfiguration()
                                    archive.addMavenDescriptor = false

                                    archiver.createArchive( project, archive )

                                    helper = session.lookup("org.apache.maven.project.MavenProjectHelper")

                                    // need to attach to the *original* project
                                    // http://jira.codehaus.org/browse/MGROOVY-172
                                    project.class.getDeclaredField("original").accessible = true
                                    helper.attachArtifact( project.original, "zip", "asdoc", asDocJar )
                                </source>
                            </configuration>
                        </execution>
                    </executions>
                </plugin>
            </plugins>
        </build>

        <dependencies>
            <dependency>
              <groupId>org.codehaus.plexus</groupId>
              <artifactId>plexus-archiver</artifactId>
              <version>1.0-alpha-7</version>
            </dependency>
            <dependency>
              <groupId>org.apache.maven</groupId>
              <artifactId>maven-archiver</artifactId>
              <version>2.3</version>
            </dependency>
        </dependencies>
    </profile>
</profiles>

if you were using Hudson, there’s a plugin that will start/stop Xvnc for you. there’s demand for a Bamboo plugin, but nothing yet.

however, you don’t really need a plugin! if you’re using maven 2.0, drop these three lines into ~/.mavenrc:

vncserver -kill :0
vncserver :0
export DISPLAY=:0

(be sure to run vncserver once as the user Bamboo runs as to set a password first).

then, when maven is launched, it will destroy the existing X session, start a new one, and set the display property properly. should anything go awry, you can always connect a VNC client to see the screen prior to the next build starting.

while it’d be nice to have it more automagic like what Hudson has, its easy enough to string a solution up

You can now get through firewalls, opening your applications to the widest audience ever using the new HTTP connection option. If a client can’t successfully establish a socket connection with the server due to firewall security then HTTP connection can be used and it will just work. As a developer, the only difference in the way that you use the API is you will call createHttpConnection instead of createConnection. All other calls and events are identical!

the implementation wasn’t bad at all. due to the usage of mina on the backend, it was very simple to plug in alternate frontend that wraps our existing protocol. i hacked and back-ported pieces of the mina 2.x branch http client code for a very simple http implementation that wraps the electroserver binary protocol as the request/response payloads. it was really just an extra link in the chain before the existing logic that expected the binary protocol on the wire directly. add in some support for storing messages for clients and voila.

due to how mina itself works, comet / long poll support also “fell right out” of the implementation. this means that for message receipt, if there is an open channel, using http is just as performant as electroserver’s native binary protocol.

there was also another funny bug that i fixed that involved making a reentrantlock fair. this was the first time i had personally witnessed the needed to use this option, but when dealing with the need to process things in-order where messages can arrive via multiple threads, its a lifesaver.

Like him, when I started using it on the Mac, they drove me nuts. Since this was back when Eclipse sucked mightily on the Mac, I remapped them all.

You can download the file here. Place it in your ~/Library/Preferences/IntelliJIDEAxx/keymaps folder and restart IDEA.

i have a lot of ideas on how to simplify the programming model we expose to plugin developers, some of which i’ll be expanding upon at a later date.

but, to help achieve those goals, paul hammant turned me on to a library mike rettig has ported from .net, jetlang.

it reminds me a lot of the old excalibur event code that the avalon team worked on years ago.. trading sinks and sources for publishers and subscribers, the end goal is the same. i tried to revive the event code a month ago or so, but it felt to large.. not all of the functionality was really needed.

jetlang does it right.. its simple and focused, and will be an excellent base to build upon.

mike posted about a 0.1.3 release today. i’m fairly happy with the api, and i think mike is too. next thing i want to tackle is a maven build, to help bring it to a wider audience. then, time to build stuff on top of it!

anyways, go check it out. post a message to the mailing list with your thoughts.

however, what i found interesting was:

Why ePACE? Olin indicates that a key attraction was the fact that the solution is based on an open source platform running on the Linux operating system.

as the lead architect of the system, reading this makes me proud. its using some very battle-tested technologies. apache avalon as the component backbone (i bet its still running in the phoenix container!), cocoon for the webapp, and all served up with jetty. we moved to an appliance model early on, shipping a debian-based machine that was turn-key

congratulations to the whole pace team, you guys did great!

edit: another good article (especially the comments) on the deal .. highlights what some of the customers liked about pace, and the industry in general.

this afternoon, i tried to do a release of some software at work.. and the maven release plugin was failing! its a very odd error:


[INFO] Tagging release with the label release-0.4...
[INFO] Executing: svn --non-interactive copy --file /tmp/maven-scm-1130425261.commit . https://example.com/workstuff/release-0.4
[INFO] Working directory: /Users/osi/Documents/workstuff/trunk
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Unable to tag SCM
Provider message:
The svn tag command failed.
Command output:
svn: Commit failed (details follow):
svn: File '/workstuff/tags/release-0.4/pom.xml' already exists


very weird. i tried executing that same command at the prompt, and got the same error. i did a svn up, and then it worked.. hrm. thankfully, macports makes it very easy to drop back to 1.5.0, and after i did that, maven was able to release no problem.

UPDATE: using 2.0-beta-9 of the maven-release-plugin has a workaround for this issue.

now, rather than having to start your agent via the command line, wouldn’t it be neat to do what they suggest in the package javadocs and load an agent dynamically at runtime?

i had a hell of a time finding details on exactly how to do this. install an agent in another vm? sure. current vm? nah.

in randomly following links last night, i came across a blog post from dain, and it mentioned a getPid() routine that OpenJPA uses. this tickled my memory, and i went looking for the class that uses it. i found the InstrumentationFactory from the OpenJPA code. jackpot!

what they do, is use the Attach API that Sun added in Java 6 to dynamically load an agent. They had to do a trick in order to figure out the current PID, but with that, no problem!

i did need to make some tweaks to their code to have it load in my environment. if you’re working in an environment with dynamic class loaders, when the class is loaded as an agent, it will be a new instance and thus not visible to the factory as-is. to get around this, split the factory into two pieces. the agent, and the factory. the factory does not use the agent at all, it always accesses it reflectively. then, after the agent has been loaded, use Class.forName("your.agent.class.name", true, ClassLoader.getSystemClassLoader() ) to get the instance. reflectively load the stored instrumentation and bingo!

i’ve learned a lot working there; it was the first venture-funded startup i had worked for. i got to see the team grow from around 5 to the current 20-something. my co-workers and teammates were all immensely skilled in areas different than i, so it was a great experience to witness how they did what they did. we worked like mad to get twine launched. i now leave it in their capable hands to allow it to grow and mature. keep an eye on it, there are a lot of cool ideas that should be surfacing in the next few months.

the completely different thing is going to work for a gaming company, electrotank. i’m not much of a gamer myself (aside from lots of mario kart. comment if you’ve got it on the wii as well so we can play!),

it will be an opportunity to learn about an entirely different industry. what i’ll be doing is of course what i’m good at, helping architect/design/build the back-end systems for maintainability and scaling. their core product is built on apache mina, so this will also allow me to spend more time with the community than i had in the past year.

i wish all my past radar colleagues the best, look forward to meeting all my new teammates, and tackling the fun challenges ahead!