SAP Deployment with Ant

A few months ago, I wrote about our continuous integration system and how I’d hooked everything up to automate as much as possible. One of the key components of this suite of tools was a SAP NetWeaver Deployment Plugin for Maven that I wrote. Since then, I have received a few comments and queries about this plugin and have been asked whether it’s something we’re actively developing. I had intended on releasing it as an open source plugin (and may still do so at some stage), but in the meantime I have set up another option that has proven very useful – and that’s what this post is all about.

This time I’ve provided the documented Ant build file at the end of this article, which you are welcome to download and use for your own development.

How does it work?

Within the standard Maven project object model, you have the ability to define artifact repositories within the <distributionManagement /> section of the pom.xml file. Maven uses these settings to deploy the artifact that was generated during the build process – which, in our case, simply deploys them to Nexus. This makes it easy to reference the artifact in other projects and ensures that it is appropriately shared (either internally or publicly, depending on how you have configured it). It’s up to you to decide how and when you deploy to Nexus, but the point is that it is in a shared repository. This should be done for you as part of your release process if you use the Maven Release Plugin, although it can be manually uploaded too (either via Nexus or via the Maven Install Plugin / Maven Deploy Plugin). Now that we have our artifact in Nexus, we can simply download it whenever we need it. We don’t want to rebuild the sources to produce another copy of the already released artifact – we simply want to use the same compiled artifact that we originally produced.

We used Ant to create a build script – modelled on the sample script provided in the SAP NetWeaver CE 7.1 Developer Edition installation – that would allow us to run a deployment from anywhere to anywhere. The standard script provided by SAP is tied to the directory where it lives – which is not very useful, since we really don’t need a full NWCE installation just to fulfill a few dependencies. So we decided to combine one of the best features of Maven (dependency management) with the simplicity and clarity of Ant, and have produced a build script with no local ties. The next few sections will explain what you need to make this work and how to setup your environment (the script also includes some documentation).


You’ll obviously need to have Ant installed for this to work. In addition to this, you’ll need to download the Maven Tasks for Ant and copy them into your {ANT_HOME}/lib folder. The next thing you need is your own internal Nexus repository manager. This is technically not required, as you could simply install all dependencies locally – although it’s more realistic that you’ll want to use a shared repository for your team / company.

Once you have your Nexus repo manager configured, you need to deploy the SAP deployment JAR files to the 3rd Party release repository. These are not made available in any public repo, so you’ll need to host them yourself. I’ve outlined the details I used to upload the deployment libraries in our system, but you’re free to use whatever GAV parameters you like (so long as you update the Ant build file as well). You can find all of these files in the SAP installation directory – just look in the sample Ant script (in /usr/sap/LCL/J00/j2ee/deployment/scripts)¬†for the relative file locations.

JAR File Maven Artifact Definition

Note: I’ve used version 7.1.1 for all of these SAP libraries as I’m running NetWeaver CE 7.1 with Enhancement Pack 1 (more on how to check versions here).

When you run Ant with the build file, it will automatically resolve and download the dependencies via Nexus (using the Maven Tasks for Ant). So all you need to do is specify what you want to deploy / undeploy, and then let Ant & Maven do their thing. If in doubt, simply run Ant specifying the build file and the -projecthelp option.

Good luck, and I hope this has helped you!

Download: SAP Deployment with Ant


Code Reviews… One Month Later

It has been one month since we introduced formal code reviews as part of our development process, and I thought it fitting to do a review of the code reviews – effectively a Code Review Retrospective. Rather than creating a list of n reasons why you should be doing code reviews, I’m simply going to take you through our experiences over the last 4 weeks.

I guess the best place to start is to look at the goals I had for our code reviews. I’ve summarised them as follows:

  1. Improve quality [1]
  2. Share ideas
  3. Share knowledge of the code
  4. Share ownership of the code
  5. Mentor junior programmers

You’ll notice that most of these points can be summarised in one word… TEAMWORK!


I have already seen improvement in a number of these points in only a month. We have ensured that we always submit code for review before allowing it to be handed over for testing, and this has caught a variety of issues in the early stages of development. The issues we’ve identified so far range from subtle issues such as usability, terminology and coding standards to bigger issues such as EIS integration and design.

I also found that the code review process has stimulated more internal dialogue within the development team about how we should go about solving some of the user stories on our task list. As a result, we have achieved the goals of sharing knowledge and ownership of the code and sharing ideas. In turn, this has improved the quality of what we deliver to testing and ensured consistency in our approach as individuals within the same team.

When comparing code that has been reviewed against code that has not been reviewed, it is quite clear that the code reviews help us to deliver code in a consistent manner across the team. That’s quite a big strength in my opinion, as it means that we’re all playing by the same rules, abiding by the same standards, and finding consensus in our approach. Maintainability has improved because the code always looks familiar – so less time is spent figuring out what the last guy did before trying to fix a bug or develop a new feature.

Personal Benefits

I’ve found that I can keep a much better eye on our delivery by simply monitoring the code reviews. It gives me an incremental view of the changes to the codebase, and allows me to check that we’re meeting the standards we’ve set for quality, simplicity, maintainability, and so on. I think this is essential for any Tech Lead, and also achieves the goal with minimal interference. The productivity of the team should not suffer unnecessarily in order to meet standards – there is often a less disruptive way of achieving this.

What to try next

When we started the code reviews, we were unsure whether to do pre-commit or post-commit reviews. We decided to start with post-commit reviews, as this would be the least disruptive to a familiar development process and would allow us to focus on one new area at a time. Now that we’ve been doing code reviews for a while and have stabilised the process, I’m quite keen to try pre-commit reviews for a sprint or two. I’m sure there will be obstacles to overcome, but the best way to evaluate the two methods against each other is to try them both.

[1] There are many different views on what “software quality” means. I personally like the points outlined in Wikipedia: