Developing a new format

Sonatype Nexus Repository
, ,
1

Hi team,

We, at WSO2 (https://wso2.com/), are trying to implement a Nexus3 format to support Ballerina (https://ballerina.io/), an integration-specific open-source language, artifacts. I went through a few implementations (nexus-public/plugins/nexus-repository-maven at main · sonatype/nexus-public · GitHub, GitHub - sonatype-nexus-community/nexus-repository-composer: Composer support for the Nexus Repository Manager (work in progress!)). I understand that we need to implement Recipe classes for each type (hosted, proxy, group). In each of the Recipes, we need to attach a set of facets and a set of handlers through ViewFacet. However, I still couldn’t get the complete picture. I have a set of questions to clarify:

  1. Do we have a detailed guide on developing a new format, both backend and frontend?
  2. Which classes/interfaces (Facets, Handlers) should be implemented to run a basic prototype format?
  3. A Recipe is called when a repository is created and it attaches all the facets. Similarly, when is a Facet class or handler class called?
  4. Which classes/interfaces (Facets, Handlers) should be implemented to ensure security?
  5. I see a set of implementations related to the frontend here (nexus-repository-composer/nexus-repository-composer/src/main/resources/static/rapture at master · sonatype-nexus-community/nexus-repository-composer · GitHub). How does it work?
  6. Is there a specific folder structure to follow to organize the class/interface files?

It would be very helpful if you could share further information on implementing a secure, fully functioning format.

Thanks, Luhee

2

2./4. I would suggest when defining routes look at the handlers/facets common to both Maven and Raw, and duplicate the use.

  1. Handlers are invoked when the route(s) they’re attached to match an inbound request.

Facets are attached to a specific Repository instance and are accessible via repository.facet(MyClass.class). Some facets may be related to Nexus features (e.g. search) and would be invoked by those services. Facets you define wouldn’t have methods called unless you call them (e.g. by one of your handlers).

  1. Nexus has no specific requirements for the package structure.

If you’re looking at source code make sure you’re looking at the SQL related code, orientdb was removed from main but the community plugins still include it AFAIK.

3

Thanks :blush: @mpiggott. I was able to figure out a few things by debugging the Maven repository code. However, I still don’t understand how the UI part works. How can I configure my UI?

In my case, I don’t allow users to configure a custom URL for the proxy repository—it is always a hardcoded central repository. I had a structure similar to the one below for the UI:
nexus-repository-composer/nexus-repository-composer/src/main/resources/static/rapture/NX/composer at master · sonatype-nexus-community/nexus-repository-composer · GitHub.

Then, I removed a few configurations from the <FORMAT-NAME>Proxy.js file, as shown below:

Ext.define('NX.composer.view.repository.recipe.ComposerProxy', {
  extend: 'NX.coreui.view.repository.RepositorySettingsForm',
  alias: 'widget.nx-coreui-repository-composer-proxy',
  requires: [
//    'NX.coreui.view.repository.facet.ProxyFacet',
    'NX.coreui.view.repository.facet.StorageFacet',
//    'NX.coreui.view.repository.facet.HttpClientFacet',
    'NX.coreui.view.repository.facet.NegativeCacheFacet',
    'NX.coreui.view.repository.facet.CleanupPolicyFacet'
  ],

  /**
   * @override
   */
  initComponent: function() {
    var me = this;

    me.items = [
//      {xtype: 'nx-coreui-repository-proxy-facet'},
      {xtype: 'nx-coreui-repository-storage-facet'},
      {xtype: 'nx-coreui-repository-negativecache-facet'},
//      {xtype: 'nx-coreui-repository-httpclient-facet-with-preemptive-auth'},
      {xtype: 'nx-coreui-repository-cleanup-policy-facet'}
    ];

    me.callParent();
  }
});

Still, I couldn’t see those changes in the UI. Any idea on this?

4

You might be missing the maven plugin: nexus-repository-composer/nexus-repository-composer/pom.xml at master · sonatype-nexus-community/nexus-repository-composer · GitHub

5

@mpiggott, I have those plugins (extjs-maven-plugin, yuicompressor-maven-plugin) in my pom.xml. Instead of modifying my plugin, I made changes to the Composer plugin. However, the changes I made to ComposerProxy.js were not reflected in the actual UI.

I even removed the entire src/main/resources directory and the plugins mentioned above from pom file. Then, I compiled and placed the artifacts under the deploy directory. However, I still see all those components in the UI. Ideally, I shouldn’t see them in the UI, right?

Do I need to make changes anywhere else besides these JS files?

The below image shows the jar file that I added to the deploy directory

The below one shows the repository ui

6

Your screenshots seem to show composer, are you sure you’re not experiencing a name collusion with the builtin Nexus proxy in 3.75? Composer Repositories

7

@mpiggott The UI seems to be working now. It didn’t work initially as expected due to browser caching. Thanks for the assistance. :grinning:

8

I’m using version 3.72, which is why I haven’t encountered the name collision issue. I’m only using the Composer plugin as a reference to implement and reuse it for my own plugin.