<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <executions>
      <execution>
        <goals>
          <goal>test-jar</goal>
        </goals>
      </execution>
    </executions>
</plugin>

 <dependency>
     <groupId>yourGroup</groupId>
     <artifactId>yourReusableModuleArtifact</artifactId>
     <version>0.1-SNAPSHOT</version>
     <classifier>tests</classifier>
     <scope>test</scope>
 </dependency>

This has work for me with Maven 2.0.8

A strategy for Integrations versions with maven...

Details

Category: Apache Maven

Published on Friday, 25 April 2008 00:00

Written by Administrator

Hits: 9649

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

Maven dependencies under control: excluding unwanted transitive dependencies

Details

Category: Apache Maven

Published on Thursday, 17 July 2008 00:00

Written by Administrator

Hits: 23448

What can you do to avoid that when you use one Maven dependency, to also inherit some other undesirable older
dependency (which is to say from an older transitive dependency).

The fix to this is to add an exclusion to the dependency in question.
For example, if we start with a dependency upon version 1.2 of the jxpath library:

<dependency>
   <groupId>common-jxpath</groupId>
   <artifactId>common-jxpath</artifactId>
   <version>1.2</version>
   <scope>compile</scope> <!-- default scope for sake of example-->
</dependency>

This dependency to jxpath 1.2 will bring in an old version of log4j 3.8. In order to ensure that I am using the latest
versions of log4j (4.4),

I need to put in an exclusion for these transitive dependencies of common-jxpath, which I do as follows:

<dependency>
   <groupId>common-jxpath</groupId>
   <artifactId>common-jxpath</artifactId>
   <version>1.2</version>
   <scope>compile</scope> 
   <exclusions>
      <exclusion>
         <artifactId>junit</artifactId>
         <groupId>junit</groupId>
      </exclusion>
      <!-- I can put many of these here -->
   </exclusions>
</dependency>

Having excluded them, they will be any longer in the build.

Read more: Maven dependencies under control: excluding unwanted transitive dependencies

Best nginx configuration for Joomla

Details

Category: Joomla

Published on Monday, 23 January 2012 20:31

Written by Administrator

Hits: 4083

nginx (pronounced “engine-x”) is an open source Web server and a reverse proxy server for HTTP, SMTP, POP3 and IMAP protocols, with a strong focus on high concurrency, performance and low memory usage. It is licensed under a BSD-like license and it runs on Unix, Linux, BSD variants, Mac OS X, Solaris, AIX and Microsoft Windows [WikiPedia]

These are my reusable settings for any Joomla hosting, these are the most secure, and fastest settings to the best of my knowledge.

Read more: Best nginx configuration for Joomla

Maven reusing test classes across multi modules projects

Details

Category: Apache Maven

Published on Friday, 18 July 2008 00:00

Written by Administrator

Hits: 31553

Maven clearly differentiate "productive code"  in each module src/main/* from unit test code in src/test/*.
In a typical multi-module projects like the one below:

componentA
|
|-moduleA
|         /src/main/java
|         /src/main/resources
|         /src/test/java
|         /src/test/resources
|-moduleB
|         /src/main/java
|         /src/main/resources
|         /src/test/java
|         /src/test/resources

Note1: Eclipse do not support multi module project as only one level of code sharing is allowed. So we have
3 eclipse projects/maven projects with a pom.xml:

• componentA with a packaging pom, and 2 module aggregated
• moduleA, parent is ../componentA/pom.xml
• moduleB   parent is ../componentA/pom.xml

Note2: eclipse has only one Class Loader, meaning that code in /src/main/java  and /src/test/java  is also exported
as dependencies between modules, while in Maven, code is not shared!

So as default by adding a dependencies in moduleB/pom.xml to moduleA, you'll only inherit moduleA src/main/java
and src/main/resources

Read more: Maven reusing test classes across multi modules projects

Get more speed with your MAVEN2 build

Details

Category: Apache Maven

Published on Wednesday, 13 August 2008 00:00

Written by Administrator

Hits: 22588

We had serious performance problems with MAVEN in our environment. It seems to be a recurrent problem
for MAVEN... anyway I did came through the following changes...the 2.0.9.db1 Maven2 patch make really
Maven fly!

General settings to speed up Maven:

• More memory for Maven process, change the launcher of eclipse to set MAVEN_OPTS like this:
  -DMAVEN_OPTS="-Xms64m –Xmx128m"
• Use the latest version of Maven, but be careful of regressions! the latest as for today is 2.0.9
• There is a patch available for Maven 2.0.9, which speed up build by 40%. It is just simply day and
  night! try it, you'll love it! Basically Don Brown alter MAVEN2 2.0.9 to
  • use HTTP connection pooling !
  • use HTTP timeouts !
  • Download artifacts in parallel !
    download and read how this was done at
    http://www.jroller.com/mrdon/entry/making_maven_2_not_suck
    and his jar here http://people.apache.org/~mrdon/maven-2.0.9-SNAPSHOT-uber.jar

General settings to speed up Eclipse:

1. Use javaw.exe to start eclipse and not java.exe (more for console base program with a lot of feedback),
   while javaw.exe is more for graphical environment.
2. Aggressive JIT and double core processors should use:  
    -XX:-UseParallelGC -XX:+AggressiveOpts -XX:-UseConcMarkSweepGC -XX:+UseFastAccessorMethods
3. Give more memory, MORE MEMORY for eclipse, on a 4GB machine, these are my settings: 
   -Xms768m -Xmx1024m -XX:MaxPermSize=256m
4. Reduce the number of warning reported by eclipse per compilation unit (class), default is 100, reduce it to 10.
   It help nobody to see a workspace slowing down because of too many warning logging.
   Remove the warnings instead ;-)
5. SVN console with subversive is too verbose as default, go to eclipse preferences - Team – SVN - Console.
   Logging SVN errors should be enough.
6. Use a Defragmenter! NTFS fragment fast with so many small files in workspace, every 2 week is a good practice.
7. I am using Java 1.6u10 (BETA!) and have experience no crash till now,
   being on the edge can be costly in time through. Maven forking should benefit from the reduce java kernel
   size and bootstrap time

Apache Maven books

Details

Category: Apache Maven

Published on Sunday, 02 November 2008 00:00

Written by Administrator

Hits: 9891

Questions for the official certification.

 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

Subversion and the importance of svn:ignore for MAVEN multi modules

Details

Category: Apache Maven

Published on Friday, 20 March 2009 00:00

Written by Administrator

Hits: 16661

Maven 2 builds can be quite slow, especially if you are not following the best practices of using Maven in Eclipse. For example if you are not removing all /target directories from version control!

If you let /target directories going into version control, the following happen:

• Each full build of the workspace,
• Each partial build of modules,

Read more: Subversion and the importance of svn:ignore for MAVEN multi modules

Module-based development with Spring and Maven 2

Details

Category: Apache Maven

Published on Thursday, 09 April 2009 00:00

Written by Administrator

Hits: 8639

The last year, I was at Jazoon 08, and I forget to tell you how good some of their presentation about Maven were

Module-based development with Spring and Maven 2

Modularity belongs to the basic architectural best practices. Splitting your application in separate modules can reduce undesired coupling as well as lead to high cohesion, reduce complexity, simplify team development, and decrease execution size by using only the required modules. This talks presents how we combine existing technologies (Spring and Maven 2) to get a seamless module support for the development, test and runtime of Java applications. Maven is concerned with build time aspects, Spring is concerned with run time aspects and there are some shared aspects that concern both. A developer can thus define in his module what the module shall do during development, test and runtime. This leads to better separation of concerns as each module can focus on its aspects and is less bothered by aspects of other modules. We argue that to realize the full potential, only combining plain Maven 2 and Spring is not sufficient and discuss what to add. The module support is implemented and freely available in the open source EL4J project (http://EL4J.sf.net). Read More Here