Atlas-debug fails in atlassian sdk 8.2.6 if there is a profile with jira-maven-plugin

Jira Development Jira Data Center
, ,
1

Steps to reproduce:

  • atlas-create-jira-plugin

  • Edit pom.xml. Add following profile:

    <profiles>
        <profile>
            <id>jira</id>
            <build>
                <plugins>
                    <plugin>
                        <groupId>com.atlassian.maven.plugins</groupId>
                        <artifactId>jira-maven-plugin</artifactId>
                        <version>${amps.version}</version>
                        <extensions>true</extensions>
                        <configuration>
                            <products>
                                <product>
                                    <id>jira</id>
                                    <instanceId>jira</instanceId>
                                </product>
                            </products>

                            <productVersion>${jira.version}</productVersion>
                        </configuration>
                    </plugin>
                </plugins>
            </build>
        </profile>
    </profiles>
  • Run atlas-debug

Expected results:

  • Jira on debug mode is started

Acutal Results:

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.536 s
[INFO] Finished at: 2020-11-30T12:19:33+01:00
[INFO] ------------------------------------------------------------------------
[ERROR] No plugin found for prefix 'com.atlassian.maven.plugins' in the current project and in the plugin groups [com.atlassian.maven.plugins, org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (/Users/tomasmartynowicz/.m2/repository), atlassian-public (https://maven.atlassian.com/repository/public), atlassian-plugin-sdk (file:///usr/local/Cellar/atlassian-plugin-sdk/8.2.6/libexec/repository), central (https://repo.maven.apache.org/maven2)] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/NoPluginFoundForPrefixException
sh: line 1: jira-maven-plugin:8.1.0:debug: command not found

Judging by the command output the problem is on the MVN_COMMAND variable

Executing: /usr/local/Cellar/atlassian-plugin-sdk/8.2.6/libexec/apache-maven-3.5.4/bin/mvn com.atlassian.maven.plugins:jira-maven-plugin
jira-maven-plugin:8.1.0:debug -gs /usr/local/Cellar/atlassian-plugin-sdk/8.2.6/libexec/apache-maven-3.5.4/conf/settings.xml
2 Likes
2

Hey, @TomasMartynowicz, indeed, looks like a bug in latest atlassian SDK.
As a work-around you could change the
$ATLAS_HOME/bin/atlas-debug script’s definition of MVN_COMMAND from:

MVN_COMMAND="com.atlassian.maven.plugins:${MVN_PLUGIN}:${AMPS_PLUGIN_VERSION}:debug"

to:

MVN_COMMAND="com.atlassian.maven.plugins:jira-maven-plugin:${AMPS_PLUGIN_VERSION}:debug"
6 Likes
3

Thanks @sergey. I tried your workaround and it worked

4

Got hit with this as well. Still broken Atlassian! Sergey, your workaround fixed it for me.

2 Likes
5

Hey @sergey, This solution worked in my Mac too. Thank you! :slight_smile:

1 Like
6

Does the trick. Thanks

7

Hi folks, we’re looking to address this in a release coming quite soon, see [ATLASSDK-220] - Ecosystem Jira to track progress on this particular bug. Thank you for your patience so far!

1 Like
8

NEW_PLUGIN_ARTIFACT_ID=$(grep -F "${newPlugins}" pom.xml | head -1 | sed -n 's:.*<artifactId>\(.*\)</artifactId>.*:\1:p')

works for me and stays plugin/add-on/app agnostic. head -1 in the pipe seems to solve the problem.

9

@here - this isi not limited to the jira-maven-plugin - the issue is for all products.

10

Hi again, the latest version of the SDK addresses this bug and other potential inconsistencies with identifying AMPS versions. Overall the new method should be a lot more reliable, including in projects where AMPS version is specified in a parent pom. Let me know if you encounter any other bugs.