river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Barnaby <Frank.Barn...@Sun.COM>
Subject Re: svn commit: r582986 - in /incubator/river/trunk/jtsk: build_common.xml doc/build.html doc/htmlbook/ doc/index.html doc/specs/ doc/specs/html/ index.html
Date Tue, 09 Oct 2007 17:05:03 GMT

On Oct 9, 2007, at 4:50 AM, Mark Brouwer wrote:

> fbarnaby@apache.org wrote:
>> +<!--  
>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 
>> @@@@@
>> +
>> +    <delete file="${src.tar.bundle}"/>
>> +
>> +##
>> +## TODO:
>> +##
>> +## Investigate how to deal with the tar task's 100-character  
>> limitation.
>> +##
> Hi Frank,
> I noticed that you decided to add the tar.gz distribution and it  
> appears
> to raise an issue (which you also mentioned in RIVER-266), namely
> the 100 character limitation. I don't know whether that is an issue
> already as of today, but it might be tomorrow.

Knowing that the issue to provide tar files remains unresolved, I had
added the tar'ing task just to see how it worked, which is when I
noticed the 100 character limitation.  There are options for dealing
with the limitation, but they don't seem particularly useful.  The
"fail", "warn", and "omit" tar-options are obviously not useful, so
"gnu" (ie, gtar) is the only possiblity, and that would require users
to use gnu tar to expand those bundles.  The tar'ing task is currently
commented-out and can be easily removed if we decide to provide zip
bundles only.  I'll open a JIRA-issue if necessary.

> You indicated that supplying a tar.gz format made sense because it
> allows you to retain the file mask,

I think someone else provided that point.

> but I argued the same can be
> accomplished with specifying the filemask as part of the zip task,
> something that still needs to be done and which I will take care of if
> you don't mind.

Right--I'm aware of the filemode options but hadn't dealt with them yet.
Feel free to make the necessary changes.

> Although probably most will ask why is that person so bothered by the
> tar.gz distribution, but I can't find any rationale for supporting the
> tar format besides that it can be done (but this is true for so many
> distribution formats). Note that this is from a person who many years
> ago also provided tar distributions to UNIX customers, but those were
> uncompressed versions ;-)

I'm also not convinced of the necessity for the tar bundle.  I'd suggest
that we start by providing the zip distributions and revisit the tar
discussion if we find the zip bundles to be inadequate for some  


View raw message