You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Benson Margulies <bi...@gmail.com> on 2012/04/02 18:53:41 UTC
Re: Question about downloading binaries
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 <da...@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 <se...@gmail.com> wrote:
>>> >> > On 2 April 2012 16:36, Karl Wright <da...@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 <da...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by Karl Wright <da...@gmail.com>.
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 <bi...@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 <da...@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 <se...@gmail.com> wrote:
>>>> >> > On 2 April 2012 16:36, Karl Wright <da...@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 <da...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by Karl Wright <da...@gmail.com>.
I've created CONNECTORS-443 to describe the current proposal.
Karl
On Mon, Apr 2, 2012 at 3:11 PM, Karl Wright <da...@gmail.com> wrote:
> Please see below.
>
> On Mon, Apr 2, 2012 at 3:03 PM, Benson Margulies <bi...@gmail.com> wrote:
>> <Jukka added to 'to'; I need backup here so that I don't push you over a cliff.>
>>
>> On Mon, Apr 2, 2012 at 2:19 PM, Karl Wright <da...@gmail.com> wrote:
>>> "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
>>
>> Uh, oh. Now we have another problem, since these are your fellow
>> Apache people at work.
>>
>> Have you submitted patches back to commons and xerces? What sort of
>> reaction did you get?
>>
>
> I submitted patches for all the materials. In the case of httpclient,
> the patches were partly accepted and partly rejected - but they are
> only available in the 4.x version of the library, which we have not
> yet gone to. The reason is complex; the connectors that would use it
> are difficult to test in the absence of available instances of the
> kinds of repositories they would be communicating with. That's a long
> standing problem I've been trying to find a solution for for more than
> 2 years now.
>
> The patches that were rejected involved things that the package
> developers considered to be "not consistent with mission". For
> example, the xerces change basically allows the parser to accept
> broken xml (if a certain configuration switch is enabled).
>
>> Releasing 'convenience binaries' of modified sources of Apache
>> projects strikes me as somewhat contrary to the overall goals here.
>> I'd like others to weigh in here, but I'd propose that you always
>> ship modified Apache products as source. Forget about 'patch'. Just
>> ship modified sources files and drop them into place in fetched copies
>> of their releases, and build the results.
>>
>
> I'd love to acheive closure, believe me, and there are open tickets to
> this end, but until we do it I don't believe it is wise or feasible to
> withhold ManifoldCF from the community.
>
>> As Sebb points out, you really, really, must not push your modified
>> binaries to maven central unless you use shade or equivalent to change
>> the package names.
>>
>
> I would never do that, obviously.
>
>> I wish that others would weigh in here; how bad an idea is a
>> 'convenience binary' consisting of a modified Apache project library?
>>
>>> - jetty 6.1
>>
>> As a courtesy to the Jetty project, the same rule of 'don't stick this
>> out into maven as a standalone artifact' applies. Otherwise, the
>> two-pronged approach is fine: make convenience binaries, and also
>> provide the user with the ability to rebuild them for themselves. I'd
>> propose the 'whole file replacement' mechanism here as well to solve
>> the Windows problem.
>>
>
> Actually it occurred to me that since there are published binary
> releases of these artifacts, I can download and unpack those. So I
> think I have a solution for this one.
>
> Karl
>
>>>
>>> We also build the jdk1.5 version of hsqldb, which does not require
>>> patching but does require recompilation.
>>
>> That's simple enough as a -dep convenience binary.
>>
>>>
>>> I believe all of these are covered by the Apache 2.0 license.
>>>
>>> Karl
>>>
>>> On Mon, Apr 2, 2012 at 2:14 PM, sebb <se...@gmail.com> wrote:
>>>> On 2 April 2012 17:53, Benson Margulies <bi...@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 <da...@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 <se...@gmail.com> wrote:
>>>>>>>> >> > On 2 April 2012 16:36, Karl Wright <da...@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 <da...@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-unsubscribe@incubator.apache.org
>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by Karl Wright <da...@gmail.com>.
For all those with interest in the "brave newer world" of Apache
releases --- there is a build artifact (RC4 in fact) now also
available for inspection. I'd love to get feedback on the
multi-artifact licenses, readme's, and release organization before we
go through the process of putting it up for a formal vote in the
incubator list. If you see any further legal/policy problems, please
tell me now. ;-)
You can download the artifacts from http://people.apache.org/~shinichiro.
Thanks,
Karl
On Tue, Apr 3, 2012 at 3:40 PM, Karl Wright <da...@gmail.com> wrote:
> Ok, you can now browse each different build artifact's license,
> notice, and readme file at:
>
> https://svn.apache.org/repos/asf/incubator/lcf/trunk/[README.txt,NOTICE.txt,LICENSE.txt]
> - source
> https://svn.apache.org/repos/asf/incubator/lcf/trunk/lib-license/[README.txt,NOTICE.txt,LICENSE.txt]
> - lib artifact
> https://svn.apache.org/repos/asf/incubator/lcf/trunk/dist-license/[README.txt,NOTICE.txt,LICENSE.txt]
> - binary artifact
>
> Please let me know what you think now.
>
> Karl
>
>
> On Tue, Apr 3, 2012 at 2:05 PM, Franklin, Matthew B.
> <mf...@mitre.org> wrote:
>>>-----Original Message-----
>>>From: Karl Wright [mailto:daddywri@gmail.com]
>>>Sent: Tuesday, April 03, 2012 1:24 PM
>>>To: general@incubator.apache.org
>>>Subject: Re: Question about downloading binaries
>>>
>>>"Also, making sure the other comments on NOTICEs are addressed as well."
>>>
>>>I have gotten extremely confusing advice in this area in the past, and
>>>the available documentation does not help. I believe I am adhering to
>>>Roy's principles, but before we spin another release candidate, I'd
>>>like it very much if someone with a (hopefully accurate) idea of how
>>>things are supposed to work reviewed our license and notice files.
>>>You can find them here:
>>>
>>>https://svn.apache.org/repos/asf/incubator/lcf/trunk/LICENSE.txt
>>>https://svn.apache.org/repos/asf/incubator/lcf/trunk/NOTICE.txt
>>
>> Just looking quickly, the LICENSE file contains a lot of licenses for the jars you were distributing. For the source release, the ONLY L&N attributions needed are the ones for code that you are including in your source.
>>
>> If, like many projects, you have no 3rd party source inclusion, the LICENSE file should only contain ASL 2.0 and the NOTICE should have the standard developed at apache note.
>>
>> For the binary releases, we have been adding entries for any jars we include, as you have done. There are a couple of tweaks I would suggest, I propose that you get an agreeable source L&N first as I think there is (yet again) a wider discussion to be had regarding convenience binaries...
>>
>>>
>>>Thanks!
>>>Karl
>>>
>>>On Tue, Apr 3, 2012 at 1:11 PM, Matt Hogstrom <ma...@hogstrom.org> wrote:
>>>>> Hope that helps... The question is, will Roy (or anyone else) be
>>>>> unwilling to vote for the first option?
>>>>
>>>> Having been one of the people that commented and started the thread, I
>>>feel like I was wearing loose clothing while operating machinery, per Roy's
>>>guidance on the source being the thing that is voted on and the other binaries
>>>are merely convenience items, I would support the first option. Also, making
>>>sure the other comments on NOTICEs are addressed as well.
>>>>
>>>> Unfortunate that you god dog piled on but hopefully we're all better
>>>prepared going forward.
>>>>
>>>> Matt Hogstrom
>>>> matt@hogstrom.org
>>>>
>>>> A Day Without Nuclear Fusion Is a Day Without Sunshine
>>>>
>>>> On Apr 3, 2012, at 11:04 AM, Karl Wright wrote:
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by Karl Wright <da...@gmail.com>.
Ok, you can now browse each different build artifact's license,
notice, and readme file at:
https://svn.apache.org/repos/asf/incubator/lcf/trunk/[README.txt,NOTICE.txt,LICENSE.txt]
- source
https://svn.apache.org/repos/asf/incubator/lcf/trunk/lib-license/[README.txt,NOTICE.txt,LICENSE.txt]
- lib artifact
https://svn.apache.org/repos/asf/incubator/lcf/trunk/dist-license/[README.txt,NOTICE.txt,LICENSE.txt]
- binary artifact
Please let me know what you think now.
Karl
On Tue, Apr 3, 2012 at 2:05 PM, Franklin, Matthew B.
<mf...@mitre.org> wrote:
>>-----Original Message-----
>>From: Karl Wright [mailto:daddywri@gmail.com]
>>Sent: Tuesday, April 03, 2012 1:24 PM
>>To: general@incubator.apache.org
>>Subject: Re: Question about downloading binaries
>>
>>"Also, making sure the other comments on NOTICEs are addressed as well."
>>
>>I have gotten extremely confusing advice in this area in the past, and
>>the available documentation does not help. I believe I am adhering to
>>Roy's principles, but before we spin another release candidate, I'd
>>like it very much if someone with a (hopefully accurate) idea of how
>>things are supposed to work reviewed our license and notice files.
>>You can find them here:
>>
>>https://svn.apache.org/repos/asf/incubator/lcf/trunk/LICENSE.txt
>>https://svn.apache.org/repos/asf/incubator/lcf/trunk/NOTICE.txt
>
> Just looking quickly, the LICENSE file contains a lot of licenses for the jars you were distributing. For the source release, the ONLY L&N attributions needed are the ones for code that you are including in your source.
>
> If, like many projects, you have no 3rd party source inclusion, the LICENSE file should only contain ASL 2.0 and the NOTICE should have the standard developed at apache note.
>
> For the binary releases, we have been adding entries for any jars we include, as you have done. There are a couple of tweaks I would suggest, I propose that you get an agreeable source L&N first as I think there is (yet again) a wider discussion to be had regarding convenience binaries...
>
>>
>>Thanks!
>>Karl
>>
>>On Tue, Apr 3, 2012 at 1:11 PM, Matt Hogstrom <ma...@hogstrom.org> wrote:
>>>> Hope that helps... The question is, will Roy (or anyone else) be
>>>> unwilling to vote for the first option?
>>>
>>> Having been one of the people that commented and started the thread, I
>>feel like I was wearing loose clothing while operating machinery, per Roy's
>>guidance on the source being the thing that is voted on and the other binaries
>>are merely convenience items, I would support the first option. Also, making
>>sure the other comments on NOTICEs are addressed as well.
>>>
>>> Unfortunate that you god dog piled on but hopefully we're all better
>>prepared going forward.
>>>
>>> Matt Hogstrom
>>> matt@hogstrom.org
>>>
>>> A Day Without Nuclear Fusion Is a Day Without Sunshine
>>>
>>> On Apr 3, 2012, at 11:04 AM, Karl Wright wrote:
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>For additional commands, e-mail: general-help@incubator.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by Karl Wright <da...@gmail.com>.
Are there still requirements for the source tree in SVN, as far as
having applicable LICENSE and NOTICE files there? My understanding is
then that the source LICENSE and NOTICE files must reside at the root
level in the SVN tree - which implies that the binary tar/zip build
CANNOT be built from the same root. Is that correct?
Karl
On Tue, Apr 3, 2012 at 2:05 PM, Franklin, Matthew B.
<mf...@mitre.org> wrote:
>>-----Original Message-----
>>From: Karl Wright [mailto:daddywri@gmail.com]
>>Sent: Tuesday, April 03, 2012 1:24 PM
>>To: general@incubator.apache.org
>>Subject: Re: Question about downloading binaries
>>
>>"Also, making sure the other comments on NOTICEs are addressed as well."
>>
>>I have gotten extremely confusing advice in this area in the past, and
>>the available documentation does not help. I believe I am adhering to
>>Roy's principles, but before we spin another release candidate, I'd
>>like it very much if someone with a (hopefully accurate) idea of how
>>things are supposed to work reviewed our license and notice files.
>>You can find them here:
>>
>>https://svn.apache.org/repos/asf/incubator/lcf/trunk/LICENSE.txt
>>https://svn.apache.org/repos/asf/incubator/lcf/trunk/NOTICE.txt
>
> Just looking quickly, the LICENSE file contains a lot of licenses for the jars you were distributing. For the source release, the ONLY L&N attributions needed are the ones for code that you are including in your source.
>
> If, like many projects, you have no 3rd party source inclusion, the LICENSE file should only contain ASL 2.0 and the NOTICE should have the standard developed at apache note.
>
> For the binary releases, we have been adding entries for any jars we include, as you have done. There are a couple of tweaks I would suggest, I propose that you get an agreeable source L&N first as I think there is (yet again) a wider discussion to be had regarding convenience binaries...
>
>>
>>Thanks!
>>Karl
>>
>>On Tue, Apr 3, 2012 at 1:11 PM, Matt Hogstrom <ma...@hogstrom.org> wrote:
>>>> Hope that helps... The question is, will Roy (or anyone else) be
>>>> unwilling to vote for the first option?
>>>
>>> Having been one of the people that commented and started the thread, I
>>feel like I was wearing loose clothing while operating machinery, per Roy's
>>guidance on the source being the thing that is voted on and the other binaries
>>are merely convenience items, I would support the first option. Also, making
>>sure the other comments on NOTICEs are addressed as well.
>>>
>>> Unfortunate that you god dog piled on but hopefully we're all better
>>prepared going forward.
>>>
>>> Matt Hogstrom
>>> matt@hogstrom.org
>>>
>>> A Day Without Nuclear Fusion Is a Day Without Sunshine
>>>
>>> On Apr 3, 2012, at 11:04 AM, Karl Wright wrote:
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>For additional commands, e-mail: general-help@incubator.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Question about downloading binaries
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: Karl Wright [mailto:daddywri@gmail.com]
>Sent: Tuesday, April 03, 2012 1:24 PM
>To: general@incubator.apache.org
>Subject: Re: Question about downloading binaries
>
>"Also, making sure the other comments on NOTICEs are addressed as well."
>
>I have gotten extremely confusing advice in this area in the past, and
>the available documentation does not help. I believe I am adhering to
>Roy's principles, but before we spin another release candidate, I'd
>like it very much if someone with a (hopefully accurate) idea of how
>things are supposed to work reviewed our license and notice files.
>You can find them here:
>
>https://svn.apache.org/repos/asf/incubator/lcf/trunk/LICENSE.txt
>https://svn.apache.org/repos/asf/incubator/lcf/trunk/NOTICE.txt
Just looking quickly, the LICENSE file contains a lot of licenses for the jars you were distributing. For the source release, the ONLY L&N attributions needed are the ones for code that you are including in your source.
If, like many projects, you have no 3rd party source inclusion, the LICENSE file should only contain ASL 2.0 and the NOTICE should have the standard developed at apache note.
For the binary releases, we have been adding entries for any jars we include, as you have done. There are a couple of tweaks I would suggest, I propose that you get an agreeable source L&N first as I think there is (yet again) a wider discussion to be had regarding convenience binaries...
>
>Thanks!
>Karl
>
>On Tue, Apr 3, 2012 at 1:11 PM, Matt Hogstrom <ma...@hogstrom.org> wrote:
>>> Hope that helps... The question is, will Roy (or anyone else) be
>>> unwilling to vote for the first option?
>>
>> Having been one of the people that commented and started the thread, I
>feel like I was wearing loose clothing while operating machinery, per Roy's
>guidance on the source being the thing that is voted on and the other binaries
>are merely convenience items, I would support the first option. Also, making
>sure the other comments on NOTICEs are addressed as well.
>>
>> Unfortunate that you god dog piled on but hopefully we're all better
>prepared going forward.
>>
>> Matt Hogstrom
>> matt@hogstrom.org
>>
>> A Day Without Nuclear Fusion Is a Day Without Sunshine
>>
>> On Apr 3, 2012, at 11:04 AM, Karl Wright wrote:
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by Karl Wright <da...@gmail.com>.
"Also, making sure the other comments on NOTICEs are addressed as well."
I have gotten extremely confusing advice in this area in the past, and
the available documentation does not help. I believe I am adhering to
Roy's principles, but before we spin another release candidate, I'd
like it very much if someone with a (hopefully accurate) idea of how
things are supposed to work reviewed our license and notice files.
You can find them here:
https://svn.apache.org/repos/asf/incubator/lcf/trunk/LICENSE.txt
https://svn.apache.org/repos/asf/incubator/lcf/trunk/NOTICE.txt
Thanks!
Karl
On Tue, Apr 3, 2012 at 1:11 PM, Matt Hogstrom <ma...@hogstrom.org> wrote:
>> Hope that helps... The question is, will Roy (or anyone else) be
>> unwilling to vote for the first option?
>
> Having been one of the people that commented and started the thread, I feel like I was wearing loose clothing while operating machinery, per Roy's guidance on the source being the thing that is voted on and the other binaries are merely convenience items, I would support the first option. Also, making sure the other comments on NOTICEs are addressed as well.
>
> Unfortunate that you god dog piled on but hopefully we're all better prepared going forward.
>
> Matt Hogstrom
> matt@hogstrom.org
>
> A Day Without Nuclear Fusion Is a Day Without Sunshine
>
> On Apr 3, 2012, at 11:04 AM, Karl Wright wrote:
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by Matt Hogstrom <ma...@hogstrom.org>.
> Hope that helps... The question is, will Roy (or anyone else) be
> unwilling to vote for the first option?
Having been one of the people that commented and started the thread, I feel like I was wearing loose clothing while operating machinery, per Roy's guidance on the source being the thing that is voted on and the other binaries are merely convenience items, I would support the first option. Also, making sure the other comments on NOTICEs are addressed as well.
Unfortunate that you god dog piled on but hopefully we're all better prepared going forward.
Matt Hogstrom
matt@hogstrom.org
A Day Without Nuclear Fusion Is a Day Without Sunshine
On Apr 3, 2012, at 11:04 AM, Karl Wright wrote:
Re: Question about downloading binaries
Posted by Leo Simons <ma...@leosimons.com>.
On Tue, Apr 3, 2012 at 5:04 PM, Karl Wright <da...@gmail.com> wrote:
> It sounds like I wasn't clear enough.
>
> The proposal is for the following release artifacts:
>
> (1) A source-only tar
> (2) A source+binary dependencies convenience tar
> (3) A binary tar
>
> This is instead of:
>
> (1) A source-only tar
> (2) A binary dependencies convenience tar
> (3) A binary tar
>
> Hope that helps... The question is, will Roy (or anyone else) be
> unwilling to vote for the first option?
Can't speak for Roy of course, but *my* interpretation is that what
matters is having (1).
A readily buildable source release that contains all the source code
that comprises the project, that is the official release of the
project by the ASF, that is the open source apache-licensed thing that
is carefully inspected and tested by the (P)PMC, that is the thing
that is voted on, that you point to from your website as the source
release, and such and so forth.
Once you have (1), there's many different acceptable approaches for
(2),(3),(4), and so on. I personally feel ManifoldCF (like any other
project), perhaps with help from their mentors, can decide for
themselves what is the best approach. For example, I don't
particularly understand the purpose/value of either version of (2)
(wouldn't I just always want the binary version?), but that's fine :)
cheerio,
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by Karl Wright <da...@gmail.com>.
It sounds like I wasn't clear enough.
The proposal is for the following release artifacts:
(1) A source-only tar
(2) A source+binary dependencies convenience tar
(3) A binary tar
This is instead of:
(1) A source-only tar
(2) A binary dependencies convenience tar
(3) A binary tar
Hope that helps... The question is, will Roy (or anyone else) be
unwilling to vote for the first option?
Karl
On Tue, Apr 3, 2012 at 11:00 AM, ant elder <an...@gmail.com> wrote:
> On Tue, Apr 3, 2012 at 3:43 PM, Karl Wright <da...@gmail.com> wrote:
>> On Tue, Apr 3, 2012 at 10:33 AM, ant elder <an...@gmail.com> wrote:
>>> On Tue, Apr 3, 2012 at 3:18 PM, Jukka Zitting <ju...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> On Tue, Apr 3, 2012 at 3:52 PM, Karl Wright <da...@gmail.com> wrote:
>>>>> Our mentor(s) are pushing strongly for a source release (which
>>>>> contains the upstream patches), plus a "lib" release, which is to be
>>>>> overlaid on the source release to allow it to build.
>>>>
>>>> I wouldn't call it "strongly", rather as just one possible solution
>>>> that can be implemented in the short term without significant impact
>>>> on the existing codebase. The other alternatives being suggested
>>>> seemed quite a bit more complicated.
>>>>
>>>>> I much preferred a source release and a convenience source+lib release,
>>>>> but that caused significant objections, so I gave up.
>>>>
>>>> My main objection here is that the official source release should be
>>>> readily buildable. If the build instructions are essentially "take
>>>> that other package and build it instead", then IMHO in practice that
>>>> other package is the one that's being released.
>>>>
>>>
>>> It could still be readily buildable because it can just document how
>>> to overlay the lib folder from the source+lib release onto the src
>>> only release. In practice probably everyone would just use the
>>> source+lib release anyway but so what.
>>>
>>>> Personally I'd be fine with the source package containing required
>>>> binary dependencies, but since others will likely -1 release
>>>> candidates like that, I don't see how a convenience package like that
>>>> would pass review.
>>>>
>>>
>>> IMHO given that ManifoldCF is a little unusual that makes sense to me too.
>>>
>>> ...ant
>>>
>>
>> I like the "additional instructions" idea.
>>
>> I would love to get a show of hands for a source+lib convenience
>> release rather than just a pure lib release. Anyone want to provide a
>> +1 for this approach, or more importantly, a -1 if you have
>> significant objections?
>>
>
> Well the documented rules are that releases can't be veto'ed so you
> just need three, but from my reading of all this the main problems are
> the comments from Roy which i expect given the climate in the
> Incubator these days might make three hard to get:
>
> "Organizations or individuals that would be offended by (or prevented
> from receiving) the binaries are fully capable of building their own
> IF and ONLY IF the binaries do not exist in our source packages."
>
> and
>
> "Our releases are absolutely forbidden to contain anything other than
> the open source code that is in our vcs-of-record"
>
> ...ant
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by ant elder <an...@gmail.com>.
On Tue, Apr 3, 2012 at 3:43 PM, Karl Wright <da...@gmail.com> wrote:
> On Tue, Apr 3, 2012 at 10:33 AM, ant elder <an...@gmail.com> wrote:
>> On Tue, Apr 3, 2012 at 3:18 PM, Jukka Zitting <ju...@gmail.com> wrote:
>>> Hi,
>>>
>>> On Tue, Apr 3, 2012 at 3:52 PM, Karl Wright <da...@gmail.com> wrote:
>>>> Our mentor(s) are pushing strongly for a source release (which
>>>> contains the upstream patches), plus a "lib" release, which is to be
>>>> overlaid on the source release to allow it to build.
>>>
>>> I wouldn't call it "strongly", rather as just one possible solution
>>> that can be implemented in the short term without significant impact
>>> on the existing codebase. The other alternatives being suggested
>>> seemed quite a bit more complicated.
>>>
>>>> I much preferred a source release and a convenience source+lib release,
>>>> but that caused significant objections, so I gave up.
>>>
>>> My main objection here is that the official source release should be
>>> readily buildable. If the build instructions are essentially "take
>>> that other package and build it instead", then IMHO in practice that
>>> other package is the one that's being released.
>>>
>>
>> It could still be readily buildable because it can just document how
>> to overlay the lib folder from the source+lib release onto the src
>> only release. In practice probably everyone would just use the
>> source+lib release anyway but so what.
>>
>>> Personally I'd be fine with the source package containing required
>>> binary dependencies, but since others will likely -1 release
>>> candidates like that, I don't see how a convenience package like that
>>> would pass review.
>>>
>>
>> IMHO given that ManifoldCF is a little unusual that makes sense to me too.
>>
>> ...ant
>>
>
> I like the "additional instructions" idea.
>
> I would love to get a show of hands for a source+lib convenience
> release rather than just a pure lib release. Anyone want to provide a
> +1 for this approach, or more importantly, a -1 if you have
> significant objections?
>
Well the documented rules are that releases can't be veto'ed so you
just need three, but from my reading of all this the main problems are
the comments from Roy which i expect given the climate in the
Incubator these days might make three hard to get:
"Organizations or individuals that would be offended by (or prevented
from receiving) the binaries are fully capable of building their own
IF and ONLY IF the binaries do not exist in our source packages."
and
"Our releases are absolutely forbidden to contain anything other than
the open source code that is in our vcs-of-record"
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by Karl Wright <da...@gmail.com>.
On Tue, Apr 3, 2012 at 10:33 AM, ant elder <an...@gmail.com> wrote:
> On Tue, Apr 3, 2012 at 3:18 PM, Jukka Zitting <ju...@gmail.com> wrote:
>> Hi,
>>
>> On Tue, Apr 3, 2012 at 3:52 PM, Karl Wright <da...@gmail.com> wrote:
>>> Our mentor(s) are pushing strongly for a source release (which
>>> contains the upstream patches), plus a "lib" release, which is to be
>>> overlaid on the source release to allow it to build.
>>
>> I wouldn't call it "strongly", rather as just one possible solution
>> that can be implemented in the short term without significant impact
>> on the existing codebase. The other alternatives being suggested
>> seemed quite a bit more complicated.
>>
>>> I much preferred a source release and a convenience source+lib release,
>>> but that caused significant objections, so I gave up.
>>
>> My main objection here is that the official source release should be
>> readily buildable. If the build instructions are essentially "take
>> that other package and build it instead", then IMHO in practice that
>> other package is the one that's being released.
>>
>
> It could still be readily buildable because it can just document how
> to overlay the lib folder from the source+lib release onto the src
> only release. In practice probably everyone would just use the
> source+lib release anyway but so what.
>
>> Personally I'd be fine with the source package containing required
>> binary dependencies, but since others will likely -1 release
>> candidates like that, I don't see how a convenience package like that
>> would pass review.
>>
>
> IMHO given that ManifoldCF is a little unusual that makes sense to me too.
>
> ...ant
>
I like the "additional instructions" idea.
I would love to get a show of hands for a source+lib convenience
release rather than just a pure lib release. Anyone want to provide a
+1 for this approach, or more importantly, a -1 if you have
significant objections?
Karl
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by ant elder <an...@gmail.com>.
On Tue, Apr 3, 2012 at 3:18 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Tue, Apr 3, 2012 at 3:52 PM, Karl Wright <da...@gmail.com> wrote:
>> Our mentor(s) are pushing strongly for a source release (which
>> contains the upstream patches), plus a "lib" release, which is to be
>> overlaid on the source release to allow it to build.
>
> I wouldn't call it "strongly", rather as just one possible solution
> that can be implemented in the short term without significant impact
> on the existing codebase. The other alternatives being suggested
> seemed quite a bit more complicated.
>
>> I much preferred a source release and a convenience source+lib release,
>> but that caused significant objections, so I gave up.
>
> My main objection here is that the official source release should be
> readily buildable. If the build instructions are essentially "take
> that other package and build it instead", then IMHO in practice that
> other package is the one that's being released.
>
It could still be readily buildable because it can just document how
to overlay the lib folder from the source+lib release onto the src
only release. In practice probably everyone would just use the
source+lib release anyway but so what.
> Personally I'd be fine with the source package containing required
> binary dependencies, but since others will likely -1 release
> candidates like that, I don't see how a convenience package like that
> would pass review.
>
IMHO given that ManifoldCF is a little unusual that makes sense to me too.
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, Apr 3, 2012 at 3:52 PM, Karl Wright <da...@gmail.com> wrote:
> Our mentor(s) are pushing strongly for a source release (which
> contains the upstream patches), plus a "lib" release, which is to be
> overlaid on the source release to allow it to build.
I wouldn't call it "strongly", rather as just one possible solution
that can be implemented in the short term without significant impact
on the existing codebase. The other alternatives being suggested
seemed quite a bit more complicated.
> I much preferred a source release and a convenience source+lib release,
> but that caused significant objections, so I gave up.
My main objection here is that the official source release should be
readily buildable. If the build instructions are essentially "take
that other package and build it instead", then IMHO in practice that
other package is the one that's being released.
Personally I'd be fine with the source package containing required
binary dependencies, but since others will likely -1 release
candidates like that, I don't see how a convenience package like that
would pass review.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by Karl Wright <da...@gmail.com>.
"Looking into ManifoldCF a bit, I think what you need is
* buildable source release that contains all the source for ManifoldCF
* source release that contains all the custom patches for the
dependencies that need patches"
Our mentor(s) are pushing strongly for a source release (which
contains the upstream patches), plus a "lib" release, which is to be
overlaid on the source release to allow it to build. I much preferred
a source release and a convenience source+lib release, but that caused
significant objections, so I gave up.
But if others find my original proposal more to their liking, I'd be
happy to reopen the issue.
Karl
On Tue, Apr 3, 2012 at 9:03 AM, Leo Simons <ma...@leosimons.com> wrote:
> (dropped infra@)
>
> On Mon, Apr 2, 2012 at 10:54 PM, Benson Margulies <bi...@gmail.com> wrote:
>> I'm exceedingly sorry here that the IPMC as a whole let you down by
>> not turning into these issues and dealing with them at the outset.
>
> Me too.
>
>> Personally, I have no objection to including mutant jars in a -deps
>> binary with a clear explanation of what they are, but I would like to
>> see some support for that view, because I'd could imagine some
>> objections based on recent email.
>
> Me neither.
>
> But let me expand on that :-)
>
> Note the recent ("explosive"?) discussions were about source releases.
> If you get those right, what ancillary stuff (binaries, -deps
> packages, maven-repo-structured jar directories, ...) you can then
> _also_ have is not so much under discussion I think.
>
> Looking into ManifoldCF a bit, I think what you need is
>
> * buildable source release that contains all the source for ManifoldCF
> * source release that contains all the custom patches for the
> dependencies that need patches
> ** you could include the source code, but I'd actually prefer not to do that
> * source release that contains instructions for patching and then
> installing needed dependencies
> ** ideally this is all scripted of course (`build.xml
> install-and-patch-xerces` downloads xerces source release, extracts
> and applies patch, builds jar, copies jar into place, ...), but I
> don't see that as a requirement
>
> And if you have all that, then yeah, having various binary
> conveniences as well is not much of a discussion.
>
>
> cheers,
>
>
> Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by Leo Simons <ma...@leosimons.com>.
(dropped infra@)
On Mon, Apr 2, 2012 at 10:54 PM, Benson Margulies <bi...@gmail.com> wrote:
> I'm exceedingly sorry here that the IPMC as a whole let you down by
> not turning into these issues and dealing with them at the outset.
Me too.
> Personally, I have no objection to including mutant jars in a -deps
> binary with a clear explanation of what they are, but I would like to
> see some support for that view, because I'd could imagine some
> objections based on recent email.
Me neither.
But let me expand on that :-)
Note the recent ("explosive"?) discussions were about source releases.
If you get those right, what ancillary stuff (binaries, -deps
packages, maven-repo-structured jar directories, ...) you can then
_also_ have is not so much under discussion I think.
Looking into ManifoldCF a bit, I think what you need is
* buildable source release that contains all the source for ManifoldCF
* source release that contains all the custom patches for the
dependencies that need patches
** you could include the source code, but I'd actually prefer not to do that
* source release that contains instructions for patching and then
installing needed dependencies
** ideally this is all scripted of course (`build.xml
install-and-patch-xerces` downloads xerces source release, extracts
and applies patch, builds jar, copies jar into place, ...), but I
don't see that as a requirement
And if you have all that, then yeah, having various binary
conveniences as well is not much of a discussion.
cheers,
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by sebb <se...@gmail.com>.
On 3 April 2012 00:48, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> [dropped infrastructure@]
>
> On Tue, Apr 3, 2012 at 1:43 AM, sebb <se...@gmail.com> wrote:
>> Can you be certain that the non-standard jars will not interfere with
>> the standard jars?
>
> ManifoldCF is a standalone application, not a library you'd use as a
> dependency of another application. Thus whatever code goes into
> ManifoldCF has a near-zero chance of affecting the classpath of any
> other Java application.
In that case, it's only necessary to ensure that the jar is not
published where it can be picked up and used independently.
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
[dropped infrastructure@]
On Tue, Apr 3, 2012 at 1:43 AM, sebb <se...@gmail.com> wrote:
> Can you be certain that the non-standard jars will not interfere with
> the standard jars?
ManifoldCF is a standalone application, not a library you'd use as a
dependency of another application. Thus whatever code goes into
ManifoldCF has a near-zero chance of affecting the classpath of any
other Java application.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by sebb <se...@gmail.com>.
On 3 April 2012 00:38, Karl Wright <da...@gmail.com> wrote:
> "Whether it is necessary is another matter, and is not easy to answer
> in general as "it depends"."
>
> I'm going to treat this as "unnecessary", because we were extremely
> careful to maintain backwards compatibility when writing the changes.
The API may be backwards compatible, but the behaviour presumably
isn't, otherwise there would be no need to apply the patch.
[The physical API of an AA battery is identical for Zinc-carbon, NiCd
and NiMh, and they are often interchangeable, but their behaviour is
not identical.]
Can you be certain that the non-standard jars will not interfere with
the standard jars?
>
> Karl
>
> On Mon, Apr 2, 2012 at 6:59 PM, sebb <se...@gmail.com> wrote:
>> On 2 April 2012 22:45, Karl Wright <da...@gmail.com> wrote:
>>> I think the bigger picture here is that resolving differences of this
>>> kind requires time, and during the interim we need to be able to
>>> release software anyway. I have no wish to maintain a forked copy of
>>> either xerces or httpclient indefinitely, but right at the moment we
>>> are not prepared or able to use the released versions of these
>>> libraries. I hope that we can all agree that pragmatism has a value;
>>> we're certainly not trying to step on people's toes, we're simply
>>> trying to solve a problem.
>>
>> One sure way to solve the problem is to use your own package namespace
>> for any such imported source.
>>
>> That is definitely sufficient.
>>
>> Whether it is necessary is another matter, and is not easy to answer
>> in general as "it depends".
>>
>>> Thanks,
>>> Karl
>>>
>>>
>>> On Mon, Apr 2, 2012 at 5:28 PM, Karl Wright <da...@gmail.com> wrote:
>>>> "what's the use-case for non-well-formed
>>>> XML?' This thread is probably not the best place to delve further in
>>>> that direction."
>>>>
>>>> Simple use case: parsing malformed RSS feeds. I agree, though, we're
>>>> getting into the weeds here; I'd love to have this discussion
>>>> elsewhere, but the point does stand that none of these patch decisions
>>>> was done lightly. Hopefully the community can accept that.
>>>>
>>>> Karl
>>>>
>>>> On Mon, Apr 2, 2012 at 4:54 PM, Benson Margulies <bi...@gmail.com> wrote:
>>>>> Karl,
>>>>>
>>>>> I'm exceedingly sorry here that the IPMC as a whole let you down by
>>>>> not turning into these issues and dealing with them at the outset.
>>>>> There's been a lot of sensitivity expressed lately to Apache projects
>>>>> stepping on each other's toes.
>>>>>
>>>>> Personally, I have no objection to including mutant jars in a -deps
>>>>> binary with a clear explanation of what they are, but I would like to
>>>>> see some support for that view, because I'd could imagine some
>>>>> objections based on recent email.
>>>>>
>>>>> In the longer term, if ManifoldCF really wants to include an "XML
>>>>> parser with a difference", then it's certainly possible for you to
>>>>> maintain and release a fork of Xerces under your own package names. I
>>>>> agree with Sebb that you would be well advised to find some other way
>>>>> around it. My personal reaction, in complete isolation from the
>>>>> problem at hand, was 'really? what's the use-case for non-well-formed
>>>>> XML?' This thread is probably not the best place to delve further in
>>>>> that direction.
>>>>>
>>>>> --benson
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by Karl Wright <da...@gmail.com>.
"Whether it is necessary is another matter, and is not easy to answer
in general as "it depends"."
I'm going to treat this as "unnecessary", because we were extremely
careful to maintain backwards compatibility when writing the changes.
Karl
On Mon, Apr 2, 2012 at 6:59 PM, sebb <se...@gmail.com> wrote:
> On 2 April 2012 22:45, Karl Wright <da...@gmail.com> wrote:
>> I think the bigger picture here is that resolving differences of this
>> kind requires time, and during the interim we need to be able to
>> release software anyway. I have no wish to maintain a forked copy of
>> either xerces or httpclient indefinitely, but right at the moment we
>> are not prepared or able to use the released versions of these
>> libraries. I hope that we can all agree that pragmatism has a value;
>> we're certainly not trying to step on people's toes, we're simply
>> trying to solve a problem.
>
> One sure way to solve the problem is to use your own package namespace
> for any such imported source.
>
> That is definitely sufficient.
>
> Whether it is necessary is another matter, and is not easy to answer
> in general as "it depends".
>
>> Thanks,
>> Karl
>>
>>
>> On Mon, Apr 2, 2012 at 5:28 PM, Karl Wright <da...@gmail.com> wrote:
>>> "what's the use-case for non-well-formed
>>> XML?' This thread is probably not the best place to delve further in
>>> that direction."
>>>
>>> Simple use case: parsing malformed RSS feeds. I agree, though, we're
>>> getting into the weeds here; I'd love to have this discussion
>>> elsewhere, but the point does stand that none of these patch decisions
>>> was done lightly. Hopefully the community can accept that.
>>>
>>> Karl
>>>
>>> On Mon, Apr 2, 2012 at 4:54 PM, Benson Margulies <bi...@gmail.com> wrote:
>>>> Karl,
>>>>
>>>> I'm exceedingly sorry here that the IPMC as a whole let you down by
>>>> not turning into these issues and dealing with them at the outset.
>>>> There's been a lot of sensitivity expressed lately to Apache projects
>>>> stepping on each other's toes.
>>>>
>>>> Personally, I have no objection to including mutant jars in a -deps
>>>> binary with a clear explanation of what they are, but I would like to
>>>> see some support for that view, because I'd could imagine some
>>>> objections based on recent email.
>>>>
>>>> In the longer term, if ManifoldCF really wants to include an "XML
>>>> parser with a difference", then it's certainly possible for you to
>>>> maintain and release a fork of Xerces under your own package names. I
>>>> agree with Sebb that you would be well advised to find some other way
>>>> around it. My personal reaction, in complete isolation from the
>>>> problem at hand, was 'really? what's the use-case for non-well-formed
>>>> XML?' This thread is probably not the best place to delve further in
>>>> that direction.
>>>>
>>>> --benson
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by sebb <se...@gmail.com>.
On 2 April 2012 22:45, Karl Wright <da...@gmail.com> wrote:
> I think the bigger picture here is that resolving differences of this
> kind requires time, and during the interim we need to be able to
> release software anyway. I have no wish to maintain a forked copy of
> either xerces or httpclient indefinitely, but right at the moment we
> are not prepared or able to use the released versions of these
> libraries. I hope that we can all agree that pragmatism has a value;
> we're certainly not trying to step on people's toes, we're simply
> trying to solve a problem.
One sure way to solve the problem is to use your own package namespace
for any such imported source.
That is definitely sufficient.
Whether it is necessary is another matter, and is not easy to answer
in general as "it depends".
> Thanks,
> Karl
>
>
> On Mon, Apr 2, 2012 at 5:28 PM, Karl Wright <da...@gmail.com> wrote:
>> "what's the use-case for non-well-formed
>> XML?' This thread is probably not the best place to delve further in
>> that direction."
>>
>> Simple use case: parsing malformed RSS feeds. I agree, though, we're
>> getting into the weeds here; I'd love to have this discussion
>> elsewhere, but the point does stand that none of these patch decisions
>> was done lightly. Hopefully the community can accept that.
>>
>> Karl
>>
>> On Mon, Apr 2, 2012 at 4:54 PM, Benson Margulies <bi...@gmail.com> wrote:
>>> Karl,
>>>
>>> I'm exceedingly sorry here that the IPMC as a whole let you down by
>>> not turning into these issues and dealing with them at the outset.
>>> There's been a lot of sensitivity expressed lately to Apache projects
>>> stepping on each other's toes.
>>>
>>> Personally, I have no objection to including mutant jars in a -deps
>>> binary with a clear explanation of what they are, but I would like to
>>> see some support for that view, because I'd could imagine some
>>> objections based on recent email.
>>>
>>> In the longer term, if ManifoldCF really wants to include an "XML
>>> parser with a difference", then it's certainly possible for you to
>>> maintain and release a fork of Xerces under your own package names. I
>>> agree with Sebb that you would be well advised to find some other way
>>> around it. My personal reaction, in complete isolation from the
>>> problem at hand, was 'really? what's the use-case for non-well-formed
>>> XML?' This thread is probably not the best place to delve further in
>>> that direction.
>>>
>>> --benson
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by Karl Wright <da...@gmail.com>.
I think the bigger picture here is that resolving differences of this
kind requires time, and during the interim we need to be able to
release software anyway. I have no wish to maintain a forked copy of
either xerces or httpclient indefinitely, but right at the moment we
are not prepared or able to use the released versions of these
libraries. I hope that we can all agree that pragmatism has a value;
we're certainly not trying to step on people's toes, we're simply
trying to solve a problem.
Thanks,
Karl
On Mon, Apr 2, 2012 at 5:28 PM, Karl Wright <da...@gmail.com> wrote:
> "what's the use-case for non-well-formed
> XML?' This thread is probably not the best place to delve further in
> that direction."
>
> Simple use case: parsing malformed RSS feeds. I agree, though, we're
> getting into the weeds here; I'd love to have this discussion
> elsewhere, but the point does stand that none of these patch decisions
> was done lightly. Hopefully the community can accept that.
>
> Karl
>
> On Mon, Apr 2, 2012 at 4:54 PM, Benson Margulies <bi...@gmail.com> wrote:
>> Karl,
>>
>> I'm exceedingly sorry here that the IPMC as a whole let you down by
>> not turning into these issues and dealing with them at the outset.
>> There's been a lot of sensitivity expressed lately to Apache projects
>> stepping on each other's toes.
>>
>> Personally, I have no objection to including mutant jars in a -deps
>> binary with a clear explanation of what they are, but I would like to
>> see some support for that view, because I'd could imagine some
>> objections based on recent email.
>>
>> In the longer term, if ManifoldCF really wants to include an "XML
>> parser with a difference", then it's certainly possible for you to
>> maintain and release a fork of Xerces under your own package names. I
>> agree with Sebb that you would be well advised to find some other way
>> around it. My personal reaction, in complete isolation from the
>> problem at hand, was 'really? what's the use-case for non-well-formed
>> XML?' This thread is probably not the best place to delve further in
>> that direction.
>>
>> --benson
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by Karl Wright <da...@gmail.com>.
"what's the use-case for non-well-formed
XML?' This thread is probably not the best place to delve further in
that direction."
Simple use case: parsing malformed RSS feeds. I agree, though, we're
getting into the weeds here; I'd love to have this discussion
elsewhere, but the point does stand that none of these patch decisions
was done lightly. Hopefully the community can accept that.
Karl
On Mon, Apr 2, 2012 at 4:54 PM, Benson Margulies <bi...@gmail.com> wrote:
> Karl,
>
> I'm exceedingly sorry here that the IPMC as a whole let you down by
> not turning into these issues and dealing with them at the outset.
> There's been a lot of sensitivity expressed lately to Apache projects
> stepping on each other's toes.
>
> Personally, I have no objection to including mutant jars in a -deps
> binary with a clear explanation of what they are, but I would like to
> see some support for that view, because I'd could imagine some
> objections based on recent email.
>
> In the longer term, if ManifoldCF really wants to include an "XML
> parser with a difference", then it's certainly possible for you to
> maintain and release a fork of Xerces under your own package names. I
> agree with Sebb that you would be well advised to find some other way
> around it. My personal reaction, in complete isolation from the
> problem at hand, was 'really? what's the use-case for non-well-formed
> XML?' This thread is probably not the best place to delve further in
> that direction.
>
> --benson
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by Benson Margulies <bi...@gmail.com>.
Karl,
I'm exceedingly sorry here that the IPMC as a whole let you down by
not turning into these issues and dealing with them at the outset.
There's been a lot of sensitivity expressed lately to Apache projects
stepping on each other's toes.
Personally, I have no objection to including mutant jars in a -deps
binary with a clear explanation of what they are, but I would like to
see some support for that view, because I'd could imagine some
objections based on recent email.
In the longer term, if ManifoldCF really wants to include an "XML
parser with a difference", then it's certainly possible for you to
maintain and release a fork of Xerces under your own package names. I
agree with Sebb that you would be well advised to find some other way
around it. My personal reaction, in complete isolation from the
problem at hand, was 'really? what's the use-case for non-well-formed
XML?' This thread is probably not the best place to delve further in
that direction.
--benson
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by sebb <se...@gmail.com>.
On 2 April 2012 20:11, Karl Wright <da...@gmail.com> wrote:
> Please see below.
>
> On Mon, Apr 2, 2012 at 3:03 PM, Benson Margulies <bi...@gmail.com> wrote:
>> <Jukka added to 'to'; I need backup here so that I don't push you over a cliff.>
>>
>> On Mon, Apr 2, 2012 at 2:19 PM, Karl Wright <da...@gmail.com> wrote:
>>> "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
>>
>> Uh, oh. Now we have another problem, since these are your fellow
>> Apache people at work.
>>
>> Have you submitted patches back to commons and xerces? What sort of
>> reaction did you get?
>>
>
> I submitted patches for all the materials. In the case of httpclient,
> the patches were partly accepted and partly rejected - but they are
> only available in the 4.x version of the library, which we have not
> yet gone to.
You really should upgrade; 3.x is end-of-life.
> The reason is complex; the connectors that would use it
> are difficult to test in the absence of available instances of the
> kinds of repositories they would be communicating with. That's a long
> standing problem I've been trying to find a solution for for more than
> 2 years now.
Depending on the original source, it may be possible to provide local
code that works round the issues.
This can generally be in your own package space.
If the required hooks are missing in the libraries, have you tried
asking the developers to provide a hook?
That may be possible without compromising the original library.
> The patches that were rejected involved things that the package
> developers considered to be "not consistent with mission". For
> example, the xerces change basically allows the parser to accept
> broken xml (if a certain configuration switch is enabled).
I'm not surprised that was rejected.
There has to be a better way to do that.
>> Releasing 'convenience binaries' of modified sources of Apache
>> projects strikes me as somewhat contrary to the overall goals here.
>> I'd like others to weigh in here, but I'd propose that you always
>> ship modified Apache products as source. Forget about 'patch'. Just
>> ship modified sources files and drop them into place in fetched copies
>> of their releases, and build the results.
>>
>
> I'd love to acheive closure, believe me, and there are open tickets to
> this end, but until we do it I don't believe it is wise or feasible to
> withhold ManifoldCF from the community.
>
>> As Sebb points out, you really, really, must not push your modified
>> binaries to maven central unless you use shade or equivalent to change
>> the package names.
>>
>
> I would never do that, obviously.
>
>> I wish that others would weigh in here; how bad an idea is a
>> 'convenience binary' consisting of a modified Apache project library?
>>
>>> - jetty 6.1
>>
>> As a courtesy to the Jetty project, the same rule of 'don't stick this
>> out into maven as a standalone artifact' applies. Otherwise, the
>> two-pronged approach is fine: make convenience binaries, and also
>> provide the user with the ability to rebuild them for themselves. I'd
>> propose the 'whole file replacement' mechanism here as well to solve
>> the Windows problem.
>>
>
> Actually it occurred to me that since there are published binary
> releases of these artifacts, I can download and unpack those. So I
> think I have a solution for this one.
>
> Karl
>
>>>
>>> We also build the jdk1.5 version of hsqldb, which does not require
>>> patching but does require recompilation.
>>
>> That's simple enough as a -dep convenience binary.
>>
>>>
>>> I believe all of these are covered by the Apache 2.0 license.
>>>
>>> Karl
>>>
>>> On Mon, Apr 2, 2012 at 2:14 PM, sebb <se...@gmail.com> wrote:
>>>> On 2 April 2012 17:53, Benson Margulies <bi...@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 <da...@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 <se...@gmail.com> wrote:
>>>>>>>> >> > On 2 April 2012 16:36, Karl Wright <da...@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 <da...@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-unsubscribe@incubator.apache.org
>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by Karl Wright <da...@gmail.com>.
Please see below.
On Mon, Apr 2, 2012 at 3:03 PM, Benson Margulies <bi...@gmail.com> wrote:
> <Jukka added to 'to'; I need backup here so that I don't push you over a cliff.>
>
> On Mon, Apr 2, 2012 at 2:19 PM, Karl Wright <da...@gmail.com> wrote:
>> "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
>
> Uh, oh. Now we have another problem, since these are your fellow
> Apache people at work.
>
> Have you submitted patches back to commons and xerces? What sort of
> reaction did you get?
>
I submitted patches for all the materials. In the case of httpclient,
the patches were partly accepted and partly rejected - but they are
only available in the 4.x version of the library, which we have not
yet gone to. The reason is complex; the connectors that would use it
are difficult to test in the absence of available instances of the
kinds of repositories they would be communicating with. That's a long
standing problem I've been trying to find a solution for for more than
2 years now.
The patches that were rejected involved things that the package
developers considered to be "not consistent with mission". For
example, the xerces change basically allows the parser to accept
broken xml (if a certain configuration switch is enabled).
> Releasing 'convenience binaries' of modified sources of Apache
> projects strikes me as somewhat contrary to the overall goals here.
> I'd like others to weigh in here, but I'd propose that you always
> ship modified Apache products as source. Forget about 'patch'. Just
> ship modified sources files and drop them into place in fetched copies
> of their releases, and build the results.
>
I'd love to acheive closure, believe me, and there are open tickets to
this end, but until we do it I don't believe it is wise or feasible to
withhold ManifoldCF from the community.
> As Sebb points out, you really, really, must not push your modified
> binaries to maven central unless you use shade or equivalent to change
> the package names.
>
I would never do that, obviously.
> I wish that others would weigh in here; how bad an idea is a
> 'convenience binary' consisting of a modified Apache project library?
>
>> - jetty 6.1
>
> As a courtesy to the Jetty project, the same rule of 'don't stick this
> out into maven as a standalone artifact' applies. Otherwise, the
> two-pronged approach is fine: make convenience binaries, and also
> provide the user with the ability to rebuild them for themselves. I'd
> propose the 'whole file replacement' mechanism here as well to solve
> the Windows problem.
>
Actually it occurred to me that since there are published binary
releases of these artifacts, I can download and unpack those. So I
think I have a solution for this one.
Karl
>>
>> We also build the jdk1.5 version of hsqldb, which does not require
>> patching but does require recompilation.
>
> That's simple enough as a -dep convenience binary.
>
>>
>> I believe all of these are covered by the Apache 2.0 license.
>>
>> Karl
>>
>> On Mon, Apr 2, 2012 at 2:14 PM, sebb <se...@gmail.com> wrote:
>>> On 2 April 2012 17:53, Benson Margulies <bi...@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 <da...@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 <se...@gmail.com> wrote:
>>>>>>> >> > On 2 April 2012 16:36, Karl Wright <da...@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 <da...@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-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by Benson Margulies <bi...@gmail.com>.
<Jukka added to 'to'; I need backup here so that I don't push you over a cliff.>
On Mon, Apr 2, 2012 at 2:19 PM, Karl Wright <da...@gmail.com> wrote:
> "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
Uh, oh. Now we have another problem, since these are your fellow
Apache people at work.
Have you submitted patches back to commons and xerces? What sort of
reaction did you get?
Releasing 'convenience binaries' of modified sources of Apache
projects strikes me as somewhat contrary to the overall goals here.
I'd like others to weigh in here, but I'd propose that you always
ship modified Apache products as source. Forget about 'patch'. Just
ship modified sources files and drop them into place in fetched copies
of their releases, and build the results.
As Sebb points out, you really, really, must not push your modified
binaries to maven central unless you use shade or equivalent to change
the package names.
I wish that others would weigh in here; how bad an idea is a
'convenience binary' consisting of a modified Apache project library?
> - jetty 6.1
As a courtesy to the Jetty project, the same rule of 'don't stick this
out into maven as a standalone artifact' applies. Otherwise, the
two-pronged approach is fine: make convenience binaries, and also
provide the user with the ability to rebuild them for themselves. I'd
propose the 'whole file replacement' mechanism here as well to solve
the Windows problem.
>
> We also build the jdk1.5 version of hsqldb, which does not require
> patching but does require recompilation.
That's simple enough as a -dep convenience binary.
>
> I believe all of these are covered by the Apache 2.0 license.
>
> Karl
>
> On Mon, Apr 2, 2012 at 2:14 PM, sebb <se...@gmail.com> wrote:
>> On 2 April 2012 17:53, Benson Margulies <bi...@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 <da...@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 <se...@gmail.com> wrote:
>>>>>> >> > On 2 April 2012 16:36, Karl Wright <da...@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 <da...@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-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by Karl Wright <da...@gmail.com>.
"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 <se...@gmail.com> wrote:
> On 2 April 2012 17:53, Benson Margulies <bi...@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 <da...@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 <se...@gmail.com> wrote:
>>>>> >> > On 2 April 2012 16:36, Karl Wright <da...@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 <da...@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-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about downloading binaries
Posted by sebb <se...@gmail.com>.
On 2 April 2012 17:53, Benson Margulies <bi...@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 <da...@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 <se...@gmail.com> wrote:
>>>> >> > On 2 April 2012 16:36, Karl Wright <da...@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 <da...@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org