Hi guys,

Any idea about when we can use this extensions form Nexus v3.x?

Thanks in advance
Regards
Juanlu

Doing:

npm update
gulp

on a local clone of the extension generates a vsix file with missing node_modules:

listing the contents of the archive gives out.1.txt

whether the original vsix gives out.2.txt

My node & npm versions:

λ npm version
npm info it worked if it ends with ok
npm info using [email protected]
npm info using [email protected]
npm info ok
npm info it worked if it ends with ok
npm info using [email protected]
npm info using [email protected]
{ npm: '3.9.5',
  ares: '1.10.1-DEV',
  http_parser: '2.5.2',
  icu: '56.1',
  modules: '46',
  node: '4.4.4',
  openssl: '1.0.2h',
  uv: '1.8.0',
  v8: '4.5.103.35',
  zlib: '1.2.8' }
npm info ok

Nexus supports multiple repository types
Maven, Nuget, OBR, NPM, RubyGems and Site (as of Nexus version 2.12)

Currently this plugin only supports Maven repository uploads.
Can the plugin be altered to allow the build to select a valid upload repository for technologies other than maven?

Hi Team,

I am trying to upload multiple file on nexus repo, but it is failing.

Error

##[error]Error: form-data: ENOENT: no such file or directory
I have also tried using the wildcard entries like **/*, *. But still it is failing.
Upload failed. Error: form-data: ENOENT: no such file or directory, open 'D:\a\1\a\**'

Is this the drawback of this plugin?

Nexus allows custom url formation.
So it's possible to have a url to access nexus with the format http://nexusserver
Using the service endpoint creation (I've logged a separate bug with TFS),
a / will automatically be appended to the service endpoint.
This results in the service endpoint url being http://nexusserver/
The script for the plugin has the following line of code
var nexusUploadUrl = serverEndpointUrl + '/service/local/artifact/maven/content';
this results in a nexus upload url of
http://nexusserver//service/local/artifact/maven/content
which is an invalid url.

Hello,

I had the same idea as you and I have created the same build task, however, implemented in PowerShell. It is not yet on the marketplace as I was waiting the legal department from SonaType to give me a go to use their logo and name.
As there may not be the need to have two separate plugins, I would like to suggest a couple of things I already have working and I do find handy.

• Support for Nexus v3 API
• Support for GAV parameters being loaded from POM file
• Specific type of service Endpoint
• Multiple file upload

If you are interested in those and in accepting my work, I would try to implement those in TypeScript.

The "Packaging" input is a free-text field. This presents 2 problems:

1. It would be easy for someone to enter an unsupported value
2. Nexus looks to only support set values: pom, jar, ejb, war, ear, rar, par, maven-archetype, or maven-plugin
   We should make this field a drop-down with set options to make it less-fragile.

I currently have the docker container with nexus 3 installed.
I am able to run the deployment from my local machine with the "mvn deploy" command, but when I attempt to deploy with this extension, I receive the following error:
##[error]Upload failed, HttpResponse.statusCode: 405, HttpResponse.statusMessage: Method Not Allowed

My settings look like:

• Endpoint: "http://name.westus.cloudapp.azure.com:8081/repository/maven-snapshots/"

• Repository Id: maven-snapshots

• Group Id: maven-snapshots

• Artifact Id: newArtifact

• Artifact Version: 1.4-SNAPSHOT

• Packaging: jar

• File: The .jar produced from the build output

• Classifier: $(Build.BuildId)

Do I possibly have the url formatted wrong?
I have tried:
http://name.westus.cloudapp.azure.com:8081/repository/ which gives a 404, not found error.
http://name.westus.cloudapp.azure.com:8081/ which gives "Error: read ECONNRESET"

Does this build extension support uploading to the recently released Nexus Repository Manager OSS 3.0? Sorry couldn't find a way to post a question.

When the Nexus repository is hosted under https, if the certificate issued to the server is not valid, the request to upload the file will fail.
In some cases, there is the need to bypass this behavior, for example, if the certificate is a self signed certificate, or the root certificate authority is an Enterprise Root CA.

In this code, it appears the task will succeed if the upload fails. The error handling block should return instead of continuing execution.

request.post({ url: nexusUploadUrl, formData: formData }, function optionalCallback(err, httpResponse, body) {
    if (err) {
        tl.setResult(tl.TaskResult.Failed, err);
    }
    tl.debug('Upload successful, server responded with: ' + body);
    tl.setResult(tl.TaskResult.Succeeded, 'Successfully uploaded ' + fileName);
}).auth(username, password, true);

The "Extension" input field is currently free-text. It is unclear whether its value should be preceded with a period, such as ".jar" which is the standard format of a file extension. When preceded with a period, it doesn't match one of the supported Packaging field values, and these fields should correlate.

The TypeScript code should strip any preceding period from the file extension so that it correlates with the expected Packaging field values.