Java Application Delivery Package
The Application Delivery Package (ADP) approaches the problem of building Java software by providing the technical underpinnings for a set of development methods that enable development and operations teams to optimize build reliability, accelerate build speed, and capture and share build knowledge. ADP differs from simple script-based approaches to building software by defining, standardizing, and publishing the build process as a logically organized structured lifecycle. ADP's technology helps development teams effectively cooperate to create and deliver successful software projects consistently.
Laws such as Sarbanes-Oxley mean that compliance management has become a fact of life for application developers as well as corporate executives. Compliance management is placing greater demand on the systems and processes employed to develop software. Managing compliance requires that development tasks are consistent, documented and fully reproducible.
Application development presents a business problem when it is time to deploy the finished application into a controlled environment; how to ensure every application will be processed in the same consistent manner when developed by multiple application teams employing a variety of development tools. Integrated Development Environments (IDEs) are ideally suited for ad-hoc interactive activities by individuals performing software development. They are, however, ill-suited for performing repeatable, auditable processes.
While people new to the Application Delivery Package (ADP) concept tend to think of it as strictly a tool for builds, ADP actually offers a set of tools, including a Project Object Model (POM), a Model-View-Controller (MVC) pattern, user-defined plug-ins, and functionally rooted best practices, whose goal is to measurably improve software development processes as a whole, rather than simply enable builds to compile.
The key to building with ADP comes from how its tooling technology actually enables and reinforces development best practices across a team. ADP's goal, in terms of its tooling, is to provide a solid and cohesive technical framework that can mitigate some of the human factors that hinder software development. Once developers are relieved of the more mundane, time-consuming aspects of the build process, they can get on with the important work of creating value at the application level.
ADP arose from a very practical need to make all J2EE Web development projects functionally build in the same way in order to facilitate scripted deployments. Being able to support and maintain multiple projects meant that each developer needed to clearly know and understand how each of the individual projects worked. This meant that for every project a developer needed to build, he had to repeatedly decipher and learn not only how to build the project in question, but also become familiar with its related testing, documentation, reporting, and deployment practices.
Since all of the JEE Web development projects shared a number of build characteristics and lifecycle phases, ADP was developed to harness these commonalities. Given that all software projects need to be built, tested, packaged, documented, and deployed at the most base level - ADP was created to logically organize this build model and then orchestrate the process. Since there are also a great number of sub-functions possible at each phase of the build, test, package, document, and deploy lifecycle, ADP's build model lets users use plug-ins to meet build-specific requirements. But, at the same time, ADP constrains the overall build process to a single recognizable and repeatable model, creating a build framework (versus a build tool) that saves developers from having to (re)learn unique project builds time and time again.
