when I run the mvn release:perform, it fails when trying to upload to nexus:
Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on project edgent-parent: Failed to deploy artifacts: Could not transfer artifact org.apache.edgent:edgent-parent:pom:9.9.0 from/to apache.releases.https (https://repository.apache.org/service/local/staging/deploy/maven2): Failed to transfer file: https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/edgent/edgent-parent/9.9.0/edgent-parent-9.9.0.pom. Return code is: 401 I tried added a server decl to my .m2/settings.xml but it didn’t help. I was guessing at the server id based on the repository id “apache-release” in the pom. I also tried an id of “apache.releases.https” but that didn’t help. I can log into https://repository.apache.org with that id/pw. <server> <id>apache-release</id> <username>dlaboss</username> <!— my apache userid —> <password>my-encrypted-password</password> <!— my apache pw —> </server> What’s the correct thing to do? FYI I'm updating releasing.adoc as I go so no need for you to do that. Thanks, — Dale > On Jan 4, 2018, at 2:25 AM, Christofer Dutz <christofer.d...@c-ware.de> wrote: > > Hi Dale, > > that’s unfortunate that you had that many problems … I have to admit that the > branch operation directly pushes was new to me … the prepare operation > shouldn’t and the perform should only checkout. BUT I do know that for all > the data in the scm management block of the pom is important. So, you should > have forked, updated the scm information to your fork and then executed the > operations. > > Regarding the questions, the plugin asks: > “new working copy version” refers to the version all poms will have after the > release. > > The main duties of the release:branch and release:prepare is to update the > version information. In all cases will the originating branch’s version be > updated to the new working copy version. Branch will create a branch without > updating any version information and prepare will update all versions to the > release version (without SNAPSHOT) and tag that in git before updating it > again to the “new working copy version”. > > I thought these versions were self-explanatory, maybe I should elaborate a > little more on these. > > Chris > > > Am 03.01.18, 23:06 schrieb "Dale LaBossiere" <dml.apa...@gmail.com>: > > Hmm… > > per the releasing.adoc, I ran the release:branch step in a new clone of > the GitHub mirror repo (I neglected to clone the ASF repo) and it actually > auto-pushed 3 items to the ASF repo :-( (when release:branch completed, > there were still two commits pending/not-yet-pushed as expected) > > I also neglected to “git checkout develop” so these auto-pushed commits > were to the master branch (though they netted to a no-op change) :-( > > Lastly even after cleaning up (below) release/9.9 is still showing up in > the Branch pulldown of on the GitHub repo :-( Filed > https://issues.apache.org/jira/browse/INFRA-15777 > <https://issues.apache.org/jira/browse/INFRA-15777> > > When I tried again with a fresh ASF repo clone and on the develop branch, > release:branch is prompting and I’m not sure what to reply with - don’t > understand what the “new working copy version” terminology is really > identifying. Did you run with more -D options? I’m guessing it’s asking > about what to advance the develop branch version to (for the next release), > and when you were doing the 1.2.0 release I’m guessing that you must have > replied/specified 1.3.0-SNAPSHOT? > > @Dales-MacBook-Pro:604> git status > On branch develop > Your branch is up-to-date with 'origin/develop'. > nothing to commit, working tree clean > @Dales-MacBook-Pro:605> mvn release:branch -P > platform-android,platform-java7,distribution -DbranchName=release/9.9 > -DautoVersionSubmodules=true > … > What is the new working copy version for "Apache Edgent"? > (org.apache.edgent:edgent-parent) 1.3.1-SNAPSHOT: : > > > > FYI, from my first botched release:branch run: > > These 3 auto-pushed changes were now on master: > - commit of pom.xml on master (yikes) to change the scm-tag from > edgent-1.2.0 => release/9.9 > - created the release/9.9 branch > - commit of pom.xml on master to undo the prior commit (scm-tag back to > edgent-1.2.0) > > To cleanup I: > - deleted the release/9.9 branch locally and in the asf repo > Sadly, asf repo’s GitHub mirror still shows “release/9.9” in > its branch pulldown. > - “git reset —hard HEAD^^” followed by a “git push —force” to > essentially remove the above two commits on master > > >> On Jan 3, 2018, at 2:20 PM, Christofer Dutz <christofer.d...@c-ware.de> >> wrote: >> >> Hi Dale, >> >> I think I did write down all the steps involving Maven in the document: >> >> src/site/asciidoc/releasing.adoc >> >> The merge with the other RM doc is that the release-perform will create the >> source tar/zip we vote on in “target/checkout/target/***.tar.gz” and the >> corresponding zip. The files should follow the exact naming convention used >> to deploy it on the staging svn. >> >> In the last release, I manually created the directory structure and checked >> in the files. After that I used the existing scripts to deploy the voted-on >> release to prod. >> >> But it’s always good for others to try it too … and yes … it will do all the >> steps without pushing (it will however create a Maven staging repo). The >> staging repo is simply removed by a simple click and with the git repo, a >> simple forced git reset should do the trick. >> >> If you run into any problems, I’ll try to help as soon as possible. >> >> Chris >> >> >> >> >> >> >> Am 03.01.18, 18:26 schrieb "Dale LaBossiere" <dlab...@apache.org>: >> >> Hi Chris, >> >> At a high level, we need to ensure someone can reproduce what you just >> went through for 1.2.0. >> >> It feels like I should try going through the process for a, fictitious at >> the moment, 1.3.0 release. i.e., going all the way up to staging the >> release in dist.apache.org and in Nexus (“Closing the staging repository”), >> then cleaning that all up like it never happened (“Actions if the vote >> failed”, plus removing the release/1.3 branch). Does that make sense? >> >> As long as I don’t “git push” the created branch and pom-version-change >> commits, is cleanup as easy as just destroying my repo-clone? >> >> Looking at src/site/asciidoc/releasing.adoc, it looks pretty complete, >> but... >> >> In the vote-passed case, where’s the step / cmds to merge the release to >> master? >> >> In the vote-failed case, presumably the “fixes” are make on the release >> branch, and the eventual “Prepare” redo with the same args does what’s >> needed. But where’s the step / (cherrypick?) cmds to get the fixes to the >> develop branch? (imagine there are numerous commits for the fixes) >> >> I’m also unclear on the flow for a bug fix release like 1.2.1. Just make >> the changes on the release/1.2 branch and BEGIN the process with “mvn >> release:prepare … -tag edgent-1.2.1 -DdevelopmentVersion=1.2.2-SNAPSHOT >> -DreleaseVersion=1.2.1”? And again steps / (cherrypick?) cmds to get the >> 1.2.1 fixes to the develop branch. >> >> Once I can get through this I’ll update the RM-guide. At least initially >> I’ll leave releasing.adoc as is (covering what it covers) and just update >> the RM-guide accordingly and link to it. I don’t want to duplicate info and >> I don’t want to merge it into a single doc — unless you agree that migrating >> releasing.adoc content to the wiki (and removing releasing.adoc) is OK :-) >> >> — Dale >> > > >