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