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
