[ecf-dev] Re: Failing Zoodiscovery tests

[Wim Jongman <wim.jongman@xxxxxxxxx>]

Hi,

I think I found the problem but was not able to completely solve it.
Scott added new classes to the discovery services project
LoggingProxyDiscoveryListener, .. and these were not picked up. This
caused the test build to fail and subsequently the discovery tests to
fail.

The workspace of "L-HEAD-sdk.tests.feature" contained a stale target
platform. I removed the workspace for "L-HEAD-sdk.tests.feature" to
let it build again but it cannot find a repository at [1] which does
exist. I suspect that the secure http url is the problem. If I use
http repo [2] everything compiles but other problems persist while
archiving the results.

I changed the repos to a file:/ url for the test project and disabled
testing for zoodiscovery. Since I do not completely know how
everything links together with 3.2 and 3.3 I want to leave it with
this minor fixes and analysis.

@Pierre: I will check the problem if the build issues are resolved. I
bet they are related.

@Markus can you take a look at why the test project cannot resolve the
last successful build repository thru secure http and it will not
archive the results?

[1] ECF_P2_REPOSITORY=https://ecf2.osuosl.org/hudson/job/N-HEAD-sdk.feature/lastSuccessfulBuild/artifact/site.p2/
[2] ECF_P2_REPOSITORY=http://ecf2.osuosl.org/repo/

Regards,

Wim
On Sat, May 29, 2010 at 9:46 PM, Wim Jongman <wim.jongman@xxxxxxxxx> wrote:
> Hi,
>
> I am currently examining the reasons why the zoodiscovery tests fail
> in the build. The tests run fine when ECF is "selfhosted" but fail on
> the build server. I have downloaded the target environment from the
> build server and I can see the tests failing locally as well (which is
> nice because now we can debug).
>
> Just so you know I am looking into it. The same tests are also failing
> for jmdns so there's probably an error in the basement.
>
> Keep you posted,
>
> Wim
>