directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: One Felix test is failing in eclipse, not when run on the CL
Date Fri, 18 Feb 2011 23:18:20 GMT
On Fri, Feb 18, 2011 at 5:45 PM, Emmanuel Lecharny <elecharny@gmail.com>wrote:

> Hi Alex,
>
> the following test :
> public class StandaloneLdapCodecServiceTest
> {
>    /**
>     * Test method for {@link
> org.apache.directory.shared.ldap.codec.standalone.StandaloneLdapCodecService#StandaloneLdapCodecService()}.
>     */
>    @Test
>    public void testLoadingExtras()
>    {
>        StandaloneLdapCodecService codec = new StandaloneLdapCodecService();
>
>        assertTrue( codec.isControlRegistered( PasswordPolicy.OID ) );
>
>        CodecControl<? extends Control> control = codec.newControl(
> PasswordPolicy.OID );
>        assertNotNull( control );
>        System.out.println( control );
>        assertNotNull( codec );
>        codec.shutdown();
>    }
> }
>
>
> is failing when run alone in eclipse, while it passes when we run the full
> tests.
>
>
This requires a path parameter to the plugin directory. See the shared-integ
pom's system properties in surefire's plugin section.



> After some debugging in eclipse, it appears that the PasswordPolicy control
> is not registered in Felix.
>
>
Yes it is not registered because the bundle for PP is not loaded. It is not
loaded because the plugin directory path is not setup in your eclipse run
configuration. If you set it it will run just fine finding the bundles in
the plugin directory.


> One possible reason for the test passing in CL is that the felix cache
> might have been updated by another test.
>
>
Nope. This is already fixed a while back.


> This has to be fixed so that the test also passes in eclipse.
>
>
 Set the following system property in your run configuration and see if it
passes:

     codec.plugin.directory=${project.build.directory}/pluginDirectory

I don't think the eclipse plugin generates run configurations for tests so
these kinds of system properties that are smart defaults hold inside eclipse
as they do in Maven.

If we hard code the path programatically to the pluginDirectory in the
constructor of this codec class within the test then Maven will fail. So
that was not an option.

If you have a nice trick to make it automatically work in both environments
please do tell. I've always hated the way these pom configurations never
made it into eclipse.

Regards,
Alex

Mime
View raw message