Writing Hudson plugins with Mirah

[David Calavera]

Hi,

during the last couple of days I've been working on a different way to
write plugins.

I'm trying to write them with Mirah, http://www.mirah.org/, a
statically typed and compiled language that looks like Ruby. It's not
ruby and it's experimental right now but it's really promising and the
best part here is that is compiles to JVM bytecode directly, it's
generated bytecode it's pretty much equal than the bytecode generated
by a java source.

This is the repository where my code is located:

https://github.com/calavera/mirah.hpi

Right now the plugin compiles, the bytecode is fine and hudson can
load it but I'm blocked. As much as I try it I don't get the extension
point anywhere. This is a simple builder plugin and it should appear
into the build combo in the job configuration. Indeed, Mirah also
allows to generate the java source code and with that code the plugin
works like a charm.

So, My issue here is that I don't know how hudson looks for the
plugins, I'm using the annotation @Extension but I've also seen that
it's retention is SOURCE, so it cannot be used at runtime and I'm
completely lost.

Could anybody explain me the complete cycle of how hudson loads
plugins?

Anyway, if anybody wants to help me with this please let me know and
I'll give you complete access to the repository.

Thank you!

[Kohsuke Kawaguchi]

What's happening is that during the compilation, @Extension needs to
go through the annotation processing, which creates an index file that
lists all classes/methods/fields annotated with it.

When you compile Mirah directly to byte code, this processing (which
depends on javac) doesn't happen.

Does Mirah have some kind of post-compilation hook to inspect the
resulting bytecode / source files? That would enable us to hook
necessary processing (although that needs to be written as the current
@Extension listup depends on javac.)

2010/11/22 David Calavera <david.c...@gmail.com>:

--
Kohsuke Kawaguchi

[David Calavera]

Probably the easiest solution then will be create the java source files before compilation and let maven to compile them as usual to create the extension files, though I don't like to use this intermediate step it seems closer to a solution than write post-compilation hooks for Mirah right now.

[David Calavera]

Hi,

I just wrote a post about my work:

http://calavera.github.com/2010/11/23/building-hudson-plugins-with-mirah.html

right now I can build the plugin and it works fine. I create the java source code from mirah and after that I compile it to get the extensions.

[Kohsuke Kawaguchi]

If this is easy enough, indeed it would be a good way to go.

Is Mirah interpreted scripting language? (in the sense that you can
generate bycode from source tree at runtime, much like JRuby does,
instead of ahead-of-time compilation?) If so, perhaps the Mirah parser
should have enough hooks to do something like this.

Assuming the parser part is shared with JRuby, such a change would
benefit JRuby/Hudson plugin integration, too.

2010/11/23 David Calavera <david.c...@gmail.com>:

--
Kohsuke Kawaguchi

[Kohsuke Kawaguchi]

Nice!

Tyler, wouldn't it be great to cross-post this at hudson-labs.org? WDYT?

I think maven-hpi-plugin can be extended to do Mirah-based HPI
packaging. Again, if we do it once, we can rinse and repeat for other
language bindings.

2010/11/23 David Calavera <david.c...@gmail.com>:

--
Kohsuke Kawaguchi

[R. Tyler Croy]

On Tue, 23 Nov 2010, Kohsuke Kawaguchi wrote:

> Nice!
>
> Tyler, wouldn't it be great to cross-post this at hudson-labs.org? WDYT?
>
> I think maven-hpi-plugin can be extended to do Mirah-based HPI
> packaging. Again, if we do it once, we can rinse and repeat for other
> language bindings.

If David has no problems with it, I can schedule a cross-post for tomorrow
morning on hudson-labs.org

- R. Tyler Croy
--------------------------------------
GitHub: http://github.com/rtyler
Twitter: http://twitter.com/agentdero

[David Calavera]

Actually Mirah doesn't include any runtime interpreter itself but it uses the java one, perhaps that's why it fits well in this case. The compiler is pluggable, what means that eventually we could add hooks to it and do the same process that the hpi does so I agree we could extend the hpi plugin, but I'm not sure if this could fit for other languages.

Tyler go ahead why the post, if you have any question don't hesitate to ask me.

[David Calavera]

Tyler,

btw, if your are going to write the post, could you use this link rather than the other one?

http://thinkincode.net/2010/11/23/building-hudson-plugins-with-mirah.html

Thank you!

[Kohsuke Kawaguchi]

OK, then what I meant isn't the runtime interpreter but the compiler.
Could Hudson invoke that on the fly, in a way that gives us a chance
to inspect all annotations and register them properly?

2010/11/24 David Calavera <david.c...@gmail.com>:

--
Kohsuke Kawaguchi

[David Calavera]

Yes, we probably can do it, but I need to figure out how first :)

[David Calavera]

Hi again,

I just wrote an update about this work. Basically now we can generate a completely functional plugin with the normal hudson's steps, mvn compile hpi:run. We still need to find the way to avoid the cross source compilation but at least the java source generation and compilation is transparent for the developer:

http://thinkincode.net/2010/12/03/building-hudson-plugins-with-mirah-baby-steps.html

Cheers

[David Calavera]

Hi,

I just wrote a new post in the serie with the code for a complete plugin that's working just fine. I hope you'll find it interesting:

http://thinkincode.net/2010/12/06/building-hudson-plugins-with-mirah-dogfooding.html

Cheers