Bitbucket plugin excluding log4j 1.x

[Paul Stein]

We have an old Bitbucket plugin that we are trying to migrate to work with the newer version of Bitbucket Data Center 9.4.x. 

As a 1st step I downloaded the latest version of Plugin SDK https://maven.artifacts.atlassian.com/com/atlassian/amps/atlassian-plugin-sdk/9.1.1/atlassian-plugin-sdk-9.1.1.tar.gz  and created a blank bitbucket plugin with `atlas-create-bitbucket-plugin`. 

However, when I try `mvn clean package` on it I am getting:

[ERROR] Failed to execute goal com.atlassian.maven.plugins:bitbucket-maven-plugin:9.1.1:copy-bundled-dependencies (default-copy-bundled-dependencies) on project test-bb-plugin: Unable to execute mojo: Execution null of goal org.apache.maven.plugins:maven-dependency-plugin:3.6.1:unpack-dependencies failed: Plugin org.apache.maven.plugins:maven-dependency-plugin:3.6.1 or one of its dependencies could not be resolved:
[ERROR] Failed to read artifact descriptor for log4j:log4j:jar:1.2.12

log4j 1.x is very old and is known to have security vulnerabilities and as such is removed from our corporate Nexus repository. Is there a way to exclude it or switch to alternative logging approach (current log4j 2.x / logback / slf4j)

[Ulrich Kuhnhardt _IzymesCo_]

Hi @Paul Stein 

few things to look out for

* use atlas-mvn and not mvn, this makes sure you pull in the right maven settings.xml

* pom.xml: > the plugin generator populates these with 'wrong' values

<bitbucket.version>9.4.0</bitbucket.version>

<osgi.javaconfig.version>0.6.0</osgi.javaconfig.version>

Remove 

<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>javax.servlet-api</artifactId>
    <scope>provided</scope>
</dependency>

* MyPluginJavaConfig: fix compile error.

To investigate where the old jar is coming from use atlas-mvn dependency:tree 

[Paul Stein]

@Ulrich Kuhnhardt _IzymesCo_ Thanks for your quick reply. At the moment I am only trying to build any Bitbucket plugin so whatever is coming out of the box is fine for me. Unfortunately, being behind the corporate proxy we are not at liberty to switch `settings.xml` going to the open Internet but in the past we able to proxy repositories if artifacts from them were required for the build. Looking at `atlas-mvn settings.xml` I see quite a few so that might be the next step, however we do proxy Atlassian at https://maven.artifacts.atlassian.com/ 

I opted out of OSGI with my 1st test, and opted in with the 2nd and it did not seem to make any difference other than having to fix a couple OSGI-related issues you mentioned.

I updated to 

<bitbucket.version>9.4.4</bitbucket.version>

to match with our installed version.

I cannot run `dependency:tree` yet since this error comes prior, but when I do `mvn -X clean package` I do see the offender:

[ERROR] Failed to read artifact descriptor for log4j:log4j:jar:1.2.12: Failed to collect dependencies at org.apache.maven.plugins:maven-dependency-plugin:jar:3.6.1 -> org.apache.maven.reporting:maven-reporting-impl:jar:3.2.0 -> org.apache.maven.doxia:doxia-site-renderer:jar:1.11.1 -> org.apache.velocity:velocity-tools:jar:2.0 -> commons-digester:commons-digester:jar:1.8 -> commons-logging:commons-logging:jar:1.1 -> log4j:log4j:jar:1.2.12: The following artifacts could not be resolved: log4j:log4j:pom:1.2.12 (absent)

I tried to force the latest `maven-dependency-plugin:jar:3.8.1` which does not seem to cascade down dependency chain to the log4j 1.x (at least on a first glance), but neither explicit version under `plugins` nor adding `<exclusion>` under `<dependencyManagement>` helped. I guess atlassian-plugin dependency management in play or something.