Improve unit test for archiva build

the issue looks to be more in order change in ConcurrentHashMap.
I have fixed that (normally )

Surefire report example on a archiva-configuration with last svn version I can get.

2 consecutive run clean install

1 fail first run.
3 fail second run.

Do you have locally any file ~/.m2/archiva.xml ?

nope having only archetype-catalog.xml and settings.xml

Fake patch: only for giving a try localy.
Aim try to reproduce jdk7 randomness.

Shuffle what SpringJUnit4ClassRunner and make it several time.

Applied to ArchivaConfigurationTest.

Patch to all junit test in archiva to depend on custom Runner with random method list.

Jdk6 will return non modified list to not alter current build.

Should make jenkins archiva 1.7 job a bit more heratic .

Thanks.
But I'm a bit confuse by the patch because with 1.7 tests are now executed twice.
I will commit a modified version.
Feel free to comment .

Sorry I had this parameter to run several time to check for reproductability and give more error because 1 run can be successful with luck.

My point is to use the jdk7 job to stress test junit and help making them more reliable according to the jdk7 implementation change.

Example of a potential test:
testAdd and testRemove on a same list

Add is adding one element , remove is removing one element

Theoricaly:
testRemove may be executable alone, in this dummy example it fail (deleting from empty)
or several time not

Thats why I introduce a loop in the 1.7 testrunner. My evil plan was to set the loop to more than 2 but I don't want to destroy jenkins.

ok .
BTW with not using this name sorting even for 1.6 ?

I just not want to break 1.6 build, in case of future 1.4 js release in short time.

Because I guess that current unit test are more or less good at least with method in JVM order.

My point is more to anticipate jdk 7 or 8 build.

It's not name sorting, is multiple random .

Fixed.
For the random + several time, ok but not as default (something configurable via a sys props and activated in ci servers). Archiva build is already long enough for laptop

Will look for property,

a number as properties to give the number of repetition

not set or 0 = default jvm behavior
1 to n = random + time to repeat (with a cap to 10)

Will try to do that.

Usage -Dorg.apache.archiva.test=n

No more java.spec check.

Poor jenkins .

(A bit scare of unit test in other project when they will come to jdk7 )

applied too.
Thanks (again )

De Nada .

Is it possible to recieve a mail for failure at bar..ni@irit.fr (my name but anti spam) for the jenkis jdk 7 job once parametrized with multiple test run ?

Checksum Test are multiple time runnable.
-Add @Before to remove testing folder
-Remove a extends to abstrac cause not used

Test missing missing sa1 file that where there from previously runned method

More easy to subscribe to archiva-notifications@ see how to here: http://mail-archives.apache.org/mod_mbox/archiva-notifications/

patch applied. Thanks!

• fix for archiva-artifact-converter module

• fix for archiva-policies module (testPolicyYes workflow is not trivial for multiple run)

Will commit myself as warm up

List of module in fault figure are useless. Some failure may be real failure

According to build 1076
org.apache.archiva:archiva-webapp-js
org.apache.archiva:problem-reports
org.apache.archiva:archiva-scheduler-repository
org.apache.archiva:archiva-rest-services

Can go through full mvn clean install locally on jdk 7 but sometimes file delete issue in the following code:

File directory = new File( "target/test-repositories" );
if (directory.exists())
{
    FileUtils.deleteDirectory( directory );
}

On the module
Archiva Base :: Consumers :: Core Consumers
(well seen one time only and forgot to copy error )

Archiva Base :: Proxy
(setUp of AbstractProxyTestCase)

Archiva Core Plugins :: File System Backed Metadata Repository
(setUp of FileMetadataRepositoryTest)

Most of the job has been done.
So close it.