Posts Tagged ‘m2eclipse’

Bootstrap your Agile Java Startup Infrastructure in < 30 minutes

March 25, 2010

So, you have a great idea for the next web-based killer application. You have assembled a small but geographically dispersed team with the requisite amount of Agile Java development-fu to get the job done. What you need now is some hosted infrastructure so you can all get to work effectively.

In less than 30 minutes.

Step 1 – Get some IDE

Get Eclipse Galileo (JEE version). Hopefully your pipe is fat enough (~190 MB download). Fire it up and use update sites to obtain m2eclipse and subclipse (we’re assuming SVN for a repository, but you could use Git). Install Tomcat and configure as a server.

Step 2 – Get some Scaffolding

Within Eclipse go to File>New>Other, to open the Select a wizard dialog. From the scrollbox, select Maven Project and then click Next. Move through the wizard to select an archetype of an appropriate type (e.g. Appfuse). Click Finish. Validate you can build and deploy your app.

Step 3 – Get some Version Control

While you are waiting for your build to complete, pick a hosted version control provider. There are a number who provide low-cost or even free hosted Subversion for private projects, typically with a trial period. Here is a list. Once signed-up with a clean repository, use subclipse to share the scaffolding app created in (2).

Step 4 – Get some Project Tracking and Wiki

The majority of providers listed in (3) also offer something in the area of hosted task/issue tracking apps that often have sufficient wiki capabilities. Alternatively you can try those who specialise
in this area such as FogBugz or Agilo. We use Agilo on Mike. And you might want to get Basecamp. We use that too.

Step 5 – Get some CI

You could roll your own on Amazon EC2, but that isn’t happening in 30 minutes or 30 hours, probably! Hmmm…Oh I almost forgot – you could use our excellent hosted service ;).

Step 6 – Get some BRM

Whats a BRM? Its Binary Repository Manager. If you’re using Maven, I’d recommend you use one. The only hosted one I’m aware of is provided by Artifactory Online.

Right. We are good to go. What are you waiting for?

Eclipse Metadata Redundancy and Build Tools

November 10, 2009

As this recent blog post and subsequent discussion illustrates, the choice of build tool for Java projects can still provoke furious debate. As a long time user of both Maven and Ant, I’d like to think I have a good perspective on the various pros and cons of both of them. In fact, this perspective led to the creation of Kundo, an alternative open source build tool that sought to scratch both mine and others particular build management itches.

To use either Ant or Maven in anger you need a decent level of experience and understanding – particularly in the case of Maven. I’ve always viewed Maven as a ‘platform’ rather than a simple build tool as it aggregates/conflates a great many features. This means that the learning curve can be quite steep. I often encounter less experienced Java developers who wonder why working with these tools is so problematic – why do they need to contact the designated ‘build guy’ (or girl) when things don’t go according to plan?

More Data Than We Need?

lots of data!

Those who are familiar with the build tool domain will be aware of the ‘impedance mismatch’ that can occur between the metadata model used by Eclipse and that used by Ant, and especially Maven. In the case of Maven, this is because a POM file effectively needs to be the ‘master’ for project dependency metadata. Both the maven-eclipse-plugin and m2eclipse are good tools that seek to address this problem but I think its fair to say neither have yet completely eliminated the fundamental underlying issue. With Ant, the metadata synchronisation is simpler, but it still requires awareness from developers and they often have to be comfortable with Ant references and simple types to ensure changes in the IDE do not break the Ant build. Often Ant builds these days use either Ivy or the Maven Ant Tasks for dependency management anyway, so the problem can be much the same as with vanilla Maven in these types of projects. It is often not clear what the canonical metadata format should be and which tool ‘owns’ it.

Before I continue it is important to stress that I am focusing here solely on Eclipse, not alternatives such as NetBeans, IntelliJ etc that seek to address the problem in different ways.

Part of our mission with Mike is to lower the barrier of entry to using Continuous Integration (CI), so we have sought to include features that mean you don’t need to be a build tool guru to use our platform. Our ‘Eclipse build’ feature is a great example of this. It allows developers to simply add an Eclipse project to our hosted CI service without the need for an associated build.xml or pom.xml file. Then, at build time, Mike parses the project metadata and uses this within a vanilla life-cycle that processes resources, compiles production and test code, runs JUnit tests and creates an appropriate artefact. There are some constraints and conventions that need to be applied with this approach – at the time of writing the feature only supports the Dynamic Web project type using Apache Tomcat 5.5 or 6.0 runtimes – but here at Mike HQ we feel it allows you to be up and running with CI in very short order and we will be seeking to extend the range of project types, natures, builders etc that are supported. Of course, should you wish to subsequently own greater control over your CI build you can always add the appropriate Ant or Maven configuration at a later date and Mike will build that too.

From a pure CI perspective, this may seem to contravene the suggested approach in Martin Fowler’s original article – specifically the statement about IDE data being ‘fragile’. However, if all your developers are using a standardised version of Eclipse and apply a sensible approach to modifying the state of a project, many of the supposed issues can be avoided.

Aside from the Maven-specific tools mentioned above, it’s only fair to point out that there are other open source initiatives and projects that seek to address this same problem. In Kundo we sought to provide a ‘pluggable’ dependency management solution with one option allowing the use of Eclipse metadata as the source of your binary dependency locations. For this feature Kundo delegates to ant4eclipse. The aim of the ant4eclipse project is to avoid (or at least to reduce) the redundancy of Eclipse and Ant configurations and it consists of Ant tasks that are able to parse Eclipse metadata. More recently, the headlesseclipse project has emerged which seeks to solve the same problem by using the built-in AntRunner of Eclipse.

Finally, there is the B3 project proposal from the Eclipse community itself which, in their own words, has a goal to “develop a new generation of Eclipse technology to simplify software build and assembly”. I will be closely watching that proposal with interest to see if it finally addresses the build management metadata redundancy/synchronisation issue with Eclipse.