Octopus unable to parse Maven package name with underscore and dot

Hi guys, I have an issue with Octopus not being able to parse the name of a package in the Maven feed.
We have some Scala code artifacts there and we add Scala version at the end of the package name (e.g com.mycompany:some-package_2.11). When I try to use test action from the feed and search for this package, I find nothing. When I create a release with this package id, it shows error inside the release:

Failed to retrieve notes: Maven artifact com.mycompany:some-package_2.11 version 1.13.0-SNAPSHOT was not found.

It was not bothering me for a while, but right now I’m trying to setup Octopus-Jira integration and Octopus doesn’t detect build information pushed for a non-existent (as it shows in the UI) package.
Problem is only reproduced for packages with scala version specified _2.11, others can be successfully searched during the feed test and they are correctly represented in the release information.
Is there any fix tor this?

Octopus server version I use is 2020.5.6

Hi @timur.shagapov.sme,

Thanks for reaching out.

I’m going to try to reproduce this behavior on my end, but in the meantime please let me know if you have any other questions or information to pass along.


Hey @timur.shagapov.sme,

Can I get a bit more information about your setup, please?

What are you using to host your maven feed?
What is the file name when you are uploading it? is it some-package_2.
Can you also send a screenshot of how it sits in the file structure of the feed?
Are you wanting the version to be 1.13.0-SNAPSHOT, or something else?
By which method are you creating your release? If via octo cli, can you please send me the command you’re using?

Please feel free to DM me anything that need to be private.

Please let me know if you have any questions.


Thank you for jumping on in, Jeremy!

  1. Maven feed is hosted on Nexus Repository version 3.27.0.
    2 & 3 & 4) Filename is usually something_2.11-1.13.0-SNAPSHOT.jar For snapshots it looks like that:

    our release feed:
  2. The version of release depends on a channel we’re creating release in:
    develop channel - release is created with package version x.x.x-SNAPSHOT, but the release itself is called x.x.x-[date][time][commithash], so it’s a new release on each new build.
    release channel (sorry for tautology :slight_smile: ) - release is created with version x.x.x[-suffix(if exists)].
    BTW we don’t have issue with the deployment itself - it works well and we can download the package on the node, here is an example of how it is referenced in our step template:
  3. We use octo cli on jenkins agent to create the release, the command is:
    dotnet octo create-release --project ${octopusProject} --version ${version} --packageVersion ${packageVersion} --channel '${octopusChannel}'
    The version is the same for both ${version} and ${packageVersion} in case of release channel, but for develop channel $packageVersion = x.x.x-SNAPSHOT and $version is x.x.x-[date][time][commithash]

Hi @timur.shagapov.sme,

Thank you for all of the information.

Can you please show me the build information screen (Library->Build Information) for the package in question where it shows all the versions for that specific package ID that have build information?

Here is an example:

I’m wondering if the package name and versions are identical to the ones being stored in the Build Information tab, as they have to be identical on both parts for it to work correctly.

Please let me know.


Hi @jeremy.miller, actually there are no Maven build information in our list.
I was suspicious about it, and I checked the pipeline itself and it turned out we haven’t correctly handled octo build-information exit code. I found out that I can’t push any build information for Maven packages because of error 400.
octo build-information --package-id='com.mycompany:something-exploration_2.11' --file='buildInfo.json' --overwrite-mode='OverwriteExisting' --version 1.0.0-RC4

Space name unspecified, process will run in the default space context
Handshaking with Octopus Server: https://my.octopus.url
Handshake successful. Octopus version: 2020.5.6; API version: 3.0.0
Authenticated as: Timur Shagapov <timur.shagapov@mycompany.com>
Pushing build information for package "com.mycompany:something-exploration_2.11" version "1.0.0-RC4"...
There was a problem with your request.

 - The package ID contains invalid characters. Examples of valid package IDs include 'MyPackage' and 'MyPackage.Sample'.

Error from Octopus Server (HTTP 400 BadRequest)
Exit code: -7`

I tried removing _2.11 suffix just for test, but it still fails. Looks like colon is not allowed and it prevents from pushing any build info for maven packages since all of them has this colon

Hi @timur.shagapov.sme,

Thanks for all of the information.

I think you’re right, this looks to be an issue with the colon in my testing. I’m going to speak to our developers and see if I can’t get some more information surrounding this.

Please feel free to reach out in the meantime.


Hi @timur.shagapov.sme,

Thanks for your patience with this one.

This does appear to be a bug.

Here is an open issue for you to subscribe to to get updates on. Can't Push Build Information for PackageIDs in Maven Feeds · Issue #6904 · OctopusDeploy/Issues · GitHub

Please let me know if you have any other questions or concerns.


1 Like

Hi @jeremy.miller , I have a question regarding the second issue - were you able at that time to reproduce the issue with Maven packages being marked as “Missing” if they have _2.11 in their name? Since this seems like a separate issue.

Hey @timur.shagapov.sme,

Sorry, I think I had assumed the only issue was the colon, but I can ask if that schema should be allowed by Octopus and if so I will investigate and open an issue.

Just to confirm, you do want _2.11 to be a part of the packageid and not the version?

For instance PackageName_2. , the package Id is bold and the version is code formatted?

Please let me know if you have any questions in the meantime.


In case of Maven I assume that such approach should work: if there are numbers separated by dots, but they are not preceded with a hyphen, they should be part of the package id.
E.g. this-is-package-id_2.11-1.0.0-RC1 (as you can see the default separator in Maven is hyphen instead of the dot)

Hey @timur.shagapov.sme,

I went ahead and tested it on my end.

Nexus version: Sonatype Nexus Repository Manager
OSS 3.30.1-01
Octopus Version: 2021.1.7316

Maven Feed:


It looks to work on my end, so this may be something that got fixed between our versions.

Are you seeing something in my setup that I didn’t account for that may be different in yours?

Please let me know.


I updated my Octopus and Nexus to the same versions like you mentioned, but the issue still persist. Interesting thing - tried to get the package versions from the API, and I actually was able to do that for the release feed (we have two different feeds for standard packages and snaphot ones), but there were no packages with version higher than 1.12.0 (in reality there are a lot of packages with higher version). For the snapshot feed I haven’t been able to get even a single package version.
I used this request:
curl -X GET "https://octopus.my.zone/api/feeds/<feed-id>/packages/versions?packageId=com.mycompany%3Asomething-etl-apps_2.11&take=2147483647&skip=0&includePreRelease=True" -H "accept: application/json" -H "X-Octopus-ApiKey: API-mykey"

Maybe there is a way to get what’s going inside the octopus there from the logs? So far I only found there records when I tried to search for maven package in a wrong format

Hi @timur.shagapov.sme,

Sorry to hear you’re still hitting this.

When you do test feed within your Library->External Feed for that snapshot feed, are you seeing packages? If so, can you please show me a screenshot of a step where you are using a package to see how it’s setup? Are you able to curl packages directly from the feed with maven commands outside of Octopus using the same artifact and version?

Please let me know.


Hey @jeremy.miller , sorry for delay - no, I can’t see any packages in the UI when trying to list them via Library->External Feed for both feeds (and API calls only return incorrect list for the release feed and empty list for snapshot feed). The artifact is available outside of Octopus UI, even Octopus server is able to download it during deployments itself.
The step is based on a script step template with package reference:

And in the project it is referenced like:

Hi @timur.shagapov.sme,

Thanks for all of the detail.

I think we should probably focus on the packages not showing up in the feed test as our first step.

As you can see here when I search for a known package named similarly to yours, it works:

Here is how I have my feed setup:

I am an admin within that nexus repo.

Can you please check to make sure your feed settings are correct, and then show me what you get when you try to search for a known good package?


Here is my feed setup:

I have a specific readonly user for Octopus in my Nexus, but just for testing purposes I gave it admin permissions.
Here is me trying to find existing package without _2.11:

With _2.11:

Do you host your Octopus Server installation in docker? In my case this is a usual application running under Windows Server 2019 with DB hosted in AWS RDS (Microsoft SQL Server 2017)

Hi @timur.shagapov.sme,

That’s definitely strange that we’re getting different results if we’re on the same versions of both Octopus and Nexus.

I am running my reproduction in cloud, so yes it’s a docker container. I can attempt to run it as a regular windows application and update you with my results.

Just to confirm, you are still on version 2021.1.7316?


Yes, it is 2021.1.7316

Hey @timur.shagapov.sme,

I’ve spun up 2021.1.7316 on a Windows Server 2019 VM as a normal app, and I am able to see the package with the same feed and test.

It might be worth digging into your pom/xml on your maven feed between that working test and the nonworking one above. There might be some difference in the appender vs -etl-apps that we haven’t thought of that’s causing the search to not work.

Please let me know what you think.