I added another entry for apache.snapshots.https and changed both to have my pw in the clear… and it worked! Hmm.
> On Jan 9, 2018, at 6:48 PM, Christofer Dutz <christofer.d...@c-ware.de> wrote: > > Aaaaahhh … I just noticed that I have a duplicate definition of the repos (in > our pom and in the apache root). > I needed that in order to have the repo urls in the generated maven site, but > the ids should match. > But in my case I have no credentials for “apache-release” or > “apache-snapshot”. So probably the root definitions are used. > > Chris > > Am 10.01.18, 00:26 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>: > > Hi Dale, > > well the id should be apache.releases.https for a release version and > apache.snapshots.https for snapshots. The apache-release is just the name of > a profile in the apache root pom. I don’t have my password encrypted though, > but otherwise my setup is the same. > > Chris > > Am 09.01.18, 23:41 schrieb "Dale LaBossiere" <dml.apa...@gmail.com>: > > 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 >>> >> >> >> > > > > >
