"Since the 3rd-party material is consumed in source code form, I assume it must have a source-compatible license."
The releases we patch are: - commons-httpclient 3.1 - xerces 2.9.1 - jetty 6.1 We also build the jdk1.5 version of hsqldb, which does not require patching but does require recompilation. I believe all of these are covered by the Apache 2.0 license. Karl On Mon, Apr 2, 2012 at 2:14 PM, sebb <seb...@gmail.com> wrote: > On 2 April 2012 17:53, 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. > > I would add: > > We should not publish patched builds of source in such a way that they > can interfere with the normal use of the unpatched source builds. > This includes (but is not limited to) publishing patched binaries on > Maven Central (regardless of the groupId) with the original package > names. > > Since the 3rd-party material is consumed in source code form, I assume > it must have a source-compatible license. > I.e. a license which is only normally permitted for binary > dependencies would I think be excluded for this use case. > >> 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 >> --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
