Leaky JCR 1.0 Apis

[Ian Boston <ie...@tfd.co.uk>]

Hi,

This is FYI.

For anyone depending on Sling you may find that you get build errors relating to the things like 

session.getNode(nodePath);

This is a JCR2 only API, and even if you are certain you have specified JCR2 in your maven pom you may still get build and test errors.

The reason is that early versions of org.apache.sling.jcr.api contain javax.jcr.* from JCR1, and some of the current SNAPSHOT artifacts include those early versions of org.apache.sling.jcr.api as a transitive dependency.

For instance, the current Sling User Manager pulls in jcr.base 2.0.4-incubator and servlets.post 2.0.4-incubator both of which pull in org.apache.sling.jcr.api 2.0.2-incubator which is JCR 1 API

Since these jars are not the same artifact, the build failing depends on the search order in the classpath, and to make matters worse, Surefire uses a different search order, so build might past, and tests might fail with with a method not found exception (also the tests will probably be ok in Eclipse)

-----------------------------------------

Question:

Is there a reason that the sling User Manager us not using later versions of jcr.base and servlets.post ?

----------------------------------------

btw, a workarround

    <dependency>
      <groupId>org.apache.sling</groupId>
      <artifactId>org.apache.sling.jcr.jackrabbit.usermanager</artifactId>
      <version>2.0.5-SNAPSHOT</version> 
       <exclusions>
         <exclusion>
          <groupId>org.apache.sling</groupId>
          <artifactId>org.apache.sling.jcr.api</artifactId>
        </exclusion>
      </exclusions>
    </dependency>


HTH
Ian