On 5 May 2016 at 05:49, Josh Elser <els...@apache.org> wrote:
>
>
> sebb wrote:
>>
>> Have a look at the scripts in
>>
>> http://svn.apache.org/viewvc/commons/scripts/
>>
>> I used those for VALIDATOR and NET.
>
>
> Cool. Thanks for sharing. It would be good if the generic commons release
> documents referenced these if they are expected to be re-used by other
> commons projects' RMs.
They are brand new, and possibly still needing some tweaks.
They don't work wit Git.
>> On 4 May 2016 at 04:43, Josh Elser<els...@apache.org> wrote:
>>>
>>> Here's what I've been doing. The generic instructions are woefully
>>> incomplete (before someone chimes in again - no, not just because "VFS is
>>> a
>>> multi-module project"). I think I have this on point for rc1, so I'm
>>> writing
>>> it down here before I forget (we can figure out where it *should* go
>>> later).
>>>
>>> rc0 only:
>>> # Make the branch
>>> $ svn cp trunk branches/VFS-XXX
>>> $ cd branches/VFS-XXX
>>> # Set the proper versions
>>> $ mvn release:prepare
>>
>>
>> We use a tag not a branch, but perhaps that is what the release plugin
>> does.
>> In which case I assume the branch is taken to avoid mangling trunk?
>
>
> release:prepare doesn't do the tagging (this is what release:perform does).
> All it's really doing are some pre-condition checks and version updates.
OK
> TBQH, I don't have any idea how the maven-release-plugin and SVN are
> remotely useful for the ASF's vote-then-promote process.
I agree.
It's just wrong that trunk is updated before the release succeeds.
However using a temporary branch would solve that.
> That said, it's ok if I don't get it. This is what worked for me and I'm
> happy with it. If there's something obvious I could have done differently,
> great.
>
>>> ---
>>>
>>> # Or just set it to your JDK6 installation -- this works on OSX
>>> $ export JAVA_HOME=$(/usr/libexec/java_home -v1.6)
>>>
>>> # Where ${asf.username} for me is "elserj"
>>> $ mvn clean package -Duser.name=${asf.username}
>>
>>
>> No need to use package if using CP40
>
>
> What are you using instead of `package` to build the code...
mvn deploy
>>
>>> # Set back to 1.7 because my 1.6 installation has trouble deploying to
>>> nexus
>>> $ export JAVA_HOME=$(/usr/libexec/java_home -v1.7)
>>
>>
>> So does mine; in which case use -Pjava-1.6 below.
>>
>>> $ mvn deploy -Prelease -Duser.name=${asf.username}
>>>
>>> # This is what could be consolidated via one invocation of `mvn site`
>>> $ mvn site:site site:stage
>>>
>>> # Move back to the root SVN repo
>>> $ cd ../..
>>> $ svn cp branches/VFS-XXX tags/commons-vfs-project-XXX-rcN
>>
>>
>> Isn't that what the release plugin does?
>>
>> You might find
>>
>> http://svn.apache.org/viewvc/commons/scripts/create_RC_tag.sh
>>
>> easier to use - it does it all for you without needing to create a
>> temporary branch.
>
>
> Cool. I didn't find these from the generic commons release document.
They are very new.
>>> --
>>>
>>> Things not covered above:
>>>
>>> * Copying artifacts (tarballs/zips, xsums, and sigs) into
>>> dist.a.o/dev/commons/... (building md5/sha1 files)
>>> * Closing staging repo in Nexus
>>
>>
>> That can be done using Nexus2DistDev.sh
>
>
> Again, great. It would have been good to know about these beforehand.
They did not exist then...
>>
>>> --
>>>
>>> Some things that could still be improved that I didn't fix:
>>>
>>> * Artifacts in dist/target are renamed when they're installed/deployed,
>>> but
>>> not in the local directory. Should do a rename of the file on disk so
>>> that
>>> what is on the RM's computer matches what is in their m2 repo and ASF
>>> nexus.
>>
>>
>> Or ignore the local copies and use Nexus2DistDev.sh which copies the
>> bin/src artifacts from Nexus and deploys to dist/dev and can remove
>> them from Nexus before closing the staging repo.
>>
>> AFAIK only the deploy directory (i.e. Nexus) has the hashes.
>>
>>> * `mvn site` which invokes site:site and site:stage automatically (which
>>> would make for a more natural build process -- `mvn deploy` would build
>>> the
>>> site automatically)
>>
>>
>> I don't follow that.
>
>
> `mvn site` is invoking the "site" maven lifecycle phase. "mvn site:site` and
> `mvn site:stage` are invoking executions on the maven-site-plugin. These are
> two distinct kinds of actions. We can configure the maven-site-plugin
> (and/or other necessary tasks) to run at the 'site' lifecycle phase for a
> more 'natural' process.
>
I see.
I meant I did not see why 'mvn deploy ' would/should create the site.
>>
>>> Again, for now, this is just for my benefit. When this is all over, I'll
>>> try
>>> to add this all to the website. Please point out anything wrong/missing.
>>> Thanks.
>>>
>>> - Josh
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
