Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Subject: Re: [VOTE] Apache DS 2.0.0-M24 release
To: dev@directory.apache.org
References: <CAG8=FRj+xfkze1Pv7p322TKQ=dbLsPhZa0dNnBK-V+HHeS2Q+w@mail.gmail.com>
 <5b5a400c-c2f5-0734-d53c-f901e25756f1@pingtoo.com>
 <00d9b126-e183-2c5a-cab5-e8584b90810d@gmail.com>
 <453f4c59-9d0d-905a-02e6-908e73feb40e@pingtoo.com>
 <312ead95-430f-5fac-f4d8-b4151c6dc4c6@stefan-seelmann.de>
 <b7233f28-a797-84fc-3006-28bf8a1194a8@pingtoo.com>
From: =?UTF-8?Q?Emmanuel_L=c3=a9charny?= <elecharny@gmail.com>
Message-ID: <6154de61-2f62-7041-6a71-013d270b61e5@gmail.com>
Date: Tue, 6 Jun 2017 10:45:50 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)
 Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <b7233f28-a797-84fc-3006-28bf8a1194a8@pingtoo.com>
Content-Type: text/plain; charset=utf-8
Content-Language: fr
Content-Transfer-Encoding: quoted-printable
archived-at: Tue, 06 Jun 2017 08:46:05 -0000


Le 06/06/2017 =C3=A0 09:29, Brian Burch a =C3=A9crit :
> On 06/06/17 16:10, Stefan Seelmann wrote:
>>
>>> The two disks are identical and configured as a linux soft RAID array=
.
>>> They are Hitachi HDS721010CLA332s - 1 Tb 7200 rpm.
>>
>> I'm sure that's the cause. I also tried to build ApacheDS on a server
>> with spinning disks, and it takes forever. I assume that we just do to=
o
>> many sync's when writing data to disk during the tests.
>>
>> @Emmanuel: Is it possible to disable sync-on-write?
>>
>
> I seem to remember my "solution" was to implement some rather nasty
> synchronized static semaphores with finalizers to allow each of the
> several threads within a single test unit to follow each-other's
> progress. I also had to configure jUnit to only run one test unit at a
> time (to protect the statics). It was tricky and ugly, but I was
> desperate to have every test always run properly on any platform. I
> presume this is a surefire problem, not apacheds?

@Stefan : no, it would not be safe.

@Brian : SSD is the way to go, but if you don't have one, on linux, the
solution would be to run the build on a ram drive. That should speed up
the build considerably.

>
>>> To make matters more depressing, I decided to do a clean checkout of
>>> M24
>>> on my laptop, which is super-slow by comparison. That failed much
>>> earlier (goal apacheds-core-api - missing dependencies) and I will po=
st
>>> those details separately when I get back home again in a couple of
>>> hours
>>> from now.
>>
>> That's probably another reason: The API 1.0.0 which ApacheDS M24 depen=
ds
>> on is not yet available in public Maven repo. On your other machine yo=
u
>> built it yourself and thus it's in you local maven repo.
>
> You are correct! I copied my local API sandbox to the laptop and then
> re-ran mvn clean. It now fails in exactly the same way as my desktop,
> i.e.
>
> [INFO] Apache Directory API All ........................... SUCCESS [
> 8.239 s]
> [INFO] Apache Directory LDAP API Client All ............... SUCCESS [
> 6.523 s]
> [INFO] Apache Directory API Integration Tests ............. SUCCESS [
> 33.313 s]
> [INFO] Apache Directory API OSGi Integration Tests ........ FAILURE [
> 59.170 s]
> [INFO] Apache Directory API OSGi Integration Tests 2 ...... SKIPPED
> [INFO] Apache Directory LDAP API Distribution ............. SKIPPED
> [INFO]
> -----------------------------------------------------------------------=
-
> [INFO] BUILD FAILURE
> [INFO]
> -----------------------------------------------------------------------=
-
> [INFO] Total time: 05:57 min
> [INFO] Finished at: 2017-06-06T17:12:59+10:00
> [INFO] Final Memory: 49M/405M
> [INFO]
> -----------------------------------------------------------------------=
-
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test
> (default-test) on project api-integ-osgi: Execution default-test of
> goal org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test
> failed: The forked VM terminated without properly saying goodbye. VM
> crash or System.exit called?
> [ERROR] Command was /bin/sh -c cd
> /home/brian/sandboxApache/ldap-api-1.0.0/integ-osgi &&
> /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -Xmx1024m -jar
> /home/brian/sandboxApache/ldap-api-1.0.0/integ-osgi/target/surefire/sur=
efirebooter7386057830129872783.jar
> /home/brian/sandboxApache/ldap-api-1.0.0/integ-osgi/target/surefire/sur=
efire806017378512191980tmp
> /home/brian/sandboxApache/ldap-api-1.0.0/integ-osgi/target/surefire/sur=
efire_157233883319047368199tmp
>

You can run it with mvn clean install -Dskiptests, to avoid facing this
issue.

>
>
>>> (It isn't too late to fire me from the developers team!! I wanted to
>>> help, but it doesn't look like I am yet!)
>>
>> Don't be depressed, your feedback is very helpful! It shows that our
>> software is too big and the build is too complex etc. (but I don't kno=
w
>> how to improve and too less time...)
>
> Perhaps you can't change it at the moment, but don't you think it is
> "wrong" that the directory build doesn't include the API?
>
> I think it is excellent that the API can be built stand-alone. (I
> might even consider converting some old applications which still use a
> private copy of the final Netscape LDAP API, along with a LOT of my
> own modifications, which work well against apacheds M23).
>
> On the other hand, it seems strange that the directory build, which
> depends heavily on the API, doesn't build its own copy if one isn't
> already available...

This is purely temporary. I committed an ApacheDS version that depends
on the 1.0 version of the API, when we usually depend on a snapshot.
Usually, it simply works find as we don't release every week.

As soon as I will have close the release (tonite), everything will be
back in order.

>
>
>> Kind Regards,
>> Stefan
>
> Thanks very much for your encouragement. I'll do my best to be
> constructive with my observations.

Much appreciated !


--=20
Emmanuel Lecharny

Symas.com
directory.apache.org