PR for JCR-4892

[jespersm]

This is an update of JCR-4892 on top of current trunk

[oleosterhagen]

Thank you for migrating Jackrabbit to the Jakarta namespace.

Can you estimate when this feature will be released?

[reschke]

No, not really; this lacks both test coverage and energy to get it done.

[jespersm]

I wonder, is there no automatic pipeline runner set up for this repo? Or am I doing something wrong?

Also: @oleosterhagen : Can you test this to ensure we resulting jar match you expectations and use case?

[reschke]

I wonder, is there no automatic pipeline runner set up for this repo? Or am I doing something wrong?

Not here, only for Jackrabbit Oak.

EDIT: working on it, see https://issues.apache.org/jira/browse/JCR-5157

[reschke]

can we move this into the parent pom and set the version to 1.0.0?

[jespersm]

I can move it, yes - but org.eclipse.transformer:transformer-maven-plugin is built for Java 17 and up. What is the minimal version supported for building?

[reschke]

Bumping up the JDK required for building should not be problem as long as we create java 11 compatible byte code.

See

jackrabbit/jackrabbit-parent/pom.xml

Line 72 in 3c76cbd

<minimalJavaBuildVersion>${javaTargetVersion}</minimalJavaBuildVersion>

[oleosterhagen]

Also: @oleosterhagen : Can you test this to ensure we resulting jar match you expectations and use case?

We have now migrated enough parts of our application to run the first tests. We deploy the Jackrabbit Webapp to a JBoss application server (now JBoss 8.x / Jakarta EE 10). We use

• the WebDAV interface
• JCR operations (for cleanup)

Both use cases work with this PR as expected. Two things I have noticed:

1. For jackrabbit-webapp-jakarta (pom.xml) only a WAR and no additional JAR (e.g. jackrabbit-webapp-2.22.0.jar) is created. We need the JAR as a dependency in an overlay to refer to classes from Jackrabbit.

The JAR can be produced with a second execution of the transformer-maven-plugin and an extra attach for the resulting JAR:

[...]
          </execution>
          <execution>
            <id>default-jar</id>
            <goals>
              <goal>jar</goal>
            </goals>
            <configuration>
              <artifact>
                <groupId>org.apache.jackrabbit</groupId>
                <artifactId>jackrabbit-webapp</artifactId>
                <version>${project.version}</version>
                <type>jar</type>
              </artifact>
              <type>jar</type>
              <attach>false</attach>
            </configuration>
          </execution>
        </executions>
      </plugin>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>build-helper-maven-plugin</artifactId>
        <executions>
          <execution>
            <id>attach-jar</id>
            <phase>package</phase>
            <goals>
              <goal>attach-artifact</goal>
            </goals>
            <configuration>
              <artifacts>
                <artifact>
                  <file>${project.build.directory}/jackrabbit-webapp-jakarta-${project.version}.jar</file>
                  <type>jar</type>
                </artifact>
              </artifacts>
            </configuration>
          </execution>
        </executions>
      </plugin>
[...]

2. The Derby database driver is no longer included in the WAR. That is unrelated to this PR and already the case in Jackrabbit 2.22.0. @reschke Is the change of the scope to test in https://github.com/apache/jackrabbit/pull/157/files#diff-de0290e6ab0121b9a3d0753f5a4ffc5977e9097a52fa1ca76cf2390035d9c6b3 intentional? (It is no problem for us to include the needed driver JARs in our WAR overlay.)

[jespersm]

@oleosterhagen : Thank you for checking, sounds promising.
I will not be looking at this PR over the next few weeks, and haven't tackled the package renaming situation.