State and future of Composer support (community plugin clashes with official implementation)

Sonatype Nexus Repository
,
1

Hi,

I’ve been working on the Nexus Repository Composer Format community plugin (sonatype-nexus-community/nexus-repository-composer on GitHub) recently including major refactoring for compatibility with Nexus 3.71+ datastore format.

In 3.75 official Composer Proxy support arrived as a Pro feature and now with 3.77 it’s available in the Community edition as well. So far, so great :smile:

But … my problem now is: The community plugin competes with the official plugin, e.g. using the same format id composer - not really surprising.
Didn’t inspect what’s really going on under the hood, i.e. which implementation wins for existing composer-proxy repos, but before the login the security module already fails

Failed to get state from com.google.inject.internal.InjectorImpl$1 (ignored)
java.lang.IllegalStateException: nx-repository-view-composer-*-delete already exists

Removing the community plugin results in startup error

Missing recipe: composer-hosted`

… well, obviously.

Database has already been upgraded, so the only way to fix this instance without restoring a backup is removing the feature from nexus-community-feature-3.77.0-08-features.xml (simple setting the feature flat nexus.format.composer.enabled=false does not help in this case)

For instanced with only proxy repos, we can just delete the community repos, upgrade without the plugin. re-create them and we are good to go. Hosted or group repos require the above workaround.

Sources for the official plugin don’t seem to be anywhere available in nexus-public or similar repos (or I just didn’t find them yet), so we can just guess or reverse-engineer stuff to make it compatible again. Rewriting the community plugin to support groups of mixed types is also far from trivial on that basis.

(not really relevant for the actual question, just had to leave this note somewhere)

Overall, I’m little frustrated about the lack of communication regarding community plugins. Pinging people on the repo to approve changes works kinda okay, but no feedback whatsoever about effectively breaking a community project without any hint to the contributors… Absolutely OK to move stuff to the official codebase and that these get prioritized, but the way it has been done here doesn’t really encourage to spend time and resources on such projects

So what I’d like to know is:

Are there plans to extend Composer support to Hosted and Group repositories? (so the Community plugin can be deprecated and replaced within a reasonable timespan)

And are there any developer guidelines to avoid such clashes in future development?

2

Hi Stefan, our apologies for putting you in a difficult position. You’ve been working hard to add useful functionality to the ecosystem, and we should have anticipated the impact and communicated about it better. We do have a number of changes coming, and we’d like to reach out to you to discuss them. Can we use your email that you provided for the forum login?

3

Hi Miguel,

I totally understand that business decisions have priority and frankly, I was quite surprised about the amount of feedback from the Composer plugin refactoring (as often, feedback starts after things break). I appreciate that it’s now a (partially) supported feature. (among other positive developments)

There are workarounds as described above or in a related PR and it just broke an OSS staging instance, so no damage done. But I‘m not sure how many users are really aware of what “unsupported“ means, just update and …

Can we use your email that you provided for the forum login?

Sure, feel free to use that address.

4

Hi,

I’m actuallu using nexus-repository-composer and I have the same problem.

We are currently stuck with the version 3.75 since January.

It contradicts our organization’s policy, where we must update our services every month if new versions are available :confused:

Could you update me on this matter?

Thank you

5

Up to 3.77.x you can remove the official plugin from your Nexus instance and add the community version as before.

Basically remove the “nexus-repository-composer” entry from
"$NEXUS_HOME"/system/com/sonatype/nexus/assemblies/nexus-community-feature/*/nexus-community-feature-*-features.xml

(see modified Dockerfile in PullRequest #175)

For 3.78 this will no longer work due to major internal changes. The plugin actually compiles and runs with 3.78.1, but today there is no clean way to integrate it.

If you use proxy repos, it’s probably easier to remove the repos, update without the community plugin and re-add the repos using the official plugin. For hosted repos … well, unless you like a hacky solution, stick to <=3.77 until plugin capabilities are available again and the plugin is updated.

1 Like
6

Hi Stefan,

Thank you a lot for your workaround.

I will set up on our pre-prod.

Yes I saw the big breaking changes in the release for 3.78.

Thank you again

7

Hello there, I was trying to the upgrade of our instance of OSS version on OrientDB, after a lot of trouble as you know already I managed to change OrientDB to h2, and then …
Well you know the story, I just saw the 3.78.1 version and all.
I’ve already contributed to the composer repository in the past and I’m willing to discuss to find a solution.
Did you get any feedback Stefan? I’m also available if necessary to help for this issue and maybe add the whole implementation or better one on the official version.