Service enhancer (docs?) may not work after update to 6.0.0 for assembler configuration

[OyvindLGjesdal]

Version

6.0.0

What happened?

I have ansible molecule job that tests my ansible fuseki role, that failed upon update to 6.0.0

Instructions from jena-site at https://jena.apache.org/documentation/query/service_enhancer.html was used to try both methods described

https://jena.apache.org/documentation/query/service_enhancer.html

More info on the jena-dev mailing list: https://lists.apache.org/thread/3wj80l5hdx6l8y1n3qgp1odqwmz1v6jl

I can set it up on a server instead of running molecule for easier debugging and report back.

Relevant output and stacktrace

Are you interested in making a pull request?

None

[Aklakan]

I am afraid my documentation needs an update:

https://jena.apache.org/documentation/query/service_enhancer.html

The following approach is my attempted fix which looks good to me:

1. Download the pom.xml by Maven coordinate:

mvn dependency:copy -D'artifact=org.apache.jena:jena-serviceenhancer:6.0.0:pom' \
  -Dmdep.stripVersion=true -D'outputDirectory=.'

2. Download the serviceenhancer jar itself without dependencies:

mvn dependency:copy -D'artifact=org.apache.jena:jena-serviceenhancer:6.0.0:jar' \
  -D'outputDirectory=jars'

3. Download all (runtime-scope) jar files of the transitive dependencies of serviceenhancer:

mvn -f jena-serviceenhancer.pom -Pbundle dependency:copy-dependencies \
  -DincludeScope=runtime -DoutputDirectory=jars

The bundle profile excludes jena's own dependencies.

➜  tree
.
├── jars
│   ├── failureaccess-1.0.3.jar
│   ├── guava-33.5.0-jre.jar
│   ├── j2objc-annotations-3.1.jar
│   ├── jena-serviceenhancer-6.0.0.jar
│   ├── jspecify-1.0.0.jar
│   └── listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
└── jena-serviceenhancer.pom

[OyvindLGjesdal]

mvn dependency:copy -D'artifact=org.apache.jena:jena-serviceenhancer:6.0.0:pom' -Dmdep.stripVersion=true -D'outputDirectory=/home/fuseki'
#doesn't pull in serviceenhancer itself, only its dependencies
mvn dependency:copy-dependencies -f jena-serviceenhancer.pom -DincludeScope=compile -DoutputDirectory=$FUSEKI_BASE/extra
mvn dependency:copy -D'artifact=org.apache.jena:jena-serviceenhancer:6.0.0:jar' -DoutputDirectory=$FUSEKI_BASE/extra

Works for me. pulling guava pom instead of the jena-serviceenhance pom may also work with less jars in the extra folder.

[Aklakan]

Yes, it's 3 steps: Get pom, get jar, get deps - somehow I had messed this up.

[Aklakan]

Also note the bundle profile, which excludes jena's own jars.

[OyvindLGjesdal]

Thank you, that works nicely for the download example. The shaded jar has the same issue that the serviceenhancer class files aren't included in the jar, when built from a fetched pom.

     "Archive:  jena-serviceenhancer-6.0.0.jar",
            "   creating: META-INF/",
            "   creating: META-INF/maven/",
            "   creating: META-INF/maven/org.apache.jena/",
            "   creating: META-INF/maven/org.apache.jena/jena-serviceenhancer/",
            "  inflating: META-INF/maven/org.apache.jena/jena-serviceenhancer/pom.xml  ",
            "  inflating: META-INF/maven/org.apache.jena/jena-serviceenhancer/pom.properties  ",
            "   creating: META-INF/maven/com.google.guava/",
            "   creating: META-INF/maven/com.google.guava/guava/",
            "  inflating: META-INF/maven/com.google.guava/guava/pom.properties  ",
            "  inflating: META-INF/maven/com.google.guava/guava/pom.xml  ",
            "   creating: META-INF/proguard/",
            "  inflating: META-INF/proguard/base.pro  ",
            "  inflating: META-INF/proguard/cache.pro  ",
            "  inflating: META-INF/proguard/collect.pro  ",
            "  inflating: META-INF/proguard/concurrent.pro  ",
            "  inflating: META-INF/proguard/hash.pro  ",
            "  inflating: META-INF/proguard/primitives.pro  ",
            "   creating: com/",
            "   creating: com/google/",
            "   creating: com/google/common/",
            "   creating: com/google/common/annotations/",
            "  inflating: com/google/common/annotations/Beta.class  ",
            "  inflating: com/google/common/annotations/GwtCompatible.class  ",

I think the options here are changing the docs to include instead build from the git repo

e.g:

# from directory of jena
mvn package -B -pl jena-serviceenhancer -am -Pbundle -DskipTests

or include something like this in the SE pom to fetch the dependency (Claude suggested, works when placed in the bundle plugins section.)

<!-- ... existing code ... -->
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-dependency-plugin</artifactId>
            <executions>
              <execution>
                <id>unpack-own-classes</id>
                <phase>generate-resources</phase>
                <goals>
                  <goal>unpack</goal>
                </goals>
                <configuration>
                  <artifactItems>
                    <artifactItem>
                      <groupId>org.apache.jena</groupId>
                      <artifactId>jena-serviceenhancer</artifactId>
                      <version>${project.version}</version>
                      <type>jar</type>
                      <overWrite>false</overWrite>
                      <outputDirectory>${project.build.outputDirectory}</outputDirectory>
                    </artifactItem>
                  </artifactItems>
                  <!-- Skip if classes already exist (normal build with sources) -->
                  <overWriteIfNewer>false</overWriteIfNewer>
                </configuration>
              </execution>
            </executions>
          </plugin>
<!-- ... existing code ... -->

[Aklakan]

The shaded jar has the same issue that the serviceenhancer class files aren't included in the jar, when built from a fetched pom.

This is expected, because creating the shaded jar from the downloaded pom will bundle the compiled source code with the dependencies - and the source code is not there - so the set of source files is empty.

The unpack-own-classes approach should indeed make it possible to build a shaded jar from a released maven project without requiring the source code to be present. It could be included as an additional profile. Thanks for the pointer!

Another approach could be with OSGI. With OSGI, plugin dependencies could be isolated - so two plugins using e.g. different versions of guava would not conflict because OSGI would load them with different class loaders.

[OyvindLGjesdal]

Tried to update the documentation from the examples in this issue. Have tried copy-pasting the commands, and the instructions work. Since this now is the only module dependent on Guava, maybe we could consider to publish the bundled jar, in addition to the one now present, with a filesuffix e.g, apache-jena-serviceenhancer_VERSION_bundled.jar, to enable download of an official bundled-jar?