On 5 January 2016 at 20:42, Phil Steitz <phil.ste...@gmail.com> wrote: > On 1/5/16 1:24 PM, sebb wrote: >> On 5 January 2016 at 17:56, Phil Steitz <phil.ste...@gmail.com> wrote: >>> On 1/5/16 10:14 AM, sebb wrote: >>>> An alternative approach might be to leave the POM as is, and create a >>>> separate script to download the source/binary bundles from Nexus to >>>> the dist/dev area, and then delete them from Nexus. >>> Seems roundabout to me. >> Is hacking the POM better? >> >>> As RM, I prefer to just commit artifacts >>> that I have tested locally to svn, run a VOTE on exactly these >>> artifacts and then just svn move them to release. >> I'm not proposing changing where the VOTE files are staged. > > But how exactly do they get there? Who does the commit? What kind > of script? If it is a shell script, I already have those working > fine locally (checked in for the components I have recently RM-ed). > The only annoyance is getting rid of the junk in the Nexus staging > thingy and playing with the GUI there to release to central. >> >>> Automating >>> delete of Nexus cruft would be wonderful if there is a way to do >>> it. >> Nexus allows DELETE (with suitable auth creds) >> >> $ curl --user user:pass --request DELETE URL >> >> The URL is of the form: >> >> https://repository.apache.org/service/local/repositories/orgapachecommons-1120/content/commons-net/commons-net/3.4/ > > Cool! Can you add file specs at the end to specify the .asc.md5 and > other cruft to selectively kill so you can just release what you > want?
Sorry, I only copied the URL prefix from my script. You need to add the filename to the end. > Or do you have to kill the whole repo? No. That would not be useful here ... > Phil >> >>> I know some people don't like having to locally script the move >>> of build artifacts into a local svn checkout of /dist/dev. That >>> could probably be scripted in maven somehow, like it is rigged for >>> the site build. >>> Phil >>>> On 22 December 2015 at 08:39, Pascal Schumacher >>>> <pascalschumac...@gmx.net> wrote: >>>>> Thanks for the explanation and sorry for the noise. >>>>> >>>>> Cheers, >>>>> Pascal >>>>> >>>>> >>>>> Am 22.12.2015 um 09:28 schrieb Luc Maisonobe: >>>>>> Le 22/12/2015 09:14, Pascal Schumacher a écrit : >>>>>>> I agree. >>>>>>> >>>>>>> Maybe I misunderstand the issue, but please continue to attach sources >>>>>>> to maven central releases. It's very helpful when the IDE can >>>>>>> automatically download the source of jar and display it. >>>>>> This is already done. >>>>>> There is a difference between the source distribution in the zip file >>>>>> and the source jar. The former contains everything necessary to rebuild, >>>>>> the second contains only the source for the sake of IDE auto-completion >>>>>> and similar features. >>>>>> >>>>>> What we are talking about here is removing the source and binary zip, >>>>>> not the source and binary jar. >>>>>> >>>>>> best regards, >>>>>> Luc >>>>>> >>>>>>> Thanks, >>>>>>> Pascal >>>>>>> >>>>>>> Am 21.12.2015 um 23:24 schrieb Christopher: >>>>>>>> Why detach them at all? Why not permit them to be uploaded to Maven >>>>>>>> Central? >>>>>>>> It may not be as useful for Java builds, but Maven repository isn't >>>>>>>> designed to hold only jars. It can hold any type of artifact. >>>>>>>> >>>>>>>> On Mon, Dec 21, 2015 at 3:30 AM Emmanuel Bourg <ebo...@apache.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Le 20/12/2015 23:06, Emmanuel Bourg a écrit : >>>>>>>>> >>>>>>>>>> I've tested with JEXL and it seems to work >>>>>>>>>> fine, I haven't noticed undesirable side effects. >>>>>>>>> Actually there is one side effect: the .sha1 and .md5 files for the >>>>>>>>> src/bin archives no longer come for free (they are currently generated >>>>>>>>> when the archives are deployed in the local repository). So if we >>>>>>>>> detach >>>>>>>>> the files we should compensate with an explicit generation of the >>>>>>>>> checksums using the antrun plugin immediately after the assembly >>>>>>>>> plugin. >>>>>>>>> >>>>>>>>> Emmanuel Bourg >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> 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 >>> >> --------------------------------------------------------------------- >> 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
