You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Andy <an...@orprovision.com> on 2010/09/28 23:50:46 UTC

Maven pom sweep

Hi all,

I have a made a pretty thorough sweep through the entire pom tree and 
have brought just about everything up to date in all poms - I don't 
think there is one that has not been touched!

All dependencies are looking good, and several erroneous dependencies 
that had crept in have been squeezed back out.

Where possible I have pulled up dependency management into parent poms 
(where they should be) - All examples remain as standalone modules. This 
will encourage global version definition, rather than the current array 
of varying versions across the tree - The next step will be to define 
'all' versions as properties (at the moment only several are defined). A 
further goal is to update the maven-assembly-plugin to a more current 
version, but this will need more reading up on my part to figure out 
what is required.

I have also updated a few classes in Axis2 in order to use 1.4.1 - A 
move to 1.5.2 will also require more work. Do we need to maintain 
backwards compatibility on this dependency?

The following two tests fail intermittently on:

assertAttribute("Aged", 5L);

org.apache.openejb.core.stateless.StatelessPoolStatsTest.testAging()
org.apache.openejb.core.stateless.StatelessPoolStatsTest.testAgingWithReplacement()

This has to be some kind of synchronization or timing issue that returns 
inconsistent results - I have seen 'Aged' vary between 3L - 8L.


-----------
Also, I am not sure if this is a maven quirk (or an Andy on Windows 
quirk) but when the core fails at least one test then the core classes 
directory gets a file lock and the assembly plugin cannot create several 
assemblies even when -fn or -fae are specified?

Running:

mvn -e -fn -Dassemble clean install

Followed by:

mvn -e -fn -DskipTests -Dassemble

Results in a successful build

To reiterate, if I comment out the above two tests then a clean build 
succeeds.

Finally to sum up. I have compared the build 'lib' directory with a 
previous build and I am pretty sure that the new build has dropped only 
erroneous dependencies. However, if you find a jar missing that you 
believe should be an included dependency then please let me know.

If you have any problems then try the following:

mvn dependency:purge-local-repository
mvn -e -U -fn -Dassemble clean install
mvn -e -fn -DskipTests -Dassemble

Andy.


Re: Maven pom sweep

Posted by Andy <an...@orprovision.com>.
  Hi all,

There are still several version anomalies in the final assembly so here is what I am currently doing in order to resolve 
the dependencies:

mvn dependency:tree -Dverbose

This provides a nice dep tree to analyse issues - It's also a good way to work out excludes. There are still a lot of 
missing excludes. If a library depends on other libraries it is better to write the excludes, and then explicitly 
declare includes with the required versions. This prevents any externally resolved dependency changes 'quietly' 
affecting the stability of the build. All versioned dependencies should be pushed up the parent pom tree as high as 
possible into dependency management. A top level pom defines the actual 'version', with child poms defining usages and 
scopes (a child pom should not declare a version except when the dependency is atomic across the multi-module project).

Note: The examples are all standalone projects, and define their own dependencies and versions - There should still be 
an effort to keep dependency versions the same across the board.

mvn dependency:copy-dependencies -DoutputDirectory="D:\Temp\deps"

This copies absolutely all dependencies to the specified location, which makes it easy to see what is duplicated (There 
is a list option if you don't want to write files). There are still several duplicates and version mismatches in the 
current tree which need to be eliminated. With this list it is quite easy to search for and work out which poms are the 
culprits. Running the goal without the 'outputDirectory' creates a /target/dependency in every project, which makes 
finding jar locations easy.

dependency:analyze-dep-mgt

This shows up dependency management issues, of which there are also currently quite a few.

All these commands really need to be run from bottom up and top down in every project directory to iron out all 
conflicts - Quite a lot of work, but will be worth it in the end to get a really clean build.

Any suggestions and or help will be appreciated. I hope to get most of this done be the end of the coming weekend.

Andy.