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:

http://www.cqblueprints.com/xwiki/bin/view/Blue+Prints/CQ+Development+Team+Server+%22In+A+Box%22

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: http://www.cqblueprints.com/xwiki/bin/view/Blue+Prints/Using+Nexus+as+a+Maven+Repository+for+CQ+Team+Development

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.

VMware Delivers Micro Cloud Foundry, Bringing the Industry’s First Open PaaS Directly to any Developers’ Mac or PC

Posted in: Cloud Computing

Cloud Foundry delivers access to modern, high productivity frameworks and a rich ecosystem of application services from VMware, third parties and the open source community. A complete version of Cloud Foundry that runs on a developer’s Mac or PC, Micro Cloud Foundry lets developers build end-to-end cloud applications locally, without the hassles of configuring middleware while preserving the choice of where to deploy and the ability to scale their applications without changing a line of code.

via VMware Delivers Micro Cloud FoundryTM, Bringing the Industry’s First Open PaaS Directly to any Developers’ Mac or PC.

Remote Debugging Elastic Beanstalk with the AWS Toolkit for Eclipse

Posted in: Cloud Computing

Learn to use the AWS Toolkit for Eclipse to easily configure Elastic Beanstalk for remote debugging.

Deploying 3rd Party Libraries to Adobe Communique

Posted in: Enterprise Java, Software Development Best Practices

I just published a new Blueprint over on cqblueprints.com that details how to easily deploy 3rd party libraries into your CQ environment, even when those libraries do not contain the necessary OSGi entries in the Manifest file.

CQ is built on top of Apache Sling, and Apache Sling is built on top of an OSGi container (Apache Felix specifically).

OSGi containers behave slightly differently (in terms of how classes are loaded and made available on the classpath) than most Java developers are used to.

To be able to make classes available within the OSGi container, Jar files need to be packaged in a specific way, including adding extra meta-data to the standard MANIFEST.MF file. The problem this can create is that libraries created by other developers that have not been built with OSGi in mind are missing this extra information and so their Jar files cannot be deployed in CQ.

This Blueprint details how to easily and reliably expose non-OSGi enabled libraries in CQ.

See Deploying 3rd Party Libraries

Building and Deploying OSGi Bundles on Adobe Communique

Posted in: Enterprise Java

I just published a new Blueprint over on cqblueprints.com that details how to easily build and deploy OSGi bundles into your Adobe Communique server.

CQ is built on top of an OSGi container and as a result custom code and functionality can be added to CQ through the features provided by OSGi. To be able to deploy custom code into an OSGi container, developers must package their code as a bundle. An OSGi bundle is simply a Jar file that has had extra meta data added to it. This Blueprint details how to create an OSGi bundle using Apache Maven and how to deploy that bundle into a running CQ instance.

See Building and Deploying OSGi Bundles

Cloudbees lands $10.5M to move Java development into the cloud

Posted in: Cloud Computing

CloudBees, which offers a Java platform as a service (PaaS) for developers, has raised $10.5 million in a funding round led by Lightspeed Venture Partners.

CloudBees was founded by Sacha Labourey, the former chief technology officer of JBoss. Its first investors included JBoss founder Marc Fleury. Kohsuke Kawaguchi, creator of Hudson, the most popular continuous-integration tool in the Java world, also works for the company, making CloudBees something of a Java dream team.

via Cloudbees lands $10.5M to move Java development into the cloud | VentureBeat.

What’s Next in Continuous Integration?

Posted in: Enterprise Java, Software Development Best Practices

Kohsuke Kawaguchi discusses the future of Continuous Integration and Jenkins as they will be influenced by virtualization, cloud computing, DVCS and analysis software.

via InfoQ: What’s Next in Continuous Integration?.