Software Development Macro and Micro Process

If you think that in year 2012 all companies which produce software and IT divisions in our world have already their optimized software development process, you are wrong. It seems that we - software architects, software developers or whatever your title is - still need to optimize the software development process in many software companies and IT divisions.

So what do you do if you enter a software company or IT division and you see following things:

1. There is a perfect project management process to handle all those development of software but it is a pure project management without a context to software development. So basically you only take care of cost, time, budget and quality factors. In the software development you still use the old fashioned waterfall process.

2. From the tooling point of view: you have a project management planning and controlling tool but you are still in the beginning of Wiki (almost no collaboration tool) and you don't use issues tracking system to handle all the issues for the development of your software components and applications. You use Winword and Excel to define your requirements and you cannot transform them to your software products since you don't have any isssues tracking system. No chance to have traceability from your requirements down to your issues to be done in your software components and applications.

3. Maven is already used but with a lot customization and not intuitively used. The idea of using a concrete already released version of dependencies was not implemented. Instead you always open all the dependently projects in Eclipse. You can imagine how slow Eclipse works since you need to open a lot of projects at once although you only work for one project. Versioning in Maven is also not used correctly e.g.: no SNAPSHOT for development versions.

4. As you work with webapp you always need to redeploy to the application server. No possibility to hot deploy the webapp. Use ctrl-s, see your changes and continue to work without new deployment is just a dream and not available.

Luckily as an experienced software architect and developer we know that we can optimize the two main software development processes:

1. Software Development Macro Process (SDMaP): this is the overall software development lifecycle. In this process model we define our requirements, we execute analysis, design, implementation, test and we deploy the software into production. Waterfall process model and agile process model like RUP and Scrum are examples of SDMaP.

2. Software Development Micro Process (SDMiP): this is the daily work of a software developer. How a software developer works to develop the software. A software developer codes, refactors, compiles, tests, runs, debugs, packages and deploys the software.

More information on SDMaP and SDMiP:

• You can find the definition of SDMaP and SDMiP in the context of analysis and design in the book  Object-Oriented Analysis and Design with Applications from Grady Booch, et. al.
• Unifying Microprocess and Macroprocess Research 
• Effects of Architecture and Technical Development Process on Micro-Process

The picture below shows the SDMaP and SDMiP in combination. The macro (SDMaP) and micro (SDMiP) process meet at the implementation phase and activity. So changing and optimizing one has definitely side effects on the other one and vice versa.

At the example of organization mentioned above it is important that we optimize both processes since they work hand in hand. So how can the optimization for macro and micro process looks like?

1. SDMaP:

• Introduce Wiki for IT divisions and software companies. You can use WikIT42 to make the structure of your Wiki and use Confluence as your Wiki platform.
• Introduce Wiki with issue tracking like JIRA and combine both of them to track your requirements.
• Refine the requirements into issues (features, tasks, bugs, etc.) to the level of the software components and applications, because at the end you will implement all the requirements using your software components and applications.
• Introduce iterative software development lifecycle instead of waterfall process. This is a long way to go since you need to change the culture of the company and you need a full support from your management.

2. SDMiP

• Update the Maven projects to use the standard Maven mechanism and best practices with no exception. Transform the structure of the old Maven to the new standard Maven using frameworks like MoveToMaven. 
• Use Maven release plugin to standardize the release mechanism of all Maven projects.
• Use m2e Eclipse plugin to optimize your daily work as a software developer under Eclipse and Maven.
• Use Mylyn to integrate your issue tracking system like JIRA into your Eclipse IDE.
• Introduce JRebel to be able to hot deploy quickly your webapps into the application server.

Optimizing macro and micro process for software development is not an easy task. In the macro process you need to handle all those relationships with other divisions like Business Requirements, Quality Assurance and Project Management divisions. You need to convince them that your SDMaP optimization is the best way to go. This is more an organizational challenge and changes than the micro process optimization.

The micro process is also not easy to optimize, since you need to convince all developers that they can be more productive with the new way of working than before. You need to show them that it is a lot more faster if you don't open a lot of Java projects within your Eclipse workspace. Also using JRebel to deploy your webapp to your application server is the best way to go. Normally developers are technical oriented, so if you can show them the cool things to make, they will join your way.

New Article about MDA at heise.de

Checkout my newest article about Model Driven Software Development with UML and Java at heise.de (in German language): Modellgetriebene Softwareentwicklung mit UML und Java - Besser als der Ruf.

Model Driven Software Development with UML - Back to the Root (or how KissMDA saves our Agile Development with Java...)

After working since 2004 with MDA (Model Driven Architecture) / MDSD (Model Driven Software Development) technologies like AndroMDA, oAW, etc. always in context of Java technology and UML (Unified Modelling Language) I feel like that we need just another MDA tool. Why?

Past 

The first experience with AndroMDA in the year of 2004 was great! At the end you don't need to code those boiler plate codes in EJB 2.x. AndroMDA generates everything for you. You also have the documentation of your application always up to date. This is a very important thing, since if you have more than one hundred entities you definitely need that actual documentation to be able to extend the application. AndroMDA offers a lot of mature cartridges like EJB 2.x, SpringFramework, Struts, Hibernate, JSF. The idea with cartridges is just gorgeous. IMHO it is possible to have a general application architecture for most business applications. So if you are using SpringFramework and Hibernate you can reuse the already written cartridge and you don't need to write your own cartridge. I see no case for your own "architecture" and your own cartridge especially in the area of business applications. This is one of the best thing AndroMDA did for us.

oAW has a different story. There is no reusable cartridges because every persons and companies should build their own architecture and cartridges. This is not a good idea. This is just like when you say that you need your own database system for your "simple" business application.

In year 2006 - high noon of Model Driven Software Development with UML - I thought that we are going into the next level of component reuse in the software development: UML model reuse! Just like what openCRX (Open Source CRM application) has done with their own model driven development tool. But this dream is still a dream until today.

Present

1. I still like AndroMDA, yes the project is very much alive and it has already proven itself to be a strong Open Source project, since AndroMDA has survived the come and go of its comitters. AndroMDA is IMHO the best project in MDA / MDSD area sofar. One problem I see is the complexity of the project. Yes, you need to model the cartridge to build your own cartridge. In the beginning this looks like "eat your own dog food" but at the end it makes the things much more complex to build. Just take a look how you can build your own cartrige in AndroMDA. You also need to use a lot of XML files and elements to configure your cartridge. As an application developer you need all those XML elements to be able configure AndroMDA which makes AndroMDA a configuration monster.

2. oAW has a different story. Until the version 4.3 it seems everything looks very smooth. After the project went to Eclipse it seems that the project has no activity anymore. No news anymore from oAW 5 release. It's really a pitty. The big problem of oAW is also its Domain Specific Language (DSL) Xtend und Xpand (remember: Polyglot Programming sucks!). Since they depend on their own editor capabilities in Eclipse and because the project seems to be dead, you will definitely stuck with Eclipse 3.4! No development anymore in the future.

3. Acceleo is new kids on the block and looks pretty nice. The project is active and alive. The main problem is that it uses a DSL called MOFM2T (MTL) to generate artifacts. You can read the getting started document of Acceleo to understand how Acceleo generator works. Additionally everything in Acceleo is quite Eclipse centered. So you need the MTL editor from Eclipse, imagine if something happens just like oAW. You will stuck with an old Eclipse version!

There are some other MDA / MDSD tools available outside: Taylor, Topcased, openMDX, etc. But all of them suffer the problems I mentioned above.

Experiences and Advantages

In my career as a software developer I see real values using MDSD / MDA. Here are my important experiences:

1. If you are following the best practices in model driven software development with UML your application will have a very good blueprint. This is comparable with the blueprint of your house (application architecture). You still don't get any blueprint for your city planning (enterprise architecture) but this is a good way to begin with. So if you have a lot of houses, you will have a very good documentation of each houses but still you don't have any overview about the city where your houses are built on. In a situation where external developers come and go it is very useful to have a very good documentation of your application architecture.

2. The documentation of your application architecture I mentioned above is always up-to-date. Can you imagine to have 200 entities (database tables) in your application and you don't have any UML class diagram for them? Surely you can say, hey we can generate the UML class diagram from the Java classes. The problem with this approach is that you cannot talked with your business people or your stakeholders until you implement the classes and as you know if you already implement those classes you tend to defend your design. Instead of saying "ohh no problem at all I can just change the name of that class" you will say "ahh c'mon you know what I mean right?". It is a lot of work if you have to change the name of your class especially if it has an impact to your persistence layer (JPA, database tables). Let's imagine if you can just change the name of your class in the UML class model and you can generate your persistence layer. You will still have a lot of work refactoring the rest of your codes but it is less work than without using model driven development.

3. The architecture of  your applications is always the same. This is important if you have a lot of applications to be managed. Frameworks like Spring and JPA with Hibernate still give you too much freedom. You can implement your applications in different styles like using XML or only annotations. This will be a problem later as you have to maintain your applications.

4. It is faster to introduce your application structure to external developers and consultants. They learn how to model the entities and services or the domains with UML and generate the skeletons of the codes which they need to implement. In many cases you can generate the persistence layer completely.

From all the points above I can tell you that Model Driven Software Development with UML helps you a lot not only in the beginning as you can start your application development faster but also afterwards in the maintenance phase of your application development.

Best Practices

After a long journey in Model Driven Software Development with UML I can summarize following points to be the best practices (also note this presentation: MDD: the Good, the Bad and the Ugly):

1. Always top-down, never bottom-up, never both directions: you describe your application (entities, services or domains) first with UML. From this you will generate the artifacts (Java, XML, whatsoever). In many cases you will have to extend or implement the generated artifacts.

2. Never edit the generated artifacts, never check-in the generated artifacts into versioning system: you will need different places for your generated and non-generated artifacts. In Maven you have target/generated-sources/java for generated Java artifacts and you can use the Maven phase generate-sources. Never use protected regions, this makes your code unmanageable.

3. UML models are first class citizens in MDSD with UML: you have to handle them with care and you also need an excellent tool for them. Not less than Eclipse or IntelliJ as for Java codes! You need to partition your UML models just like your Java projects so that they won't be too big. Generally I use this practice: one UML model per Java project.

4. Separation of cartridge and application development: a cartridge is just a framework and you will use that framework in your application development. It is clear that you should separate their lifecycle (versioning) correctly. Never mix them! The application just uses that cartridge in a specific version.

5. You introduce MDSD with UML in many small steps, never in big bang: you first introduce UML models in the your smallest and less important Maven projects.

Problems

Still we have some problems in MDSD with UML:

1. For me who's not doing UML daily it is still hard to get into the UML metamodel! BTW. never use the word "metamodel" if you are trying to explain the advantages of MDSD with UML to your management team. As an application developer you actually have less interaction with the UML metamodel. For cartridge developers the UML metamodel with Eclipse UML2 library is a very important thing. Without this you won't be able to generate something useful.

2. There are still less mature cartridges available on the market. AndroMDA has done here a very good job because they have them.

3. Tooling's problem. Still there is no very good Open Source UML tool. You have Eclipse Papyrus but still not comparable with the commercial offers. In commercial area you have definitely MagicDraw which is IMO a very good one! If Google just would take care of this problem... ;-)

Conclusion and Future

In the meantime I have the feeling that less developers want to use MDSD with UML because they think that MDSD with UML is heavyweight and complex, also code generation is heavyweight and complex. It only has disadvantages. They often forget that someone needs to maintain those applications somehow. Without up-to-date visual documentation of those applications you will definitely have difficulties to be able to maintain your applications reasonably. And if you need to change something quick, since the requirements of your business are also changing fast, you will need those up-to-date documentations. Not mentioning that you are not the one and only person who should be able to extend those applications. Maybe there are some external developers or consultants who should support you? This is where Model Driven Software Development with UML plays its important role.

Back to the problem I found in MDSD tools in the beginning of this article and as a Java's lover (and Polyglot hater), we (Ingo, Markus and I) are proud to be able to release the first version of Open Source MDSD tool KissMDA (Keep It Simple Stupid, MDA!). We hope to introduce the next generation tool of MDSD with UML which is easy, quick, clean to use and 100% Java. Join us to bring MDSD with UML to the next level!

BTW. do you want to try application development with KissMDA in quick and clean way, just in three minutes? Check out this Intro: Introduction for Application Developers: Quick and Clean in Three Minutes.

Discuss with us at Google+ for the first release of KissMDA 1.0.0!

Have a lot of fun!
Lofi.

Open Data Initiative and Mashup

Just finishing playing with Open Data Initiative Berlin and Google Maps... Mashup with GWT using the newest Google Maps GWT (gwt-maps 3.8.0-pre1)... Very nice! All in all I used following technologies:

• Java (what else?)
• Maven 3
• GWT (Google Web Toolkit) with gwt-maps 3.8.0-pre1 for Google Maps V3
• GAE (Google App Engine)

Within this mashup I combined the Open Data from Berlin: 

1. Total population 2011 per area (Berlin Mitte, Berlin Spandau, etc.)
2. Result of Election 2011 per area

... and put them into Google Maps. You can find all the links in my WebApp: http://opendataberlin.appspot.com

I found out following things as I implemented the WebApp:

• Open Data Berlin needs to take care of their Open Data API. For the total population I need to get the Zip file, uncompress it and read the CSV file inside it, using Common Compress and OpenCSV Java Open Source library. For the result of election I have to work with Excel file using JExcel, also Open Source library. Amazing to see how complicated they did it! Please just use XML and JSON as the data format and define a usable REST API for this!
• Open Data Initiative itself does not make any sense for many of us. We need applications (WebApp and MobileApp) on the top! And this is where mashup helps a lot.

Check this out (in German language): http://opendataberlin.appspot.com

Article about Polyglot Programming at heise.de

My new article about Polyglot Programming at heise.de in German language: http://goo.gl/QfhpJ This article is based on my privious blog. Enjoy!

Why "Polyglot Programming" or "Do It Yourself Programming Languages" or "Language Oriented Programming" sucks?

Last year we saw the launch of a new Web programming language Dart - Structured Web Programming from Google. A very interesting approach to support web application development. Not so long after Go, Groovy, Ruby, Scala, << name your DSL here >>; we see Dart. Is it a good thing to have at least one programming language to solve one problem? The answer is, like we already know, it depends.

Some important backgrounds you should know about the multi programming language paradigm are following:

1. You can read Martin Fowler article about language oriented programming with language workbenches which enables you to write small programming languages easily. In this article I see everyone writing their small languages, everywhere. In this concept we see DSL (Domain Specific Language) as the future of our programming activities. Source: http://martinfowler.com/articles/languageWorkbench.html

2. Neal Ford talked about Polyglot Programming, combining multiple programming languages in application development. Later Mr. Fowler add this paradigm with Polyglot Persistence, using different type of databases within one application. Source: http://memeagora.blogspot.com/2006/12/polyglot-programming.html and http://martinfowler.com/bliki/PolyglotPersistence.html

Since 2006 I already discussed and collected some experiences in multi programming language paradigm:

1. I remember a “hot” discussion in year 2006 with Sebastian Meyen, chief in editor of JavaMagazin Germany, also the biggest organisator of Java Conference JAX. We agreed to see the future of programming in multi language paradigm concept. I also said that all those languages will be based on Java VM. I also told him that in one day SAP will move ABAP as a language which can be run within the Java VM, so just another language within the Java environment, no two different personalities any more. Today we see the beginning of this in the project called Caffeine ABAP. Source: https://cw.sdn.sap.com/cw/groups/caffeine

2. Also in year 2006 I had a project in which we also used different kind of languages and also creating our own DSL:

• Java for the most implementation stuffs
• UML for design of the business objects. We generate a lot of things using the concept of MDA (Model Driven Architecture)
• Groovy for a lot of things, especially for writing unit tests
• Based on ANTLR we create our own DSL for some aspects of the application

It was really exciting and we had some very good programmers in the project. The result was a very nice and flexible product, just as what we expected in the beginning of the project. Please read this article in German language for more information: http://www.sigs.de/publications/os/2009/02/dewanto_egger_OS_02_09.pdf

So after all those nice things about multi language paradigm I told you, why this sucks at the end? Here are some reasons from my point of view:

1. As typical in application development the problem comes first in the maintenance phase, after all the capable programmers leave the project. Did you, programming language creators ever try to teach a new programming language to a “normal”, 9 till 5 programmers? I’m not talking about 9 (am) till 9 (pm) programmers who love to learn every new languages. It is definitely tough to be proficient in one programming language. This is comparable with the languages we speak everyday. I’m not a native English speaker, so I’m quite sure that I made a lot of syntax and grammar errors in this article. It is possible to be able to speak three or four languages perfectly but this is an exception.

2. Did you ever try to maintain a big Struts web application with AJAX? Just try to add a functionality and you will end up with creating and editing a lot of files: Action and Form files, Struts XML configuration files, JavaScript files with JSON and also HTML or JSP files. Can you imagine to add Groovy, Scala, Dart additionally into that web app? The complexity of such a project is very high.

3. Creating a new programming language means that you also have to build the environment for it. Good IDE, good documentation, good community support, clear roadmap, backward compatibility are some points to be done. Groovy is a bad example of this. In the early version of this language the editor for Eclipse was really bad. After a while they improved the editor but they make a lot of basic changes in the language so your old groovy applications do not work anymore. You are punished to update to the new version. This never happens to Java. You still can compile Java 1.1 applications with Java 6 compiler.

4. Before you are creating your own DSL with e.g. ANTLR ask those language Gurus first, how hard it is to maintain a programming language for a long term. Before you discuss with them don’t ever create your own DSL. Especially if you are working for SME (Small and Medium sized Enterprise). With a small team and small budget you will never ever maintain your own language decently.

So in year 2012, six years after my support to Polyglot Programming, I hope to see following things happen:

1. One language for all aspects in one application is the best concept ever. I name this as “One for All Programming Language paradigm”. Just like we don’t use English for technical language, German as literate language and Indonesian as community language, to be able to communicate internationally with each other we just use English pragmatically for all aspects of our life. In Germany you need to speak German in all aspects to be able to communicate with others. My best solution sofar is Java + XML, that’s it, no more, no less. No mixing with Groovy, Dart, Ruby, Scala, << name your DSL here >> in one application. Especially if you are working as contractor, please don’t try to use all those languages just for a small Java web application. I don’t say that you should not use the other languages at all. The only thing which is important is not to mix those languages in one application. In SME you maybe also want to use just one programming language for all your applications.

2. Concept like GWT (Java to JavaScript compiler) or XMLC (XML compiler which compiles XML, HTML to Java classes) is great. You can work just in plain Java. Guice with all Java and no XML is also a great solution (I know that SpringFramework is also doing this with Annotations). Android is great because it uses Java as its application programming language.

As a conclusion I can only hope to see more such pure and plain Java solutions in year 2012!

OpenID and OAuth: Step2 Protocol

My new article at heise.de about OpenID and OAuth: Step2 Protocol or also known as Hybrid Protocol OpenID and OAuth: OpenID and OAuth: Step2 Protocol.

Enjoy!

Lofi.

Moving from Ant to Maven: Best Practices with Maven Plugins

I would like to share my experience of moving from "our reinventing wheel" of Ant build scripts to Maven standard.

I reworked some apps which have following characteristics:

(1) Java Version:

- The apps should be compiled with Java 6 version.

(2) Basic technologies:

- Some of the apps are using Model Driven Architecture/Model Driven Software Development things, it means we have some MDA/MDSD generators inside our Ant scripts, like AndroMDA or oAW.

- Almost all the apps use Hibernate, so we need to generate the whole Database scheme to be able to create the whole database automatically.

- Some of the apps use older version of ANTLR. So we have some of ANTLR source codes which have to be compiled.

- Some of the apps use older version of Groovy. So we have some of Groovy source codes which have to be compiled.

- A webapp uses GWT as presentation layer.

(3) Packaging:

- Some of the webapps have somekind of information about the version. For example the webapps have version.html file which should be automatically generated with some information like build timestamp, the person who build the app, the description of the app, etc.

- The apps or modules should be packaged as war or jar. Additionally they also include some additional information like installation documentation, SQL scripts, etc. which have to be package as a zip file separately.

- All of the apps or modules should also package the source codes additionally to the packaged artifacts, so we can debug the apps easily.

- The webapps need to package the class files additionally as a separate jar file, so that this can be added as a dependency into another Maven project or module.

(4) Test:

- The apps have some unit tests in JUnit.

- The apps have some integration test for SpringFramework context and database or service methods test in SpringFramework.

(5) Optimization:

- JavaScript, CSS of some webapps should be optimized using YUICompressor.

- JSP files should be precompiled with JSPC from Weblogic.

(6) Quality check:

- Quality check: the apps should be quality checked using Emma (code coverage) and CheckStyle (quality of the codes).

(7) Deployment:

- The webapps should be automatically deployed to Weblogic.

- All configurations should be automatically uploaded to the server.

- The database scheme should be automatically upgraded and downgraded.

(8) Development support:

- JRebel rebel.xml file should be automatically generated for chosen projects or modules.

Yes, our Ant scripts can do the (almost) whole things above. You can imagine how complex they are? Yes, everything are in the Ant scripts and you need to turn on/off the features you need. Remember how SAP works? Yes, we call this customizing! This is where I see the power of Maven. The plugin concept is just a better concept. Instead of having everything, we only have a small "core" and we add plugins on the top to fullfil our need. In case of the Ant scripts, you have everything (although you don't need all of them) and then you use switcher to turn them on and off.

So how did I solve the requirements above with Maven? Here they are, the plugins we need! In this article I just want to show you the plugins I used:

(1) Java Version:

This is quite simple, just add maven-compiler-plugin (2.3.2).

(2) Basic technologies:

- MDA/MDSD: In this case I have two main technologies: AndroMDA and oAW cartridges. For oAW 4.3.x cartridges we have fornax-oaw-m2-plugin (3.0.1). No problem at all. For AndroMDA 3.2 we also have some Maven plugins. My problem was that we use AndroMDA 3.1. In this version there are only some Maven 1.x available. So in this case I have to use maven-antrun-plugin (1.2). Using maven-antrun-plugin I can execute the AndroMDA task to generate the codes without any problems. I need to use the older version of this plugin because of the dependency to the older Ant version of the AndroMDA 3.1 task. One thing you should not forget: if you are generating codes you need to include the generated codes into your compile classpath. Using build-helper-maven-plugin (1.5) you can achieve this. Great!

- To be able to generate the SQL DDL scripts from Hibernate you just need to add hibernate3-maven-plugin (2.2). Working like a charm!

- Because we are using older version of ANTLR we also have to use maven-antrun-plugin (1.2) to be able to execute the ANTLR compiler.

- The same thing also happens with our older version of Groovy. Just use maven-antrun-plugin (1.2).

- For some GWT projects just use gwt-maven-plugin (2.2.0). This is a great Maven plugin (and the one and only) for GWT. This plugin has a very good documentation, so integrating it is quite easy.

(3) Packaging:

- The first step is to delete some of the target directories (generated directories). For this purpose we have maven-clean-plugin (2.4.1).

- To be able to generate a version.html file I use maven-resources-plugin (2.5). With this plugin you will be able to copy some resources (like version.html), parse the file and exchange all the variables with the content you like. In our case we need to exchange some variables with Maven pom.xml information (${maven.build.timestamp}, ${pom.version}, ${pom.description}, etc.). To be able to read these information you need to use at least the latest Maven 2.2.1. In the future we want to create our own Maven plugin to do this stuff, so that we can encapsulate the function better.

- To package additional information and files we have maven-assembly-plugin (2.1). This plugin is very flexible. So I can capture all the requirements of packaging additional zip files with it.

- To be able to deploy the source codes into Maven repository just use maven-source-plugin (2.1.2).

- In some of the webapps I need to package the "classes" into a separate jar file, so that this file can be added into a Maven dependency by other modules. In this case you can split the projects into two: one project for the "classes" and one project for the "webapp". But I did not want this because it will add the complexity of my projects (two projects instead of one). So I use maven-war-plugin (2.1.1) and add a configuration: attachClasses = true. That's it. You will get a new artifact for the classes with additional classifier: classes.

- In some business modules (Jar files) I need to exclude the model files which are the foundation of MDA/MDSD development style. For this purpose just use maven-jar-plugin (2.3.1) and exclude all the model files you don't want to be packaged in your Jar file. The cool thing is that your maven-source-plugin won't be disturbed by this action. So you will have all those model files still included in your source Jar file.

(4) Test:

- For unit test just use maven-surefire-plugin (2.8.1).

- For integration test just use maven-failsafe-plugin (2.8.1). It is important to separate unit and integration test because the integration test can take sometime. Using both plugins will make your project build more flexible, trust me!

(5) Optimization:

- For CSS, JavaScript optimization with YUICompressor just use yuicompressor-maven-plugin (1.1). It works without any problems. One thing you should aware of: if you are build a webapp you also need to configure maven-war-plugin so that it can copy the result of the optimization into the war file. This is also one thing you maybe want to use Maven profile concept, since you don't want to have optimized files within your development lifecycle.

- Precompiling JSP files with JSPC from Weblogic: this is still an open point. I can use maven-antrun-plugin, but I think that there should be a better way.

(6) Quality check:

- For Emma just use emma-maven-plugin (1.0-alpha-2).

- For CheckStyle just use maven-checkstyle-plugin (2.3). You also need to use surefire-report-maven-plugin (2.8.1) to be able to get a report on CheckStyle.

(7) Deployment:

- Automatic deployment war file with Weblogic can now be done easily with this plugin: weblogic-maven-plugin (10.3.4) from Oracle itself. This is great since this Maven support comes from Oracle. Here is the link to the Oracle documentation of this Maven plugin: Maven plugin from Oracle. To be able to define the server location without changing the pom.xml I use this plugin properties-maven-plugin (1.0-alpha-2). With this plugin you can read any properties file and you will have those properties accessible from your Maven build. Great stuff!

- If you want to be able to make automatic deployment you also need to support upload of configuration files to your server. For this purpose you can use this plugin: wagon-maven-plugin (1.0-beta-3). You can download and upload all kind of files with different kind of protocols (http, scp, ftp, etc.).

- The last important thing is to be able to automatically upgrade or downgrade your database scheme. This is an open point for me. There are some Maven plugins out there, but I had no time to analyse them. See my buzz for the list of them.

(8) Development support:

- To generate rebel.xml you can use jrebel-maven-plugin (1.0.7).

As a conclusion I just can say, Maven and its plugin ecosystem are great. No matter how complex your project you can still handle it easily with Maven plugins. My lessons learned is that DO NOT REINVENTING WHEEL! There are a lot of good Maven plugins out there! In case you cannot find one, just use maven-antrun-plugin. You can almost do everything with it. Just don't forget that you don't want that chaos back to Ant, so use it with precautions.

... and to all other developers who still doing their own build processes... try Maven, you won't regret!

Cheers,

Lofi.