Build: maven attempts to upload both the jar and the bundle, with the same name

[Hugo Wood]

Hello,

I have forked the swagger-core repository, made some changes, and now I'm trying to deploy my jars to a custom Nexus repo. Unfortunately, mvn deploy (run standalone or as part of mvn release:perform) fails at the swagger-annotations project (the first project in the reactor) because Nexus responds 400 Bad Request. After examining the logs, I've found that maven attempts to upload the main jar file twice: once a as classic jar, and once as a bundle, but both times with the same name. Nexus therefore refuses to overwrite the first upload and responds with 400. If I set the packaging to jar in the POMs of swagger-annotations and swagger-models, then everything goes fine.

I could do that modification, but I wonder why I have to do it. How does the swagger-core team does its build and deploys on Maven Central and not have this problem?

Thank you

Hugo Wood

[Aki Yoshida]

I think your local pom was forked from 1.5.0 has become inconsistent
with the upstream version.
swagger-annotation has been a bundle since 1.5.1. and the build should
create only a single jar which is a bundle jar and this should get
uploaded once.

> --
> You received this message because you are subscribed to the Google Groups
> "Swagger" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to swagger-swaggers...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Hugo Wood]

My fork is based upon 2c855e134180bee963cb62d29e65ce3c63ea68ff, which is 1 commit ahead of the 1.5.3 tag.

Well if you don't have the problem, then I must have introduced it when editing the POMs. I removed the root's parent (oss-parent) and plugins that sign the artifact. Could that be it? I'll continue to investigate.

> email to swagger-swaggersocket+unsub...@googlegroups.com.

[tony tam]

The swagger team doesn't use the mvn release plugin to do the release--we typically run the following:

mvn verify gpg:sign install:install deploy:deploy

I do believe you have to change the parent pom or it'll try to upload to sonatype.  Replace it with your repo settings and you should be fine deploying locally.  I suggest changing the version to append a suffix or you'll get really weird behavior and possibly checksum errors if your client accidentally pulls down mixed local & oss versions. 

[Hugo Wood]

Here's how I've edited the POMs: https://github.com/restlet/swagger-core/commit/4a65dd3a44b459563915080494d53c921acfe9e8.

I indeed removed the sonatype parent and added a suffix to the version.

[tony tam]

OK, and what command are you running?  Have you tried the one i suggested?

[Hugo Wood]

I'm simply running mvn deploy.

I've tried the simplest thing:

- check out 2c855e134180bee963cb62d29e65ce3c63ea68ff (just 1 commit ahead of the 1.5.3 tag)

- add my distribution management settings (nothing else)

- run mvn versions:set so it's a release

- run mvn deploy

And I still get the same problem. I examined the maven logs and it seems that everything is run twice. A first time, and then a second time as part of the maven-bundle-plugin:2.5.4:deploy goal. I've attached the logs to this message.

I then tried mvn verify gpg:sign install:install deploy:deploy, like you suggested. I edited the POM to skip the GPG part, and it works! Thank you very much for your help. :)

Does it mean that the POMs of the project are not quite correct for the deploy phase? Shouldn't mvn deploy work as expected? What do you think?

Hugo

[tony tam]

I am positive there are much more experienced maven gurus out there.  But in general, I use `mvn deploy` for uploading snapshots and the other command for uploading the release artifacts.

Is there a real issue if it runs twice?  It hasn't gotten in the way with the current release process.

[Hugo Wood]

The issue with uploading twice is that the Nexus repo refuses the second upload (you can't upload the same release multiple times) and the build fails immediately without uploading the rest of that jars.