On 3/30/11 10:24 AM, sebb wrote: > On 30 March 2011 17:03, Phil Steitz <phil.ste...@gmail.com> wrote: >> On 3/30/11 5:39 AM, sebb wrote: >>> On 30 March 2011 08:01, Luc Maisonobe <luc.maison...@free.fr> wrote: >>>> Le 30/03/2011 03:36, Gary Gregory a écrit : >>>>> Wait! I'm not done or I'm loosing my marbles... >>>>> >>>>> I followed the whole song and dance from: >>>>> >>>>> http://wiki.apache.org/commons/UsingNexus >>>>> >>>>> It's the last time I'll pick that route. >>>> For what its worth, for math 2.2 I used a mix of Phil scripts for the >>>> beginning and Nexus for the rest, using the wiki as a guideline. In this >>>> case the process was a little convoluted, because we create both a >>>> trimmed down version of the site to hold only the user guide and to be >>>> put in the docs archives, and we create a complete site to be uploaded. >>>> >>>> For the last release candidate, it worked well. Phil asked me to >>>> document it and extend the scripts if needed, and I forgot to do it in >>>> time, sorry :-( >>>> >>>> The one thing I found cumbersome was that part of the process pushed >>>> non-maven artifacts on Nexus, that had to be manually moved away. >>>> Furthermore, these are what we consider here the real Apache artifacts >>>> (i.e. the ones that are available in the download page, not the ones >>>> that are at last published in maven repository). >>> I asked about extending Nexus so it could handle non-Maven staging, >>> and that did seem to be possible, but whether it will ever be >>> implemented, I don't know. >>> >>> That would be ideal. >>> >>>> I also have some slight concerns using a proprietary product, but as it >>>> secures some things as Sebb says, I can live with it. >>>> >>>> Is it possible to find some intermediate approach, extending Phil >>>> scripts, pushing only the maven part on Nexus directly without having to >>>> log on Nexus web interface ? The last part (not logging to close the >>>> staging area) may reduce the safety we get and risk some spurious >>>> publish as Sebb explained, but with several independent scripts, this >>>> could leverage the risk. >>> Separating the deployments of Maven and non-Maven artifacts might be >>> possible, but I'm not sure I have enough Maven-foo to do it. >>> >>> It would mean removing the non-maven stuff from deploy, and using some >>> other means to copy the non-maven stuff to a separate staging >>> directory. >>> >> There is this cool command called "cp" that works very well. There > Does not work natively on Windows or various other OSes.
Last I checked, we do not run Windows on ASF infra at this point. We are talking about moving stuff from ASF host to ASF host here. For that, unix commands work just fine. >> is another one called "tar" and even one called "scp" ;) If the >> problem is that we want to be more paranoid than we are with the >> mirrors for the maven stuff, why can't we just get access and copy >> the files we want to put in the staging repo? Or write a simple >> script that moves the kind of thing that I have sitting now in >> http://people.apache.org/~psteitz/pool-1.5.6-rc2/maven/ >> to the "staging repository" and another script or command that >> "promotes" it. It seems ridiculous to me that we need to introduce >> a proprietary GUI tool to just move files on ASF hosts. > Nexus does more than just move files around. > > It maintains the maven-metadata.xml file, and checks that the > signature is correct. > It also ensures that the file is uploaded to the correct directory > based on the groupId. > There are probably other features I have not encountered. > > If someone wants to spend time creating and maintaining an alternative > tool, fine, but don't overlook the benefits that Nexus brings. > > At present I think it's great that I can do a "mvn deploy" and not > worry that it might be published accidentally. > > Nexus makes it easy for non-Unix types to inspect the files and delete > any that should not be there or upload others that are missing. > I get that, which is why I think some kind of middle ground where we provide simple scripts to move stuff around on the ASF hosts might be a good compromise. This is essentially what the ibiblio-rysnch stuff does. The only manual missing piece is correctly updating the maven-metadata (which logically the assembly or other such plugin could do locally) and maybe some kind of check to make sure that things are deployed to the right directories. I like much better to be able to inspect the artifacts that I am about to put out to vote locally. That is why I have never liked "mvn deploy." I understand that others don't care so much about that and are willing to trust maven to put what they think it is going to deploy to where they think it is going to. With all the layers of pom inheritance and history of bugs, I don't trust this approach and it saves me no time personally. I also understand that some Windows users may not want to mess with Cygwin or other tools to provide scp and such, but I would prefer that at least this route remain open to those of us who like to package and test locally and deploy release artifacts manually. Phil >> Phil >> >> Phil >>>> Luc >>>> >>>>> I cannot seem to have published the Maven bits to Maven places. There is >>>>> no >>>>> 1.5 here: >>>>> >>>>> http://repo1.maven.org/maven2/commons-codec/commons-codec/ >>>>> >>>>> Because it is not here: >>>>> >>>>> /x1/www/people.apache.org/repo/m2-ibiblio-rsync-repository/commons-codec >>>>> >>>>> What does "Promote" out of Nexus do then? >>>>> >>>>> Should I copy the files to /www/ >>>>> people.apache.org/repo/m2-ibiblio-rsync-repository myself per >>>>> >>>>> http://commons.apache.org/releases/release.html >>>>> >>>>> under the section "3 Deploy Maven Artifacts"? >>>>> >>>>> Or will that cause problem with work I did in Nexus (for the last time?) >>>>> >>>>> Thank you >>>>> >>>>> Gary >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: sebb <seb...@gmail.com> >>>>> Date: Tue, Mar 29, 2011 at 10:15 AM >>>>> Subject: Re: [VOTE] Release Apache Commons Codec 1.5-RC1 >>>>> To: Commons Developers List <dev@commons.apache.org> >>>>> >>>>> >>>>> On 29 March 2011 04:45, Gary Gregory <garydgreg...@gmail.com> wrote: >>>>>> On Mon, Mar 28, 2011 at 11:21 PM, Phil Steitz <phil.ste...@gmail.com> >>>>> wrote: >>>>>>> On 3/28/11 4:49 PM, Gary Gregory wrote: >>>>>>>> I am having a heck of a time pushing the release out. >>>>>>>> >>>>>>>> I cannot seem to be able to create the sym links per the instructions >>>>> in >>>>>>>> http://wiki.apache.org/commons/UsingNexus >>>>>>>> >>>>>>>> I cannot get the symlinks.sh script working. I copied it to my home bin >>>>>>>> directory. When I invoke it, it is not found. Just running it from my >>>>>>> home >>>>>>>> bin w/o args does give me the usage I get: >>>>>>>> >>>>>>> You need to run it from the dist directory where the links are going >>>>>>> to be created and you need to give it the release number. See steps >>>>>>> 1 and 2 here: >>>>>>> http://commons.apache.org/releases/release.html >>>>>>> >>>>>>> Step 2 assumes that the tars and zips have somehow made their way to >>>>>>> /www/www.apache.org/dist/commons/foo/ >>>>>>> >>>>>>> Step 1 provides instructions on how to move things there. I think >>>>>>> Nexus tries to do this moving for you. >>>>>>> >>>>>>> To get the symlinks created properly, you need to invoke symlinks.sh >>>>>>> with the release number as its command line argument from >>>>>>> /www/www.apache.org/dist/commons/foo/ >>>>>>> >>>>>>> For that to work, you have to have the script available and >>>>>>> executable. That should happen if you put it in your bin directory >>>>>>> and do chmod +x on it. Have a look at your .profile file (cat >>>>>>> ~/.profile). If it does not contain a line that looks something like >>>>>>> >>>>>>> >>>>> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:$HOME/bin; >>>>>>> export PATH >>>>>>> then you need to add that line (maybe minus the games and X11R6 >>>>>>> stuff) or just copy a new .profile. Let me know if you are having >>>>>>> problems with this and I will help. >>>>>>> >>>>>>> Sebb is right though that you should close the VOTE before moving >>>>>>> stuff to dist/ >>>>>>> >>>>>> Thank you for the detailed instructions. I am going to go through those >>>>>> next. >>>>>> >>>>>> I must have misunderstood the voting process, which I thought was, if all >>>>>> goes well: >>>>>> - Send a [VOTE] email (this thread) >>>>>> - Wait 72 hours >>>>>> - Send a [VOTE][RESULT] email: >>>>>> >>>>> http://mail-archives.apache.org/mod_mbox/commons-dev/201103.mbox/%3caanlktikgpm0lo-aoi8wfkjxznoxzodtgza2cwjdcq...@mail.gmail.com%3E >>>>>> Is there a [VOTE][CLOSE] email that needs to go out as well after 72 >>>>> hours? >>>>> >>>>> No, but for some reason I did not see the [RESULT] e-mail - sounds >>>>> like Phil did not either. >>>>> >>>>>> I can see that I should have mentioned the vote timeline in the [VOTE] >>>>> email >>>>>> as documented in http://commons.apache.org/releases/prepare.html >>>>>> >>>>>> But, I used the [VOTE] email template from >>>>>> http://wiki.apache.org/commons/UsingNexus which contains no such text. >>>>>> >>>>>> Sigh, the release process is so obtuse with the mixture of Maven, UNIX, >>>>>> Nexus, multiple instruction pages, and so on. It is quite discouraging >>>>>> and >>>>> a >>>>>> barrier to progress :( >>>>> Patches welcome ... >>>>> >>>>>> Gary >>>>>> >>>>>>> Phil >>>>>>> >>>>>>> >>>>>>>>> symlinks.sh >>>>>>>> symlinks.sh: Command not found. >>>>>>>> >>>>>>>>> sh symlinks.sh >>>>>>>> symlinks.sh: 46: Syntax error: word unexpected >>>>>>>> >>>>>>>> I need some UNIX help ;) >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Gary >>>>>>>> >>>>>>>> On Thu, Mar 24, 2011 at 9:39 PM, Gary Gregory <garydgreg...@gmail.com >>>>>>>> wrote: >>>>>>>> >>>>>>>>> [VOTE] Release Apache Commons Codec 1.5-RC1 >>>>>>>>> >>>>>>>>> Tag: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>> https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec-1.5-RC1 >>>>>>>>> Site: >>>>>>>>> >>>>>>>>> http://people.apache.org/builds/commons/codec/1.5/RC1/site/index.html >>>>>>>>> >>>>>>>>> Binaries: >>>>>>>>> >>>>>>>>> >>>>>>> https://repository.apache.org/content/repositories/orgapachecommons-041/ >>>>>>>>> [ ] +1 release it >>>>>>>>> [ ] +0 go ahead I don't care >>>>>>>>> [ ] -1 no, do not release it because >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Gary >>>>>>>>> >>>>>>>>> http://garygregory.wordpress.com/ >>>>>>>>> http://garygregory.com/ >>>>>>>>> http://people.apache.org/~ggregory/ >>>>>>>>> http://twitter.com/GaryGregory >>>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>>> >>>>>> -- >>>>>> Thank you, >>>>>> Gary >>>>>> >>>>>> http://garygregory.wordpress.com/ >>>>>> http://garygregory.com/ >>>>>> http://people.apache.org/~ggregory/ >>>>>> http://twitter.com/GaryGregory >>>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 >> >> > --------------------------------------------------------------------- > 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
