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
>> 
> 
> 
> 

Reply via email to