Ant to Meister conversion is not required

Don’t believe that an Ant to Meister conversion is needed to move to Meister Build services

Our competitors would like you to believe that an Ant to Meister conversion is required to use Meister.  It is a common question that we hear,  “how long does it take to convert my Ant Scripts to Meister?”  The answer is there is really no requirement to “convert” Ant to Meister. Meister will do that for you by referencing the most accurate information found in the Eclipse Project files.  Ant Scripts can do many steps including calling version control and executing a deployment.  If these kinds of steps are in your Ant scripts, you will need to define a Workflow that will call these steps in the correct order.  Meister has, “out of the box”, calls to common activities that are included in Ant Scripts from calling version control tools to static testing and deployment.  You will end up creating a workflow that performs the same steps as your existing Ant Scripts.

For the core of the Ant script, the compile process, Meister will use your Eclipse Project files to generate the “ant” like process for creating your jars, wars, ears.  An Ant to Meister conversion is a misunderstanding of how Meister is configured.  Meister uses Targets instead of a script of any type. Instead of manually creating Targets, you can automatically generate them using your development IDE.  If you are currently executing builds using Ant or Maven scripts, and you use an IDE, you are not required to reference your existing static scripts in order to use Meister.    Meister can automatically generate your Targets based on the IDE Project file using the Eclipse plug-in.  This is the preferred method, as your IDE Project file is the most accurate reflections of how your Java component is built, therefore automatically generating the Target based on the Project file will provide the most accurate results.

In addition, by automatically generating your Java Targets via your IDE, you can improve your Continuous Integration process.  By auto generating your Targets you can synchronize the builds performed inside of the Eclipse IDE with the builds running outside of the Eclipse IDE.  This synchronization resolves changes made to the source code that has impacted the build scripts running outside of the IDE such as the case with refactoring, adding libraries, or changing compile options.

The OpenMake TGT Generation Plug-In integrates with Eclipse, IBM Rational Application Developer, IBM Rational Software Architech, MyEclipse, Weblogic Workshop, IBM WebSphere Studio Application Developer, and CodeGear.

When using the Target Generator, Targets are automatically generated and maintained by the Plug-In.  The Plug-In can be configured to automatically create and update .tgt’s when:

A file is added or removed from a referenced Eclipse project

Referenced Eclipse project properties such as Java Build Path are updated

Developers choosing to use the Eclipse plug-in should first setup the configuration of the Eclipse Target Generator.  Once your configuration has been setup you can then define a Project and Dependency Directory and configure their Eclipse projects to use the Target generation and build features.   Note:  To validate that you have the Eclipse Target Generator already installed simply view the list of plug-ins available from the Eclipse IDE.  If the Meister Eclipse Target Generator is installed you will see “OpenMake TGT Generator” in the list.



Ms. Ragan has had extensive experience in the development and implementation of DevOps for large organizations. She began her consulting career in 1989 on Wall Street specializing in build, testing and release management for the distributed platform. It was during her consulting experiences that Ms. Ragan recognized the lack of standardized development procedures on open systems that were common on the mainframe. In the years leading to the creation of OpenMake Software she worked with development teams in implementing a community driven standardized build and deploy process that enabled frequent builds and releases, automated around version control. Her knowledge and experience contributed to the creation of OpenMake Meister, the first commercial Build Automation solution. Ms. Ragan served on the Eclipse Foundation Board of Directors as an Add-in Provider Representative for 5 years. She has been published on numerous occasions and regularly speaks at conferences including CA World where she presented for 15 consecutive years. She holds a BS Degree in Business Administration, Computer Technology from California State University, Pomona.

Related Posts


Accelerated Builds – are they fact or fiction?

Accelerated builds – critical to agile development Accelerated builds for continuous integration Accelerated builds have been a topic for OpenMake Software since Meister was first created. The October 2013 issue of SD times has an article Read more...


7.5.1 Continuous Delivery Suite Now GA

Free Continuous Delivery ready for GA OMS improves upon Continuous Delivery in 7.5.1 Release Our 7.5.1 Continuous Delivery suite including both Meister and Release Engineer is now GA! This includes a Jenkins Plug-in for Release Read more...


Component packaging for Continuous Delivery

Component Packaging for easy software deployment Release Engineer helps you with Component Packaging Component packaging is the lowest level of assembling together the artifacts to be used in your software release. Release Engineer starts your Read more...