• Embed Doc
  • Copy Link
  • Readcast
  • Collections
 
ENTERPRISE SOFTWARE DEVELOPMENT
Introduction
Effectively managing the software development lifecycle (SDLC) has become more challenging than ever.There are many reasons for these circumstances, including the widespread adoption of open source, theincreasingly complex structure of modern software applications, and the progressively more diversemakeup of project teams.This White paper describes the software development predicament that IT organizations encounter today,as well as how Maven is helping many enterprises surmount these formidable obstacles. In addition,we’ll see how Sonatype has created a suite of value-added products that augment Maven with additionalenterprise-class capabilities.
Software Development Challenges Today
Before exploring the particular benefits that Maven brings to the process of building and deploying soft-ware, it’s useful to examine the underlying factors that have contributed to the rise of this technology.We’ll also explore how legacy solutions have not been able to keep up with the challenges that Mavenelegantly resolves.
Building software has gotten more complex
In the past few years, software development environments have become significantly more pow-erful and complex, offering previously unimaginable capabilities to the average developer. Theseprofessionals have put this capacity to work, designing and developing feature-rich applicationsfaster than ever before.However, all of this potential and flexibility comes with its own set of unique challenges, as item-ized below:•Highly modular applications translate into a much more complex build, test, and deploymentprocess.•In addition to internally-developed software, modern applications often make extensive use of externally-developed software components, known as artifacts. Artifacts may be provided bycommercial vendors, or they may be open source.•A given artifact is commonly dependent on other artifacts. These affiliations, known as transi-tive dependencies, are often difficult for external developers to understand and support.
The Maven Company
800 W. El Camino Real, Suite 400, Mountain View, CA•telephone: +1 (650) 248-2919•fax: +1 (650) 472-9197•www.sonatype.com
 
•Whether provided by commercial vendors or open-source initiatives, artifacts often introducesignificant licensing challenges.•Agile software development, incremental deployment, and frequent integration have all re-sulted in many more builds over the life of a software deliverable.In spite of all the aforementioned challenges and complexities, the portion of the average IT budget dedicated to the software build, test, and deployment process has not grown. Instead,developers are often expected to preside over these increasingly intricate responsibilities withoutany outside assistance. Unfortunately, it’s beyond the skill set of the average developer to manageall of this complexity. Delayed deliverables, buggier solutions, and higher maintenance costs are but a few of the results of this gap between skills and expectations.
Software development teams have changed
 Just as software has become more feature-rich and intricate, and delivery expectations more ag-gressive, project teams are more sophisticated now as well. In the past, the members of a softwaredevelopment team often worked together in the same department, typically located in the same building. Things are very different today. For internally maintained software, mergers and acqui-sitions have resulted in more distributed teams, while the increasingly popular round-the-clock software development process, often aided by outsourcing, mandates developers in multiple timezones frequently speaking different languages and following varying practices. Open source andcommercial artifacts are maintained by external personnel, often located halfway around theworld.The result of the increased complexity of software development and project teams is that thesoftware build process can take much longer to complete, is much harder to standardize, and issignificantly more error prone. As we’ll see next, however, existing technologies have not metthese challenges.
Current software build management technology hasn’t kept up
Given the headaches caused by all of the realities and challenges described so far, developershave grown increasingly disillusioned with legacy software build technologies. Expensive, pro-prietary, heavyweight solutions from established vendors such as IBM/Rational are often priced beyond the reach of today’s IT organizations. Even when cost isn’t an issue, these products re-quire extensive consulting expertise for tasks as simple as a basic proof-of-concept. To make mat-ters worse, these packages continue to view the software build process as primarily involving thecompilation of source code, thereby neglecting the realities of artifact-based software, the opensource movement, and the special complications introduced by continuous integration and in-cremental builds.
Sonatype, Inc.2
 
While outright software licensing charges are not an issue, lightweight build technologies such asApache Ant and Gnu Make have their own drawbacks. They can be very convoluted to config-ure, especially when factoring in the complications of modern, artifact-driven software projects.While they are very flexible, this adjustability is a double-edged sword: all of these options oftenlead to developer confusion resulting in difficult to maintain “one-off” build scripts that keep thelearning curve steep for new team members.
Introducing Maven and Sonatype
In response to the insufficiencies of existing software build technologies, Maven was created tohelp developers overcome the headaches inherent in modern software construction. This has al-lowed these professionals to focus on their primary software design and development responsi- bilities. Maven is part of the Apache Software Foundation family of open source initiatives. Thereare dozens of active Apache projects, adding value across the entire spectrum of computing chal-lenges. Some of the best known Apache endeavors include:•Tomcat•Struts• JakartaIn fact, Maven was originally created to help streamline the software build process for the Apache Jakarta Turbine project. While Java was the initial programming language of choice for Mavenprojects, there are now many other available development options.Maven directly surmounts the faults of existing heavyweight and lightweight build solutionstechnologies. In contrast with the current breed of expensive, bulky offerings, Maven is far easierto install and use. It also embraces the reality that the build process is made up of much morethan simply compiling source code. Finally, Maven is not a closed system. Instead, it’s designedfor easy extensibility, which has spawned a healthy ecosystem.Lightweight solutions are missing many of the essential capabilities found in Maven, including:•Conventions•Models•Processes•Coherence
Sonatype, Inc.3
of 00

Commenting has been disabled.