Version 1.0.4 of the CQ Blueprints Maven Archetype Available

Posted in: Enterprise Java, Software Development Best Practices

I’m happy to announce the release of version 1.0.4 of the CQ Blueprints Maven Archetype.

The CQ Blueprints Maven Archetype can be used to bootstrap a fully Apache Maven enabled, multi-module, Adobe CQ project. By using the generated Apache Maven project you no longer need to use tools such as CRXDE and can instead develop and work in a tool like Eclipse and simply build and deploy to a running CQ Server using common Apache Maven commands.

This new release fixes several reported bugs, and adds complete examples of best practices for writing JSPs and custom tag libraries and integrating these with OSGI services.

Visit the CQ Blueprints site for further information about the CQ Blueprints Maven Archetype.

Remember, if you need assistance with your current or future Adobe CQ project, don’t hesitate to contact myself directly or alternatively contact Ruben Reusser and the team at Headwire who generously provide the CQ Blueprints project.

Using Nexus as a Maven Repository for CQ Team Development (Updated)

Posted in: Enterprise Java

I just finished doing a major update to the CQ Blueprints page about using Nexus as a Maven Repository for CQ development. The Blueprint now demonstrates how to make use of the repository that Adobe has recently made available.

Customers who wisely choose Maven as their build tool should setup their own Maven Repositories and configure them to proxy the repository to provide access to the CQ related artifacts for your team. Some possibly outdated documentation on the Day/Adobe sites recommends installing and using Apache Archiva as your local repository. However, since Nexus is now being used actively to manage the Maven Central repository it has become the defacto standard for Maven Repository management tools. As a result, we recommend the use of Nexus over any other Maven Repository management tools, including Archiva.

via Using Nexus as a Maven Repository for CQ Team Development Blue Prints.Using Nexus as a Maven Repository for CQ Team Development – XWiki.

CQ Development Team Server “In A Box”

Posted in: System Administration

Just wrapped up a project with the Headwire team to create an example server environment for getting up and running with a new CQ project quickly. The server has all of the elements needed for a CQ development team like Subversion, Nexus and Jenkins already installed, configured and integrated. There are also instructions for setting up your CQ environment, including deploying the CQ binaries into Nexus and making them available to your Maven builds.

The server is packaged as an Open Virtualization Archive file, so you should be able to import it into most virtualization tools (VirtualBox, VMware etc).

Check out the documentation here:

Using Nexus as a Maven Repository for Adobe CQ Team Development

Posted in: Enterprise Java

I just finished writing another Blueprint over on the CQ Blueprints site. This time I talk about how to go about setting up and using Nexus as your team’s Maven Repository when working with Adobe CQ (now Adobe ADEP / CEM).

Check it out here:

How To Easily Deploy Pre-Packaged Maven Artifacts

Posted in: Enterprise Java

The Maven deploy:deploy-file goal is very useful for deploying JARs (and other artifacts) that have not been mavenized, to your own repository. It allows you to pass Maven coordinates and other Maven related meta data on the command line so that the artifact ends up in the right spot in your repository and has at least the bare minimum of Maven meta data associated with it to make it useful. Unfortunately, one less common scenario it does not currently handle is deploying an already mavenized artifact to a repository. I recently ran into this exact issue while doing some work for a client, so I put together a script to bridge the gap.

Continue reading »

Heroku vs OpenShift – The Battle of the JavaEE FUD

Posted in: Cloud Computing, Enterprise Java

On the same day that Heroku announced its new support for Java based applications, it also curiously posted a laundry list of FUD about the JavaEE platform. Don’t get me wrong, I share some of Heroku’s complaints, but calling out the shortcomings of the JavaEE platform by linking to documentation related to obsolete versions did not help give Heroku’s arguments credence. Last I checked, the Jetty server, which Heroku’s Java platform is based on, quite clearly states that it is a Java Servlet container, and the Java Servlet specification is part of the JavaEE family of specs. So the specs that Heroku derided are in fact the same specs that their product is running on a subset of. Interesting tactic.

Of course, the RedHat team with their OpenShift platform (that does in fact support a full JavaEE stack) managed to take the Heroku post personally and responded in a less than dignified fashion. Why RedHat felt they needed to respond at all is the first question that comes to mind. The Heroku post does not call them out by name. The level of animosity in the Redhat response makes me wonder if there is bad blood between these teams.

Personally I have real concerns about Heroku’s model of non-conformance to the JavaEE specifications. There is a wealth of knowledge and code out there based on those specs (irregardless of how flawed they may be), so expecting people to do some heavy lifting to port their existing standard Java code to run on your platform is a big ask. The tools out there (from IDEs to builders like Maven and Ant to CI environments like Hudson) are entrenched in every team and on every developer’s box. Where do you hire Java Heroku developers from exactly anyway? Now, you could argue that Heroku’s model is not that different from standard JavaEE, but the fact that it is different at all is the problem. As one commenter on Heroku’s post said “Any reason you didn’t simply allow for uploading of a .war?“. Precisely.

OpenShift has its own set of issues as well though. I cannot recall the last time I worked on a project that actually required a full JavaEE stack. I don’t think I have a JBoss or WebLogic environment on any computer I own currently (and I definitely don’t have WebSphere, that’s for sure). What I do have is about 3 different versions of Tomcat with multiple applications deployed on each. I also have a couple of packaged pieces of software installed that actually run Jetty internally. Perhaps it’s just the kinds of projects I work on, but I suspect I am most likely in the majority. Probably even more so if you looked at all the Java apps that are deployed on full JavaEE stacks out there, that could actually be deployed into a servlet container with no code changes. Arguing that a full JavaEE stack is an essential and technically superior solution when you are a vendor of such a stack (ie. JBoss) doesn’t really give your argument much objective weight.

So, JavaEE is not what it was even 5 years ago, it has gotten a lot better and has evolved via a variety of means, one of the biggest being watching what the community does to work around the JavaEE shortcomings (see Hibernate etc).

That said, a full JavaEE stack is not the answer to every problem, maybe not even a majority of problems.

As with most things in life, the middle ground is probably where the truth will be found. A non-standard Java platform is probably not the right answer, but then again a full JavaEE stack is probably not either. IMHO, as far as I can see right now, the sweet spot in the Java PaaS space are the vendors that allow developers to work as they have been previously – allow them to use the tools they know, the development workflow they know and the architecture they know. Based on that, I think Amazon’s Elastic Beanstalk and CloudBees RUN@Cloud are probably on the right track.

NetBeans 7 Is GA

Posted in: Enterprise Java

The GA release of NetBeans 7 has finally been released. You can read about the improvements and download it here:

The features I am most looking forward to:

  • Maven 3 Support
  • Java 7 / Project Coin Support


Posted in:

I am a full-time consultant who is available to engage with clients remotely or onsite anywhere in the world (I currently hold dual-citizenship between Australia and the United States).

To discuss your specific needs, please call me on +1.650.336.5877, or email me at, or use this Contact form, or download a copy of my resume from this page.

The following is an overview of the services I provide to clients:

Software Development Process Improvement

  • Coaching for Agile process evaluation, adoption or improvement, including Scrum, Lean, Kanban and Extreme Programming (XP)
  • Definition, refinement and documentation of team processes and practices
  • Definition of Quality Assurance and Quality Control standards
  • Integration of defect tracking systems with other tools and processes
  • Engagement with customers and requirements elicitation

Software Development Team Management

  • Job Description authoring
  • Salary range and benefits package definition
  • New candidate acquisition and screening
  • Team workspace design and office space evaluation
  • Skills assessment of existing resources
  • Collaboration strategies for teams

Vendor Management

  • New vendor discovery and screening
  • Vendor proposal reviews
  • Offshore vendor management, including onsite visits and reviews
  • One throat to choke multiple vendor management

Software Configuration Management (SCM)

  • Introduction of an SCM system to teams not already using one (Subversion, Git, CVS etc)
  • Subversion and CVS training
  • Subversion and CVS server installation and configuration
  • SCM process definition and documentation, including branching and merging processes
  • SCM system migration, particularly CVS to Subversion

Build Management

  • Implementation of Apache Maven and Apache Ant based build systems
  • Automation of builds, particularly in relation to a Continuous Integration system like CruiseControl or Hudson
  • Management and versioning of produced code artifacts, particularly in relation to an Artifact Repository like Nexus or Artifactory
  • Release numbering strategies and Alpha and Beta customer release programs

Software Architecture & Design

  • Enterprise-level system architecture definition, existing architecture reviews
  • New database design and existing database design review
  • Formal UML based architecture definition

Enterprise Java Development

  • Specialist in full-stack JavaEE development
  • Public API design and documentation for ISVs
  • Web service development and integration
  • Code reviews and performance tuning
  • Service Oriented Architecture (SOA) design and implementation

Web Development

  • HTML, JavaScript and CSS development
  • Integration of AJAX style JavaScript libraries including GWT, JQuery and ExtJS
  • Integration of Adobe Flash and Flex components

Automated Testing Strategies

  • Introduction of tools like JUnit and Sellenium to teams that currently do not do any automated testing
  • Integration of tests into automated build scripts and generation of metrics
  • Static analysis of codebase quality

Mobile Development

  • iPhone application design and development, specializing in integration to JavaEE based back ends
  • Web based mobile development

Social Media Strategy

  • Specializing in small to medium business that do not have dedicated in house Social Media resources
  • Evaluation of current Social Media presence
  • Recommendations for Social Media platforms based on particular business needs and goals
  • Evaluation of Location based services in relation to business needs and goals

Once again, to discuss your needs and to find out how I can help you, please contact me by phone on +1.650.336.5877, by email at, or simply use this Contact form. If you would like more detailed information regarding my experience and qualifications, you can download a current copy of my professional resume from this page.

The Problem with Maven Releases and Continuous Integration

Posted in: Enterprise Java

I mentioned in a meeting recently that I would like to find a better way to make releases with Maven by leveraging CruiseControl (or another CI tool) to save us work and as a result time.

The main problem currently is created because of the flexibility of using Maven’s SNAPSHOT dependency mechanism. Currently when CC does a build, it just creates a simple SNAPSHOT build and does not change the pom file at all. This is a good thing, as it pushes the latest code out to the shared repository and then when developers do their next build they automatically get the latest code, even if they are not working directly on that project.

The down side is that the builds created by CC are not formal releases and so are not ready to go to QA or production. When we do want to move something to QA we have to stop and do a manual release, and then a second manual release for Production. This is caused by a few reasons:

  1. Currently when CC does a build there is no tag applied to our CVS repository to mark the build, which means the build is not repeatable. This is intentional currently, since there is really no need to be able to repeat a SNAPSHOT build. This can easily be solved though, we can have CC apply a tag, but that still leaves the next issue which is more significant.
  2. Because CC is making a Maven SNAPSHOT build, it does not resolve the SNAPSHOT dependencies to other projects, so the build is still not repeatable, even if we had a CVS tag applied.
  3. The QA releases are tagged/named with suffixes like 1.0.0-rc## (for release candidate) or 1.0.0-beta## (where the #s are numbers indicating iterative releases to QA are being made) to clearly indicate they have not passed QA yet.
  4. Because the QA releases are tagged/named in such a way a whole second release needs to be done to clean up the tag/name to just something like 1.0.0

Here is what I think needs to happen instead:

  1. We continue to have CC create and publish SNAPSHOT builds to the shared repository, just as it does now, no changes.
  2. We add an extra step to the CC build that (on a successful build) tags CVS, then creates a branch based on that tag.
  3. It then does a checkout on the newly created branch.
  4. It then updates all of the pom.xml files where SNAPSHOT versions are used in dependencies to other projects/plugins etc. More on these updates in a second.
  5. It then checks those updated poms back into the branch.
  6. It then does a proper Maven release on that branch and publishes that to the shared repository. That is the end of life for that branch, it only exists to allow the release to be made, nobody would ever use this branch directly.

So, for regular development work, nothing changes, you would continue to use SNAPSHOT versions where appropriate. But, we now no longer need to do a special release when we go to QA, and in addition, if a QA build gets approved, it can go straight to production, we do not need to do a special production build anymore.

This all sounds good, but the tricky part is the “updates the poms” part that I mentioned above in the 4th bullet point. I do not think this functionality exists today in Maven.

So here is how I think it would work:

  • We change to use build numbers that look like this “<major version>.<minor version>.<micro version>.<build number>” – the big difference is the “build number” part. Whenever there is a successful CC build, this number gets incremented. One of these releases with a unique build number will be given to QA. If QA approves that build number, that same build number goes to production.
  • Once a build goes to production, the major, minor and/or micro version numbers get incremented (just like we do now), and the build number automatically rolls back to zero.
  • When CC does a build, it examines the pom file of the project for dependencies to other projects/plugins that are SNAPSHOT versions. It then looks in the shared repository for the latest build number of those artifacts and changes the pom to depend on that specific build number instead of the SNAPSHOT. For example, if CC finds a dependency to version 1.0.1-SNAPSHOT of artifact-X, CC goes to the shared repository and finds that the highest build number for that release is, so it changes the dependency in the pom to be that release number.
  • CC continues until there are no SNAPSHOT dependencies left.
  • Now CC checks in the updated pom (or poms plural if it is a multi-module project) into the branch.
  • Now CC just does a normal Maven release based on the branch and deploys the release to the shared repository. However, it needs to determine the correct build number for the main project being released. Basically this is the same algorithm used to determine the highest build numbers for all of the dependencies that we just finished. Except this time when we find the highest existing build number, we add 1 to it and use that for the release process.
  • The Maven release process finishes with the project in question being released with an incremented build number based on a branch in CVS. The trunk is unchanged, hence the normal SNAPSHOT releases continue as before.

That’s it.

Now I see the Maven release plugin has had some updates in recent releases with features like the non-interactive build now being possible by passing build numbers on the command-line. But I do not see any mention of the type of functionality I outlined above.

Am I just missing it, or is there a project out there for us to sink our teeth into?