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? Or do you have to kill the whole repo? 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
