incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <daddy...@gmail.com>
Subject Re: Question about downloading binaries
Date Mon, 02 Apr 2012 16:56:05 GMT
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 <bimargulies@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 <daddywri@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.s@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.s@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 <sebbaz@gmail.com> wrote:
>>>> >> > On 2 April 2012 16:36, Karl Wright <daddywri@gmail.com>
wrote:
>>>> >> >> ---------- Forwarded message ----------
>>>> >> >> From: Daniel Shahaf <d.s@daniel.shahaf.name>
>>>> >> >> Date: Mon, Apr 2, 2012 at 11:35 AM
>>>> >> >> Subject: Re: Question about downloading binaries
>>>> >> >> To: Karl Wright <daddywri@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.s@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


Mime
View raw message