items tagged with maven

We are currently asking ourselves at INNOVEO, if we need to keep a version of integration versions.
Integration versions main objective is to be integrated with other modules to make and test an
application or a framework. This question is quickly becoming essential when working with several
modules, where you will have to to rely on intermediate, non finalized versions of modules.

Since we are also following  the continuous integration paradigm for all our modules, Thanks to
Apache MAVEN, these integration versions are produced by a continuous integration server
(Team City from JetBrain), very frequently.

So, how can you deal with these, possibly numerous, integration versions? The response is coming
from this extract from IVY documentation

There are basically two ways to deal with them,

Use a naming convention
The idea is pretty simple, each time you publish a new integration of your module you give the same
name to the version (in maven world this is for example 1.0-SNAPSHOT). The dependency manager
should then be aware that this version is special because it changes over time, so that it does not
trust its local cache if it already has the version, but check the date of the version on the repository
and see if it has changed.

 
Create automatically a new version for each
in this case you use either a build number or a timestamp to publish each new integration version
with a new version name. Then you can use one of the numerous ways in Ivy to express a version
constraint. Usually selecting the very latest one (using 'latest.integration' as version constraint) is
enough.

But usually we recommend to use the second one, because using a new version each time you publish
a new version better fits the version identity paradigm, and can make all your builds reproducible,
even integration one. And this is interesting because it enables, with some work in your build system,
to introduce a mechanism to promote an integration build to a more stable status, like a milestone
or a release.

The example given is very interesting...

Imagine you have a customer which comes on a Monday morning and asks your latest version of your
software, for testing or demonstration purpose. Obviously he needs it for the afternoon :-) Now if
you have a continuous integration process and a good tracking of your changes and your artifacts, it
may occur that you are actually able to fulfill his request without needing the use of a dolorean to
give you some more time :-) But it may occur also that your latest version stable enough to be used
for the purpose of the customer was actually built a few days ago, because the very latest just break
a feature or introduce a new one you don't want to deliver. In this case, you can deliver this 'stable'
integration build if you want, but be sure that a few days, or weeks, or even months later, the
customer will ask for a bug fix on this demo only version. Why? Because it's a customer, and we
all know how they are :-)

So, with a build promotion feature of any build in your repository, the solution would be pretty easy:
when the customer ask for the version, you not only deliver the integration build, but you also
promote it to a milestone status, for example. this promotion indicates that you should keep track of
this version in a long period, to be able to come back to it and create a branch if needed.

Note this is the strategy at Eclipse.org, where a nightly build (N20080420) can be promoted to an Maintenance
release if quality is good enough. Below I've put an extract of a presentation document from © 2006 by Alex Blewitt;
made available under the EPL v1.0 |  2006-03-20  |  http://www.rcpapps.org/

We are now using the same naming convention at INNOVEO for our product

Eclipse builds are of different type:

(N) Nightly	Built every night (whether successful or not) Used to run quality metrics and whether tests have passed
(I) Integration	Used to ensure that code works together Used to run quality metrics
(M) Maintenance	Released at the end of each build cycle
(R) Release	Released at the end of each release cycle

Each product is given a build id,

• Build Type (N, I, M or R)
• Build ID (M20060118)
• Build Label (M20060118-1600)
• Timestamp of build (16:00 on the 18th Jan, 2006)
• Each release corresponds to a specific build label
• May also be known as other aliases in CVS
• R3_1_2, vI20060118-1000, R3_1_Maintenance

To keep the Eclipse ecosystem in step, everything is tagged

• Part of the build process tags the current code with vI20060320
• A build is only promoted from N->I if there are no build failures
• A build is promoted from I->M if there are no failures and all the
  functionality works to a satisfactory level
• A build is promoted from M->R at the end of a release cycle and
  the quality is suitably high

 On the other hand, the main drawback of this solution is that it can produce a lot of intermediate
versions, and you will have to run some cleaning scripts in your repository...

I will present You later how you can achieve this goal with MAVEN and Team City

After reading these book, you may want to try the Questions for the official certification. Maven2 certification at Java Black Belt

 JavaBlackBelt is a community for Java & open source skills assessment. It is dedicated to technical quizzes about Java related technologies. This is the place where Java developers have their technology knowledge and development abilities recognized. Everybody is welcome to take existing and build new exams.

Maven: The Definitive Guide (Readable HTML alpha release) Covers:Maven 2.0.x Published:Not yet Authors: Sonatype (Jason van Zyl, John Casey, Eric Redmond)	Better Builds with Maven (Free PDF) Covers:Maven 2.0.4 Publisher:DevZuz Published:March 2006 Authors: John Casey, Vincent Massol, Brett Porter, Carlos Sanchez Better Builds with Maven is a comprehensive 'How-to' guide for using Maven 2.0 to better manage the build, test and release cycles associated with software development. The chapters include: An introduction to Maven 2.0 Creating, compiling and packaging your first project Best practices and real-world examples Building J2EE Applications Extending builds by creating your own Maven plugins Monitoring the health of source code, testing, dependencies and releases Team collaboration and utilising Continuum for continuous integration Converting existing Ant builds to Maven
Maven: A Developer's Notebook Covers:Maven 1.0.2 Publisher:O'Reilly Published:July 2005 Authors:Vincent Massol, Tim O'Brien

What you will learn in this small post

• How to create JAXB proxies at build time using maven-jaxb2-plugin in a continuous build environment (TeamCity / Bamboo)
• How to generate from an XSD file (XML-Schema-Definitions) Java code.

Requirements

• We will use JAXB2 (see JSR 222 and JAXB 2.x).
• We use Maven 2.2.1, the latest available version

Maven for PHP uses the power of Maven for building, reporting on and creating documentations of PHP projects. It adapts the Maven build lifecycle to the PHP world while fully supporting PHP 4 and PHP 5. PHP for Maven uses PHPUnit for unit testing and doxygen for creating the api documentation.
Use a PHP library project to create a library that can be used by other PHP libraries or PHP web projects. Use a PHP web project to create a standalone web project.

So I quickly describe what I did install on my root server (OpenSuse 11.X)

• Maven 2 
• php not an issue on a linux box, zypper in php5 or apt-get  to install php
• doxygen
• phpdocumentor

My Objectives: being able to build all my Joomla! component using best agile development practices

“Specific tools and techniques such as continuous integration, automated or xUnit test, pair programming, test driven development, design patterns, domain-driven design, code refactoring and other techniques are often used to improve quality and enhance project agility.”

Apache foundation is using Hudson for continuous build (and also JBOSS)

Hudson monitors executions of repeated jobs, such as building a software project or jobs run by cron.
Among those things, current Hudson focuses on the following two jobs:

1. Building/testing software projects continuously, just like CruiseControl or DamageControl.
   In a nutshell, Hudson provides an easy-to-use so-called continuous integration system,
   making it easier for developers to integrate changes to the project, and making it easier
   for users to obtain a fresh build. The automated, continuous build increases the productivity.
2. Monitoring executions of externally-run jobs, such as cron jobs and procmail jobs, even those
   that are run on a remote machine. For example, with cron, all you receive is regular e-mails that
   capture the output, and it is up to you to look at them diligently and notice when it broke.
   Hudson keeps those outputs and makes it easy for you to notice when something is wrong.

This is a public build and test server for various Apache Projects.

An Eclipse plugin is also available the online WIKI is HERE

If you are shopping for a build server, and you are not on a budget, I can recommend you the
excellent Team City from JetBrains. Maven integration is also good, but wont probably never reach the level
of Hudson as it is made by Apache and tailored for their frameworks needs.