On 03/06/17 12:39, Emmanuel Lécharny wrote:
Le 03/06/2017 à 04:31, Brian Burch a écrit :
On 03/06/17 12:02, Emmanuel Lécharny wrote:
<snip/>
I can see from the surefire JIRAs you've been onto this problem for a
while, so well done for chasing it down!
The 2.19.1 version is dated December 2015, which makes it pretty old.
The SureFire project released a 2.20 version in April 2017. I updated
my pom.xml and re-ran the install with this version - not
surprisingly, the build was successful too.
I'll leave it up to you to decide which version of surefire ought to
be used in our official API 1.0.0. release.
Actually, none of those versions are good to go. It's really a question
of luck for the build to pass - or not -.
The maven build depends on a side project, named 'project' , that fixes
all the maven plugin version. If you look at
http://svn.apache.org/repos/asf/directory/trunks, which pulls all the
subprojects (API aka shared, apacheds, mavibot and a few others), you'll
see that wealso pull 'project', which contains a POM file itself
containing :
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.19.1</version>
<configuration>
<argLine>-Xmx1024m</argLine>
</configuration>
</plugin>
I have ried with 2.18.1, same kind of (random) trouble.
I do think we will have to wait for a 2.21 version to fix this random
error.
So... do you propose to update the surefire version to 2.19.1 in the
API pom.xml?
It's already using this version :-)
Thanks for explaining. I can see the "trunks" pom.xml calling the
"project" module. I found "project has a tag of 40, which holds a
pom.xml with the preferred version of the surefire plugin. That pom.xml
is at revision 1797473, which corresponds to the latest revision of the
API 1.0.0.
I haven't encountered a maven build this complex before, so it was
helpful to follow the chicken tracks. I'm satisfied I understand why it
builds successfully at revision 1797473, when it didn't before.
I presume there will be people who might want to download and build
the API without taking everything in the entire project. It feels
better to me to clean it up so it could be used standalone. (Much
simpler than having to put a caveat into the readme and then hope
people actually read it!)
Actually, it's possible to build the API without having to set the
surefire plugin version in the pom.xml file, because it's automaically
pulled. As you can see at the top of the API pom.xml file :
<project xmlns="http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.apache.directory.project</groupId>
<artifactId>project</artifactId>
<version>40</version>
<relativePath />
</parent>
it depends on 'project' version 40, which refers to surefire 2.19.1.
I hadn't spotted that link, so thanks for pointing it out.
You can actualy get the effective pom to see which version of every
plugin is being sed, by running the mvn help:effective-pom at the top level.
Yes, I had forgotten about effective-pom. I've rarely had to use it to
track inherited dependencies before.
Either way, I'll stick with my +1 vote now this matter is cleared up.
All my tests either pass with 2.18.1, or are explained.
Thanks !
I've been nervous about having to run my production directory on a
snapshot that happened to resolve some problems for me, but never even
got tagged! I'll look forward to testing the directory server release
candidate in due course...
Brian
