Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
2 2 ICSM 2005 - Continous Refactoring of a Java Server Application
Introduction
IT20one GmbH was founded 2001 and is based in Vienna, Austria
Core business is electronic invoicing with digital signatures based on X.509 certificates
The Invoice20one Server was the first product – Add-on for ERP systems providing electronic invoices with
digital signatures – Implemented in Java and running on Windows and Linux – Consists of 17 subprojects and altogether 25.000 NCSS – Based on Jakarta Turbine web-application framework – Server functionality is implemented in terms of services – Services were intended to be reusable
3 3 ICSM 2005 - Continous Refactoring of a Java Server Application
The Bright Side of Success
The product portfolio was to be extended – Simpler but more focused applications for resellers – Reusing and extending the existing services without
breaking the code base – Testing and documentation was not adequate – No Daily Build and Smoke Test
Support of OEM distribution model – Distributors want to use their own branding – Affects the documentation regarding product names,
company logos and images
We did nothing wrong but not right either …
4 4 ICSM 2005 - Continous Refactoring of a Java Server Application
The Dark Side of Success
Invoice20one Server only used a small subset of Turbine’s services but many in-house services
Basically depending on Turbine’s service framework Jakarta Turbine not reusable across multiple projects
– Monolithic application depending on more than 30 libraries – Service framework functionality rather limited – Unable to extract the service framework implementation
Turbine Fulcrum and the Avalonic Wars – Decoupled service component repository for Turbine – Services are based on the Avalon Lifecycle Specification – Using two obsolete Avalon containers (ECM, Merlin) – Further development of Fulcrum was basically stalled
5 5 ICSM 2005 - Continous Refactoring of a Java Server Application
Roll your own Avalon Service Container?!
Yet Another Avalon Framework Implementation (YAAFI) provides a light-weight Avalon service container with minimal dependencies
YAAFI was contributed to the Fulcrum project YAAFI is now the backbone of our product portfolio Developing a IOC service framework is fun but a lot of work
Classes NCSS %Coverage %Comments
1.0.3 13 806 62 30,1
1.0.4 49 2.887 63 36,8
1.0.5 78 4.440 67 37,9
6 6 ICSM 2005 - Continous Refactoring of a Java Server Application
The Build Process Requirements
Full automation from CVS checkout to installer Excellent reporting capabilities regarding
– Source code changes – Regression tests – Coding problems – Library dependency conflicts
Documentation generated from XML And we need it for more than twenty projects …
Maven is your friend
7 7 ICSM 2005 - Continous Refactoring of a Java Server Application
The Maven Build Tool
Maven was initially developed for buiding Turbine
Maven matured into an open source software engineering platform
The core functionality is automated project building, distribution and project website creation
A project is described with a XML Project Object Model (POM)
The POM defines how to build a project and defines the external dependencies
The project build result are created in the local repository
Dependent JARs are downloaded from a remote repository
The Maven functionality is implemented in terms of plugins
The plugins are written in Jelly
8 8 ICSM 2005 - Continous Refactoring of a Java Server Application
The Maven Build Tool
9 9 ICSM 2005 - Continous Refactoring of a Java Server Application
The Maven Build Tool
10 10 ICSM 2005 - Continous Refactoring of a Java Server Application
The Success Story
During the last year fifteen Avalon services were migrated or newly written without breaking the Invoice20one Server
The YAAFI container and five services were contributed to the Jakarta community
The services including YAAFI consists of more then 15.000 NCSS and achieves statement coverage of more than seventy percent on the average.
Without Maven we would be either blind-folded or still working on an ANT build.
There is no free lunch ..
11 11 ICSM 2005 - Continous Refactoring of a Java Server Application
A Look Behind the Success Story
Implementation of YAAFI was unplanned work – Not to mention ongoing support and documentation
Battling the feature creep – Development and refactoring of application-specific services
are done in parallel
Keeping the automated build, regression tests and deployment process in a good shape ranges from a challenging to a frustrating task – No wonder that the job title “Build Manager” was invented
12 12 ICSM 2005 - Continous Refactoring of a Java Server Application
The End
Any questions !?
13 13 ICSM 2005 - Continous Refactoring of a Java Server Application
Related Links
http://avalon.apache.org/
http://jakarta.apache.org/turbine/fulcrum/
http://maven.apache.org
http://maven-plugins.sourceforge.net
http://jakarta.apache.org/turbine/
14 14 ICSM 2005 - Continous Refactoring of a Java Server Application
The Maven Build Tool
The Local/Remote Repository
15 15 ICSM 2005 - Continous Refactoring of a Java Server Application
The Maven Build Tool
Maven in a Corporate Environment
16 16 ICSM 2005 - Continous Refactoring of a Java Server Application
The Maven Build Tool
Multi-Location Setup
17 17 ICSM 2005 - Continous Refactoring of a Java Server Application
Inversion Of Control
18 18 ICSM 2005 - Continous Refactoring of a Java Server Application
The Documentation Trap
Documentation was traditionally written using Microsoft Word – Binary und proprietary document format – No separation of content and layout – Enforcement of corporate layout difficult
Migrating the documentation to XML – Project documentation written in XDOC which is directly
transformed to HTML and PDF by Maven – External documentation is either written with OpenOffice or
currently migrated to DocBook – DocBook is transformed to PDF and HTML using optional
Maven SDocBook plug-in