Polyglot for Maven is alive! Yes, the code for Polyglot has been around for a number of years but without the release of Apache Maven 3.3.1 and the new dynamic core extension loading mechanism it was highly inconvenient to use. The core work for Polyglot was one of the first things I asked Jason Dillon to work on when I hired him at Sonatype a lifetime ago. The work has stood the test of time and really is quite ingenious. Some unfortunate events occured: Sonatype had trademark issues with Apache, all Sonatype employees were thrown out of the Maven PMC by the Apache Board, I lost a lot of my motivation for anything at Apache and the Polyglot work, along with many other innovations, fell by the wayside. All that has passed, I’m back on the Maven PMC, I have moved on from Sonatype and am trying to strike a balance between what is feasible at Apache and what technologies are best served outside the walls of Apache. Polyglot I believe is one of those technologies that will thrive outside of Apache.

Mostly I’m glad that the work Jason Dillon did is finally available for Maven users as it really has a lot of potential but we’ve yet to even scratch the surface because to-date Polyglot has not been in an easily consumable form. Now it is and the feedback thus far has been incredibly positive!

I have no idea what Polyglot will become as some DSLs might be a radical departure from stock Maven. I have had many long discussions with people like Sam Pullara as to whether this is a boon for Maven or a disaster. This is one reason I think it’s best these extensions live outside the realm of Apache because it’s quite a departure from stock Maven. I honestly think that’s all right provided we get the consumer POM mechanism working as it allows folks like the JRuby developers to make a DSL they like, leverage Maven for the parts they want to use and deviate as much as they wish. The DSLs may eventually have access to Maven’s internals and this is when I think Polyglot will evolve into something very interesting. Again, normal Maven behaviour and the pom.xml are never going anywhere, Polyglot just allows some radical experimentation and we’ll see where it goes.

Honestly, I think it’s pretty cool that you can do something like this now:

project do
  id 'com.example:my-project:1.0.0'
  repositories do
    repository do
      id 'rubygems-releases'
      url 'http://rubygems-proxy.torquebox.org/releases'
    end
  end
  dependencies do
    dependency do
      group_id 'rubygems'
      artifact_id 'maven-tools'
      version '1.0.0.rc5'
      type :gem
    end
  end
  build do
    execute( 'install-gems', :initialize ) do |ctx|
      require 'rubygems/installer'
      gem_home = File.join( ctx.project.build.directory.to_pathname, 'rubygems' )
      ctx.log.info( "install gems to #{gem_home}" )
      ctx.project.artifacts.each do |a|
        ctx.log.info( "\t#{a.artifact_id}" )
        installer = Gem::Installer.new( a.file.to_pathname,
                                        :ignore_dependencies => true,
                                        :install_dir => gem_home )
        installer.install
      end	
    end
  end
end

By adding something as simple as a ${maven.multiModuleProjectDirectory}/.mvn/extensions.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<extensions>
  <extension>
    <groupId>io.takari.polyglot</groupId>
    <artifactId>polyglot-ruby</artifactId>
    <version>0.1.5</version>
  </extension>
</extensions>

If you are interested in Polyglot we have put some examples together that we hope will get fleshed out by the community:

https://github.com/takari/polyglot-maven-examples

And if you’re interested in looking at the implementation itself you can find it here:

https://github.com/takari/maven-polyglot

Please join our Maven Dev Hangout if you’re interested in learning more about Polyglot for Maven and please feel free to ask questions and leave comments!

Comments