Maven build - force the use of a newer version

Question

I am trying to build protege-server (https://github.com/protegeproject/org.protege.owl.server) from source. I downloaded the source code. Using "mvm -X package" yields the following error:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.
0:compile (default-compile) on project org.protege.owl.server: Compilation failu
re
[ERROR] /c:/Users/user/Programs/webprotege/org.protege.owl.server-master/src/mai
n/java/org/protege/owl/server/connect/local/OSGiLocalTransport.java:[11,32] type
 org.osgi.framework.ServiceRegistration does not take parameters

Based on a previous question, an OSGI blogpost explains that the problem was fixed in a later (4.3.1) version of the library.

I tried to refer a newer version of this library in the POM.xml file:

<dependency>
            <groupId>org.osgi</groupId>
            <artifactId>core</artifactId>
            <version>6.0.0</version>
             <scope>system</scope>
            <systemPath>/c:/Users/user/Downloads/osgi.core-6.0.0.jar</systemPath>
        </dependency>

and even downloaded the newer version to specifically target it.

The error still occurs. Is there any way to solve it?

EDIT:

Attempting the solution suggested by @Balazs Zsoldos didn't help and I received the same error message. I noted an import of this package (org.osgi.framework) referring version 1:

  <Bundle-Activator>org.protege.owl.server.Activator</Bundle-Activator>
                <Bundle-SymbolicName>org.protege.owl.server</Bundle-SymbolicName>
                <Bundle-Vendor>The Protege Development Team</Bundle-Vendor>
                <Embed-Dependency>antlr, antlr-runtime, stringtemplate</Embed-Dependency>
                <Export-Package>org.protege.owl.server*;version=2.0.6-SNAPSHOT</Export-Package>
                <Import-Package>!org.antlr.stringtemplate, 
                            !org.apache.commons.cli,
                            org.osgi.framework;version="1",
                            *</Import-Package>

An attempt to remove this line did not help either, as it appears in another dependency down stream. I could not find out how to override the downstream import-package instruction.

The effective pom.xml, as generated by eclipse, is attached as a link: https://docs.google.com/document/d/1eHFalUHVZ45ejLes_eqaXLw6ttjcTryphbGr_CKbhRk/edit?usp=sharing

Why do you use system scope with systemPath instead of provided scope? — Balazs Zsoldos, Apr 07 '15 at 07:48
Since I provided the JAR file explicitly, I used the system scope according to the documentation (https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope): "system This scope is similar to provided except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository." — KorMed, Apr 07 '15 at 09:14
@KorMed: I know what system scope is, but I do not think you should use it in this case. — Balazs Zsoldos, Apr 07 '15 at 13:46
org.osgi.framework;version="1" means that the bundle needs at least version 1.0.0 of the package org.osgi.framework. That package is still on 1.x, although the version of the osgi.core bundle is 6.0.0. The version of bundle and its packages are not always the same. — Balazs Zsoldos, Apr 07 '15 at 21:10

Balazs Zsoldos · Accepted Answer · 2015-04-07T21:32:29.047

The issue is that older versions of osgi.core are still on the classpath of the as they are imported with different group and artifact ids. Drag and drop the pom.xml to your eclipse and see the Dependency Hierarchy tab of the pom editor to get more information.

The following two are imported by dependencies:

org.osgi:org.osgi.core (by org.apache.felix.log)
org.apache.felix:org.osgi.core (by owlapi distribution)

To solve the problem, you should add the following dependency:

<dependency>
    <groupId>org.osgi</groupId>
    <artifactId>org.osgi.core</artifactId>
    <version>6.0.0</version>
    <scope>provided</scope>
</dependency>

And as this does not override the org.apache.felix:org.osgi.core dependency, exclude that one:

<dependency>
    <groupId>net.sourceforge.owlapi</groupId>
    <artifactId>owlapi-distribution</artifactId>
    <version>3.4.5</version>
    <exclusions>
        <exclusion>
            <groupId>org.apache.felix</groupId>
            <artifactId>org.osgi.core</artifactId>
        </exclusion>
    </exclusions>
</dependency>

(and remove the dependency with system scope as you do not need it and its artifactId is different from the standard anyway).

Edit

Just realized that the old osgi.core package is also inside org.apache.felix:org.apache.felix.framework that is pulled transitively by ProtegeLauncher via org.apache.felix:org.apache.felix.main:4.0.3. This means that you should either

Increment the version of org.apache.felix:org.apache.felix.main to the newest (or to one that at least implements osgi 4.3). In this case you do not need osgi.core at all
exclude org.apache.felix:org.apache.felix.main from edu.stanford.protege:ProtegeLauncher (and keep version 4.3.1 or higher of osgi.core)

I tried the second one and another issue comes that surfire plugin cannot be downloaded from maven central (or something similar, you will see).

Notes

The developer of this protege library was clearly not familiar how maven dependency management works and what should have been imported as a dependency. The project imports an OSGi runtime environment transitively that should never happen. For compilation only API should be imported and if the target runtime surely contains that API, it should be imported with provided scope. I would recommend to

not use this library or
clean it out (at least the maven dependency part) and send a pull request so the library can have an acceptable quality

I contacted the developer: They discontinued the work on this project altogether, which may explain the problems. I will probably have to modify it anyway. Thanks for the elaborative explanation about the mechanism. I will attempt your suggestions. — KorMed, Apr 08 '15 at 14:47

Maven build - force the use of a newer version

1 Answers1