We use ant. Ant simply invokes the patch utility, as described here: http://ant.1045680.n5.nabble.com/Patch-task-td1354764.html
Karl On Mon, Apr 2, 2012 at 12:53 PM, Benson Margulies <bimargul...@gmail.com> wrote: > Karl, > > I hope that you are making this too hard. > > We don't care about the contents of someone else's binaries. If you > make and deploy a -deps package of third-party binaries, as a > convenience for your users, it can contain any strange mixture of > sources and binaries it contains. If you provide a script to download > a third-party package, we don't care what it downloads so long as the > license is acceptable for a dependency. > > I don't follow the logic that prevents you from having a release manager: > > a) retrieve third-part sources > b) apply your patches from your svn > c) create -deps bundle > d) deploy to dist, appropriately marked as 'not an Apache release', > > so long as the third-party material has an acceptable license in the > first place. > > In case I'm wrong here, I'll ask: what is the build tool of choice for > ManifoldCF? On the other hand from all of these, perhaps there is, or > could be, a plugin for that build tool that could implement the > 'patch' utility for you on Windows? > > > > On Mon, Apr 2, 2012 at 12:37 PM, Karl Wright <daddy...@gmail.com> wrote: >> Sorry about the list cc'ing - the gmail client is fighting me today. >> >> To try and clarify, which will take some time I'm afraid: >> >> (1) The 0.5 version of the ManifoldCF release candidate was rejected >> because the tar contained binary dependencies. The binary >> dependencies were checked into svn. This has been standard practice >> for a decade or more for Java projects built with ant, but has now >> been deemed unacceptable. >> (2) In trying to find a solution which would still be convenient but >> not include binaries, we considered supplying ant logic that downloads >> the dependencies on demand. The download would use binaries from the >> Maven repository, where possible. >> (3) In some cases, there is either no corresponding jar in the Maven >> repository, or there is a jar but it doesn't include critical patches. >> (4) In these cases, we needed to see whether there was another place >> those dependent jars could live. They were in svn before, so one >> possibility was that they remain there. Other possibilities include >> putting them into a googlecode repository, or downloading and building >> them as part of the overall build process. >> >> >> >> Hope this helps. >> Karl >> >> >> On Mon, Apr 2, 2012 at 12:26 PM, Daniel Shahaf <d...@daniel.shahaf.name> >> wrote: >>> Forward to list >>> >>> I can't answer your question as it's too abstract. I don't understand >>> what you're trying to do from either infra@ or legal@ perspective. >>> >>> Karl Wright wrote on Mon, Apr 02, 2012 at 12:21:17 -0400: >>>> "'svn patch' exists in 1.7." >>>> >>>> Ok, so that implies that we would create the patched jar by checking >>>> out the project tag from svn and using svn patch, not by downloading >>>> the source tarball. Do you think it is ok to allow svn access as part >>>> of a project's build process? >>>> >>>> Karl >>>> >>>> >>>> On Mon, Apr 2, 2012 at 12:16 PM, Daniel Shahaf <d...@daniel.shahaf.name> >>>> wrote: >>>> > 'svn patch' exists in 1.7. (and tortoise includes svn.exe as an >>>> > optional component, I hear) >>>> > >>>> > Karl Wright wrote on Mon, Apr 02, 2012 at 12:05:47 -0400: >>>> >> The patches are contained in SVN, yes, but the build process is >>>> >> structured to work on Windows as well as Linux, and there isn't a >>>> >> standard patch utility on Windows. >>>> >> >>>> >> We could insist that people only build on Linux, I suppose, but that >>>> >> would be a huge inconvenience for a lot of people. >>>> >> >>>> >> Karl >>>> >> >>>> >> On Mon, Apr 2, 2012 at 11:47 AM, sebb <seb...@gmail.com> wrote: >>>> >> > On 2 April 2012 16:36, Karl Wright <daddy...@gmail.com> wrote: >>>> >> >> ---------- Forwarded message ---------- >>>> >> >> From: Daniel Shahaf <d...@daniel.shahaf.name> >>>> >> >> Date: Mon, Apr 2, 2012 at 11:35 AM >>>> >> >> Subject: Re: Question about downloading binaries >>>> >> >> To: Karl Wright <daddy...@gmail.com> >>>> >> >> >>>> >> >> >>>> >> >> You didn't CC the list >>>> >> >> >>>> >> >> Karl Wright wrote on Mon, Apr 02, 2012 at 11:33:56 -0400: >>>> >> >>> The patches for the dependencies for the main release are sourced >>>> >> >>> only >>>> >> >>> as part of the project in question at this time. So there is no >>>> >> >>> other >>>> >> >>> logical place for them to live. >>>> >> > >>>> >> > The project SVN presumably contains the patches? >>>> >> > If not, it should. >>>> >> > >>>> >> > In which case, can't you download the source and apply the patches as >>>> >> > part of the build process? >>>> >> > >>>> >> > This is what the Tomcat project does (though it's not changing code, >>>> >> > just changing package names to avoid collisions). >>>> >> > >>>> >> >>> Karl >>>> >> >>> >>>> >> >>> On Mon, Apr 2, 2012 at 11:31 AM, Daniel Shahaf >>>> >> >>> <d...@daniel.shahaf.name> wrote: >>>> >> >>> > Why do they have to be hosted on Apache infrastructure? The >>>> >> >>> > Subversion >>>> >> >>> > build depends on a C compiler but we don't host that on ASF >>>> >> >>> > hardware. >>>> >> >>> > >>>> >> >>> > Karl Wright wrote on Mon, Apr 02, 2012 at 11:16:22 -0400: >>>> >> >>> >> Hi folks, >>>> >> >>> >> >>>> >> >>> >> As a result of a change in the way Java releases must be >>>> >> >>> >> structured, >>>> >> >>> >> we need to be able to download binary dependencies as part of the >>>> >> >>> >> build process. The problem is that we have some binary >>>> >> >>> >> dependencies >>>> >> >>> >> that contain patches, or are otherwise unsuitable for being >>>> >> >>> >> pushed to >>>> >> >>> >> the Maven repository. What is the best place in the Apache >>>> >> >>> >> infrastructure for keeping dependencies like this? >>>> >> >>> >> >>>> >> >>> >> Thanks, >>>> >> >>> >> Karl --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
