Maven Central has long been a critical resource in the Java community. I don’t think there is a single developer or organization that uses the JVM that has not been impacted by Maven Central. The importance of Maven Central as an open resource cannot be overstated. That’s why I am glad to announce that Google, a prolific participant in the Java community, is now hosting a complete mirror of Maven Central with research and data mining opportunities!
Polyglot for Maven 0.1.5 was released last week and the feedback is more positive that we could have imagined. Again, we have to stress that we really don’t know what will happen with Polyglot for Maven but we are definitely seeing people keen to use it. Many people are asking “Is there a tool I can use to convert my existing pom.xml files?” Now there is! With the release of 0.1.6 now available in Maven Central there is a translation tool available.
Maven has always had a loosely defined notion of a multi-module project, but we are starting to move toward a more cohesive definition along with a few new features that illustrate this. There is still more work to do, but one key point to note is that Takari’s upcoming Continuous Delivery work is predicated on a well defined notion of a multi-module project for cohesive versioning. People have worked around this missing definition and it’s implied in many places in Maven but when Maven 4.0 is released it will be well-defined and be used by at least two sub-systems Takari is building.
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.
This week we released Apache Maven 3.3.1 with many new features, but the changes to the core extension loading mechanism is the most significant addition. Why? It allows fairly radical behavioural changes in Maven without having to fork Maven’s core or use custom Maven distributions. A concrete example of this mechanism in action is Polyglot for Maven: with stock Maven 3.3.1 you can dynamically load an extension that can read a POM encoded in a Ruby DSL. Extremely powerful, and entirely transparent to Maven’s core.
EclipseCon 2015 is just around the corner, taking place at the Hyatt San Francisco Airport from March 9 - 12, 2015. Jason van Zyl will be presenting on M2Eclipse. Here are the details:
Tomorrow we continue our Maven Developer Hangout series where we will talk about the Polyglot for Maven project, and how to make it easier to deliver sophisticated features for Maven in the form of extensions.
Last week in the Maven Developer Hangout Anton Tanasenko, an M2Eclipse committer, gave a demo of the new Maven plugin configuration content assist feature in M2Eclipse. Users have frequently been frustrated that while trying to configure a Maven plugin they don’t get much help. With the changes Anton has made it is now possible to get complete content assist for Maven plugins.
This is a short article on how the Ruby DSL for Polyglot for Maven came to be. When I first started with maven-1 you could script part of the build functionality inside the project.xml using jelly-script. It looked like a good idea but once your build system grew bigger it turned out that jelly-script itself was too limited as a programming language and XML is not meant to be programming language. With maven-2 the jelly-script was gone and now you could write plugins in Java. It was a relief to use a familiar programming language in your build system. But such a plugin is too far away from the actual build and it is a huge step to start your own plugin for your build system.
Trying to develop a new Maven plugin, extension, or core feature can be extremely difficult without help. Anyone who has tried this knows it can be frustrating. One of our ongoing themes at Takari is to make overall Maven development experience easier and hopefully more enjoyable. We have created some tools to help!
Last week in the Maven Developer Hangout on January 15th Anton Tanasenko, an M2Eclipse committer, gave a demo of the Modello editor he’s been working on. Modello is a tool that Maven committers are familiar with as it’s what we use for generating Java sources, XSDs, XML readers/writers from a model. You can think of Modello as a super-simplified version of Eclipse’s EMF.
We have been working on our incremental Takari Lifecycle for many months and we forgot to share the great blog post from Paris Apostolopoulos about his experience using the Takari Lifeycle. We’re trying to get the word out about our incremental build support and we believe the best source of information for users is from other users.
Tomorrow we continue our Maven Developer Hangout series where we will talk about the Basepom project, how to efficiently develop Maven plugins in Eclipse, and how to make the configuration of Maven Plugins easier and safer.
On Friday we released the Takari Lifecycle 1.10.1 in response to an issue reported by Paris Apostolopoulos. Paris is very supportive of our efforts so we tried to get a release out for him and his team. From the time of reporting the issue to landing the new release in Maven Central was approximately 9 hours.
Last week in the Maven Developer Hangout one of the topics we covered was Takari’s JDT compiler implementation. Working on a JDT compiler implementation is part of our larger effort to bring complete incremental build support to Maven as part of the Takari Lifecycle. As progress on individual parts of our solution are made we’re trying to make an effort to share that work.
Tomorrow we kick off the first Maven Developer Hangout of the year! We have a good range of discussions lined up for tomorrow and there will likely be some heated debate! Paul Hammant and I are going to talk about Buck :-)
The M2Eclipse project has a new website! We’ve been working on cleaning up the existing content and converting it to Markdown. The Jekyll-based site is currently hosted at Github and we hope to be more active at curating the site and making it more relevant to users. We have been successful recently in garnering contributions to the M2Eclipse Discovery Catalog in the form of pull requests and we hope the same will be true of our new website.
At very high level, a java compiler takes project sources, classpath and configuration options as its inputs and produces class files and compile messages as the output. Java sources are never compiled in isolation. At minimum the java compiler needs to access java.lang.Object and several other java standard library classes, but most sources reference other classes from the same module and/or other reactor build modules and/or classpath dependencies.
Yesterday we had out first Maven Development Hangout and we discussed evolving the POM format. A summary still needs to be written and posted to the Maven Developer list but if you’re interested in listening to the discussion I’ve tried to capture some of the highlights.
Today at 4pm EDT we’re going to have the first ever Maven Development Hangout and anyone is welcome to attend. What are we going to talk about specifically? Concretely we plan to talk about how to evolve the Maven POM format and the best strategy for doing this.
Many issues were resolved for the Maven 3.2.2 release, but of particular note this releaes is the number of pull requests we received for Maven itself. It’s not uncommon for us to get patches for plugins, but for this release we received some non-trivial contributions for Maven which is both suprising and awesome!
Lately, I’ve been pleasantly surprised with the number of pull requests for Maven Core. We get frequent patches for Maven plugins, but it’s not very common to get patches for Maven core because it takes a while to understand any part of the codebase. So kudos to those who have attempted to contribute changes and I hope to make the process of contributing easier.
In wilderness survival, knowing about the sun and stars can be vital, especially when you find yourself lost without a map or a compass. These navigation skills can help you get your bearings quickly, so you can get pointed back in the right direction. Acquiring these skills before you need them, can make a world of difference.
While working with a customer on a migration from Ant to Maven we needed to maintain the same build performance in the converted Maven build. Some ingenious work had been done in the existing Ant tasks to provide a degree of incremental behaviour which we had to match or do better. We have had a form of incremental behaviour in Eclipse m2e for quite a while, but working on this project provided the impetus for creating a proper incremental build API. The incremental build API we created is not Maven specific but our first goal was to make this API work in Maven. Our long term goals are to have parity between the incremental behaviour in Eclipse and Maven on the command line, as well as provide an incremental build API that can easily be integrated into any tool.
Prior to Maven 3.2.1 how Maven built multi-module projects was fixed. There was a serial strategy and parallel strategy of stepping through projects to build, and the way projects could reference one another as dependencies was not pluggable. These two aspects of building multi-module projects and resolving inter-project dependencies is loosely referred to as the reactor and it’s behaviour the source of much annoyance.
Apache Maven 3.2.1 was released four weeks ago without much fanfare, and while there’s no grand list of new features there are some infrastructure changes worth mentioning because they fundamentally change how Maven can work. This week I’ll do a series of short entries on the new features and detail the infrastructure changes. There are official release notes for those interested but I’ll try to provide more colour and the high-level use cases driving the changes in Maven 3.2.1. Let’s start with a couple of the new features.
In the last few months at Takari we’ve primarily been working on performance and process improvements for Maven as part of a comprehensive conversion from Ant. On the performance side we’ve create an incremental build API for Maven and a more efficient way to to schedule builds in parallel. On the process side we’ve been working on a form of continuous delivery for Maven that we call generations. On the fun side we’ve been poking at Polyglot for Maven and the Shell for Maven.