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