directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Burch <>
Subject Re: [VOTE] Apache LDAP API 1.0.0 release
Date Sat, 03 Jun 2017 07:26:21 GMT
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
>>>, 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=""
> xmlns:xsi=""
> xsi:schemaLocation="
>    <modelVersion>4.0.0</modelVersion>
>    <parent>
>      <groupId></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...


View raw message