Dependency error opensaml saml api and impl with Jira 11

Jira Development Jira Data Center
1

I am trying to update my Jira DC addon to Jira 11, but after update the jira.version number to 11.0.0 in pom.xml and using atlas-run I get the error message that dependency to Open SAML api and impl is not added resp. could not be resolved.

image
image1060×282 94.8 KB

What do I have to do? Any hints?

Best regards, Holger

2

Hi,

did you try adding them to you pom.xml ?

            <dependency>
                <groupId>org.opensaml</groupId>
                <artifactId>opensaml-saml-api</artifactId>
                <version>4.0.1</version>
            </dependency>
            <dependency>
                <groupId>org.opensaml</groupId>
                <artifactId>opensaml-saml-impl</artifactId>
                <version>4.0.1</version>
            </dependency>
3

Thank you very much! The dependency is then resolved. :slight_smile: Is this the right version? Is this provided by Jira? Guess I should add <scope>provided</scope>?

4

These types of errors are becoming more common.

These are transitive dependencies of jira-core, but are not provided by the maven central repositories:
e.g. https://mvnrepository.com/artifact/org.opensaml/opensaml-saml-api latest version that is public is 4.0.1. Since jira requires 5.0.0 the build will fail. Atlassian used to host or mirror these types of artifacts but no longer do that.

There are a long list of third party repositories that Atlassian want you to add to your maven configuration e.g:
from the plugin sdk:

maven-central Maven Central https://repo1.maven.org/maven2/ atlassian-proxy Atlassian Maven 2 Proxy https://packages.atlassian.com/artifactory/maven-atlassian-all/ terracotta Terracotta https://repo.terracotta.org/maven2/ gradle-plugins Gragle Plugins https://plugins.gradle.org/m2/ mulesoft Mulesoft https://maven.anypoint.mulesoft.com/api/v1/maven/ aspose Aspose https://releases.aspose.com/java/repo/ clojars Clojars https://clojars.org/repo/ sonatype forge Sonatype forge https://repository.sonatype.org/content/repositories/forge/ mulesoft-releases Mulesoft Releases https://repository.mulesoft.org/releases/ mulesoft-public mulesoft public https://repository.mulesoft.org/nexus/content/repositories/public/ typesafe Typesafe https://repo.typesafe.com/typesafe/releases/ jenkins-releases Jenkins https://repo.jenkins-ci.org/releases/

Generally - if you add all of those - you will have minimal issues.

Personally - I don’t like to trust so many third party repos - so instead whenever these issues come up, I simply add an exclusion to the product that is requiring the particular artifact. Especially in the case of stuff that we don’t directly need for the compilation of our apps.

e.g. in our pom.xml:

<dependency>
            <groupId>com.atlassian.jira</groupId>
            <artifactId>jira-core</artifactId>
            <version>${jira.version}</version>
            <scope>provided</scope>
            <exclusions>
                <exclusion>
                    <groupId>biz.aQute.bnd</groupId>
                    <artifactId>biz.aQute.bndlib</artifactId>
                </exclusion>
                <!-- The following exclusions are needed to compile, because these dependencies are no longer provided in Atlassian's Maven Repository -->
                <exclusion>
                    <groupId>org.opensaml</groupId>
                    <artifactId>opensaml-saml-api</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.opensaml</groupId>
                    <artifactId>opensaml-saml-impl</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>jta</groupId>
                    <artifactId>jta</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>jndi</groupId>
                    <artifactId>jndi</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>net.sf.ehcache</groupId>
                    <artifactId>ehcache</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>commons-httpclient</groupId>
                    <artifactId>commons-httpclient</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

The other approach recommended above, just overrides the version that your IDE sees. In my opinion it is not really a particularly useful fix - and very easy to accidentally compile extra stuff into your jar - e.g. by forgetting the provided

1 Like