You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Vitaliy S <ru...@gmail.com> on 2006/06/16 16:13:53 UTC
I wrote several methods for IOCommons FileUtil. How can I donate it to IOCommons?
Hello
I wrote several methods that I'd like to donate to IOCommons FileUtil class
/** converts file (or directory) to byte array using jar algorithm */
byte[] toJarBytesArray(File file) throws IOException
/** converts file (or directory) to byte array using zip algorithm */
byte[] toZipBytesArray(File file) throws IOException
/*lists all files in folder and it's subfolders */
File[] listRecursive(File file)
also I can provide ArrayCommons class (don't know to what commons
project it should be addressed,probably it fits collections)
This class provides mean to inseart, delete, find, etc elements in array.
Regards,
Vitaliy S
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: I wrote several methods for IOCommons FileUtil. How can I donate it to IOCommons?
Posted by Vitaliy S <ru...@gmail.com>.
Thanks,
I will send patch next week.
Regard,
Vitaliy S
On 6/16/06, Niall Pemberton <ni...@gmail.com> wrote:
> On 6/16/06, Vitaliy S <ru...@gmail.com> wrote:
> > Hello
> >
> > I wrote several methods that I'd like to donate to IOCommons FileUtil class
> >
> > /** converts file (or directory) to byte array using jar algorithm */
> > byte[] toJarBytesArray(File file) throws IOException
> >
> > /** converts file (or directory) to byte array using zip algorithm */
> > byte[] toZipBytesArray(File file) throws IOException
> >
> > /*lists all files in folder and it's subfolders */
> > File[] listRecursive(File file)
> >
> > also I can provide ArrayCommons class (don't know to what commons
> > project it should be addressed,probably it fits collections)
> > This class provides mean to inseart, delete, find, etc elements in array.
>
> The best way is to submit an Issue ticket using JIRA:
> http://jakarta.apache.org/commons/io/issue-tracking.html
>
> A patch against the current version of the file is the preferred method:
> http://jakarta.apache.org/commons/io/cvs-usage.html
> http://jakarta.apache.org/commons/patches.html
>
> Niall
>
> > Regards,
> > Vitaliy S
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
Regards,
Vitaliy S
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: I wrote several methods for IOCommons FileUtil. How can I donate it to IOCommons?
Posted by Vitaliy S <ru...@gmail.com>.
>>> re:Getting from File to FileInputStream is easy and no reason to add
>>> compression algorithms to IO.
>> I want to compress file (or dir). I get file on input and file(or byte[])
on
>> output. I can't understand why it should't be placed to IO.
>> If you look throw the code it works with IO packeges most of the time.
>That's a bogus argument. Just because I have code that uses mostly
>java.io classes does not make me file a JSR. ZipEntry is java.util.zip
>btw not java.io.zip.
BTW java.util.zip not java.io.zip is bogus argument too ;-) (probably it was
a mistake of java architect)
IMHO If code deals only with IO and have no sence without IO it is better to
be a part of IO.
I don't mind to add it to compressions if compression developers will allow
it and won't ask me to add it to IO
because my code deals with files while thier code deals with streams and
they love to separate conecrns very much too ;-))))
re:Sorry, but do you actually read my responses?
Yes. Hope you'll do same with mine ;-)
Regards,
Vitaliy S
On 6/19/06, Torsten Curdt <tc...@apache.org> wrote:
>
> > The JarEntry and ZipEntry treat non ASCII symbols different.
> > See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4244499 for
> details
> > (unfortunatly it is the only plase I found it explained).
>
> So the general algorithm is the same only the handling of the entries
> differs.
> Fair enough. Thanks for the pointer.
>
> > re:Getting from File to FileInputStream is easy and no reason to add
> > compression algorithms to IO.
> >
> > I want to compress file (or dir). I get file on input and file(or
> byte[]) on
> > output. I can't understand why it should't be placed to IO.
> > If you look throw the code it works with IO packeges most of the time.
>
> That's a bogus argument. Just because I have code that uses mostly
> java.io classes does not make me file a JSR. ZipEntry is java.util.zip
> btw not java.io.zip.
>
> > Also I don't think it was good idea to seporate compress from IO. ;-)
>
> Well, I like to separate concerns ...putting all different kinds of
> algroithm implementations into one project mixes concerns. And I don't
> think *that'*s a good idea ;-)
>
> > to me it is same as example with PrintWriter
> >
> > what aproach do you prefer
> > this one
> > FileWriter fout = new FileWriter("fred.txt");
> > BufferedWriter bout = new BufferedWriter(fout);
> > PrintWriter pout = new PrintWriter(bout);
> > or that one
> > PrintWriter pout = new PrintWriter("fred.txt");
> >
> > I prefer the second variant.
>
> Sorry, but do you actually read my responses?
>
> cheers
> --
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
Regards,
Vitaliy S
Re: I wrote several methods for IOCommons FileUtil. How can I donate it to IOCommons?
Posted by Torsten Curdt <tc...@apache.org>.
> The JarEntry and ZipEntry treat non ASCII symbols different.
> See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4244499 for details
> (unfortunatly it is the only plase I found it explained).
So the general algorithm is the same only the handling of the entries differs.
Fair enough. Thanks for the pointer.
> re:Getting from File to FileInputStream is easy and no reason to add
> compression algorithms to IO.
>
> I want to compress file (or dir). I get file on input and file(or byte[]) on
> output. I can't understand why it should't be placed to IO.
> If you look throw the code it works with IO packeges most of the time.
That's a bogus argument. Just because I have code that uses mostly
java.io classes does not make me file a JSR. ZipEntry is java.util.zip
btw not java.io.zip.
> Also I don't think it was good idea to seporate compress from IO. ;-)
Well, I like to separate concerns ...putting all different kinds of
algroithm implementations into one project mixes concerns. And I don't
think *that'*s a good idea ;-)
> to me it is same as example with PrintWriter
>
> what aproach do you prefer
> this one
> FileWriter fout = new FileWriter("fred.txt");
> BufferedWriter bout = new BufferedWriter(fout);
> PrintWriter pout = new PrintWriter(bout);
> or that one
> PrintWriter pout = new PrintWriter("fred.txt");
>
> I prefer the second variant.
Sorry, but do you actually read my responses?
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: I wrote several methods for IOCommons FileUtil. How can I donate it to IOCommons?
Posted by Vitaliy S <ru...@gmail.com>.
>>but AFAIK zip and jar share the same compression algorithm anyway.
> The algorithms are similar but not the same.
>Educated me ...Jar*putStream extends Zip*putStream and I have never
come across a jar I could not unzip with the usual zip command.
The JarEntry and ZipEntry treat non ASCII symbols different.
See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4244499 for details
(unfortunatly it is the only plase I found it explained).
re:Getting from File to FileInputStream is easy and no reason to add
compression algorithms to IO.
I want to compress file (or dir). I get file on input and file(or byte[]) on
output. I can't understand why it should't be placed to IO.
If you look throw the code it works with IO packeges most of the time.
Also I don't think it was good idea to seporate compress from IO. ;-)
to me it is same as example with PrintWriter
what aproach do you prefer
this one
FileWriter fout = new FileWriter("fred.txt");
BufferedWriter bout = new BufferedWriter(fout);
PrintWriter pout = new PrintWriter(bout);
or that one
PrintWriter pout = new PrintWriter("fred.txt");
I prefer the second variant.
--
Regards,
Vitaliy S
Re: I wrote several methods for IOCommons FileUtil. How can I donate
it to IOCommons?
Posted by "C. Grobmeier" <gr...@possessed.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
search in the mailinglist archives for the reasons to split up IO and
compress. Then come back and start a discussion for undo this split.
Dakota Jack wrote:
> What the hell is "specialized IO"? Someone makes these terms up and
> then people think they have meaning. Compression is definitely not a
> specialized aspect of IO. Compression is critical to handling IO well
> and belongs in an IO package.
>
> On 6/18/06, C. Grobmeier <gr...@possessed.de> wrote:
> +1 to put this in Compress. I really don't get the point why this should
> be in IO. As Martin said, i see compress as specialized IO. For me it
> would be also OK if IO would depend on compress.
>
> in my latest draft is allready a CompressUtils class where it would fit
> perfectly :-)
>
> regards,
> chris.
>
> Torsten Curdt wrote:
>>> re:but AFAIK zip and jar share the same compression algorithm anyway.
>
>>> The algorithms are similar but not the same.
>
>> Educated me ...Jar*putStream extends Zip*putStream and I have never
>> come across a jar I could not unzip with the usual zip command.
>
>>> re:...and then add a methods for bzip2, compress and gzip, too? See
>>> where I
>>> am heading? Better let's have a CompressUtils in compress.
>
>>> Compress doesn't work with files while IO does. On the other hand IO
>>> doesn't
>>> work with compression while Compress does ;-)
>>> I think it would be good idea to add compress to IO :-)
>
>> It has been removed from there because it was mixing concerns IIRC.
>
>> Getting from File to FileInputStream is easy and no reason to add
>> compression algorithms to IO.
>
>> cheers
>> --
>> Torsten
>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
> --
> Christian Grobmeier
> Possessed Management
> Hurlacher Str. 5 - 86853 Langerringen - Germany
> E-Mail: grobmeier@possessed.de
> Mobil: +(49)(0)175 57 66830
> Fax: +(49) (0)8232 959119
> Web: http://www.possessed.de
>>
- ---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFElnG3kv8rKBUE/T4RAozeAJ9z0ZG49GhO5nEa9936UsabsHaGLACeKIZO
hNU+IOwz/IpUji5jt8j1e18=
=s47f
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: I wrote several methods for IOCommons FileUtil. How can I donate it to IOCommons?
Posted by Dakota Jack <da...@gmail.com>.
What the hell is "specialized IO"? Someone makes these terms up and
then people think they have meaning. Compression is definitely not a
specialized aspect of IO. Compression is critical to handling IO well
and belongs in an IO package.
On 6/18/06, C. Grobmeier <gr...@possessed.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> +1 to put this in Compress. I really don't get the point why this should
> be in IO. As Martin said, i see compress as specialized IO. For me it
> would be also OK if IO would depend on compress.
>
> in my latest draft is allready a CompressUtils class where it would fit
> perfectly :-)
>
> regards,
> chris.
>
> Torsten Curdt wrote:
> >> re:but AFAIK zip and jar share the same compression algorithm anyway.
> >>
> >> The algorithms are similar but not the same.
> >
> > Educated me ...Jar*putStream extends Zip*putStream and I have never
> > come across a jar I could not unzip with the usual zip command.
> >
> >> re:...and then add a methods for bzip2, compress and gzip, too? See
> >> where I
> >> am heading? Better let's have a CompressUtils in compress.
> >>
> >> Compress doesn't work with files while IO does. On the other hand IO
> >> doesn't
> >> work with compression while Compress does ;-)
> >> I think it would be good idea to add compress to IO :-)
> >
> > It has been removed from there because it was mixing concerns IIRC.
> >
> > Getting from File to FileInputStream is easy and no reason to add
> > compression algorithms to IO.
> >
> > cheers
> > --
> > Torsten
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> - --
> Christian Grobmeier
> Possessed Management
> Hurlacher Str. 5 - 86853 Langerringen - Germany
> E-Mail: grobmeier@possessed.de
> Mobil: +(49)(0)175 57 66830
> Fax: +(49) (0)8232 959119
> Web: http://www.possessed.de
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.1 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFElYfkkv8rKBUE/T4RAseWAJ4tE6gNI9YVWsWBVAFdr05CJ5KPQwCeJeRR
> fj3SY+DTd0E0HusGSn+snu8=
> =1GWN
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: I wrote several methods for IOCommons FileUtil. How can I donate
it to IOCommons?
Posted by "C. Grobmeier" <gr...@possessed.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
> Are you developer of compress?
i am just contributing, as you do. There's no "owner" at the moment for
compress, as far as i know.
Regards,
Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFElnECkv8rKBUE/T4RAq1DAJ49JecH/I9w3MPisuKP50rAByKNzgCfW4lV
fS4jhjJLfHBl5HM77eUJcUY=
=WTIy
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: I wrote several methods for IOCommons FileUtil. How can I donate it to IOCommons?
Posted by Vitaliy S <ru...@gmail.com>.
Hello Christian,
Are you developer of compress?
Regards,
Vitaliy S
On 6/18/06, C. Grobmeier <gr...@possessed.de> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> +1 to put this in Compress. I really don't get the point why this should
> be in IO. As Martin said, i see compress as specialized IO. For me it
> would be also OK if IO would depend on compress.
>
> in my latest draft is allready a CompressUtils class where it would fit
> perfectly :-)
>
> regards,
> chris.
>
> Torsten Curdt wrote:
> >> re:but AFAIK zip and jar share the same compression algorithm anyway.
> >>
> >> The algorithms are similar but not the same.
> >
> > Educated me ...Jar*putStream extends Zip*putStream and I have never
> > come across a jar I could not unzip with the usual zip command.
> >
> >> re:...and then add a methods for bzip2, compress and gzip, too? See
> >> where I
> >> am heading? Better let's have a CompressUtils in compress.
> >>
> >> Compress doesn't work with files while IO does. On the other hand IO
> >> doesn't
> >> work with compression while Compress does ;-)
> >> I think it would be good idea to add compress to IO :-)
> >
> > It has been removed from there because it was mixing concerns IIRC.
> >
> > Getting from File to FileInputStream is easy and no reason to add
> > compression algorithms to IO.
> >
> > cheers
> > --
> > Torsten
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> - --
> Christian Grobmeier
> Possessed Management
> Hurlacher Str. 5 - 86853 Langerringen - Germany
> E-Mail: grobmeier@possessed.de
> Mobil: +(49)(0)175 57 66830
> Fax: +(49) (0)8232 959119
> Web: http://www.possessed.de
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.1 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFElYfkkv8rKBUE/T4RAseWAJ4tE6gNI9YVWsWBVAFdr05CJ5KPQwCeJeRR
> fj3SY+DTd0E0HusGSn+snu8=
> =1GWN
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
Regards,
Vitaliy S
Re: I wrote several methods for IOCommons FileUtil. How can I donate
it to IOCommons?
Posted by "C. Grobmeier" <gr...@possessed.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
+1 to put this in Compress. I really don't get the point why this should
be in IO. As Martin said, i see compress as specialized IO. For me it
would be also OK if IO would depend on compress.
in my latest draft is allready a CompressUtils class where it would fit
perfectly :-)
regards,
chris.
Torsten Curdt wrote:
>> re:but AFAIK zip and jar share the same compression algorithm anyway.
>>
>> The algorithms are similar but not the same.
>
> Educated me ...Jar*putStream extends Zip*putStream and I have never
> come across a jar I could not unzip with the usual zip command.
>
>> re:...and then add a methods for bzip2, compress and gzip, too? See
>> where I
>> am heading? Better let's have a CompressUtils in compress.
>>
>> Compress doesn't work with files while IO does. On the other hand IO
>> doesn't
>> work with compression while Compress does ;-)
>> I think it would be good idea to add compress to IO :-)
>
> It has been removed from there because it was mixing concerns IIRC.
>
> Getting from File to FileInputStream is easy and no reason to add
> compression algorithms to IO.
>
> cheers
> --
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
- --
Christian Grobmeier
Possessed Management
Hurlacher Str. 5 - 86853 Langerringen - Germany
E-Mail: grobmeier@possessed.de
Mobil: +(49)(0)175 57 66830
Fax: +(49) (0)8232 959119
Web: http://www.possessed.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFElYfkkv8rKBUE/T4RAseWAJ4tE6gNI9YVWsWBVAFdr05CJ5KPQwCeJeRR
fj3SY+DTd0E0HusGSn+snu8=
=1GWN
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: I wrote several methods for IOCommons FileUtil. How can I donate it to IOCommons?
Posted by Torsten Curdt <tc...@apache.org>.
> re:but AFAIK zip and jar share the same compression algorithm anyway.
>
> The algorithms are similar but not the same.
Educated me ...Jar*putStream extends Zip*putStream and I have never
come across a jar I could not unzip with the usual zip command.
> re:...and then add a methods for bzip2, compress and gzip, too? See where I
> am heading? Better let's have a CompressUtils in compress.
>
> Compress doesn't work with files while IO does. On the other hand IO doesn't
> work with compression while Compress does ;-)
> I think it would be good idea to add compress to IO :-)
It has been removed from there because it was mixing concerns IIRC.
Getting from File to FileInputStream is easy and no reason to add
compression algorithms to IO.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: I wrote several methods for IOCommons FileUtil. How can I donate it to IOCommons?
Posted by Dakota Jack <da...@gmail.com>.
Having compression apart from IO is really questionable. What would
compression be for if not for IO? Whomever made the decision to set
compression aside from IO has made a grave error that will create
complications like this until someone with more sense gets the say.
On 6/18/06, Martin Cooper <ma...@apache.org> wrote:
> On 6/18/06, Vitaliy S <ru...@gmail.com> wrote:
> >
> > re:but AFAIK zip and jar share the same compression algorithm anyway.
> >
> > The algorithms are similar but not the same.
> >
> > re:...and then add a methods for bzip2, compress and gzip, too? See where
> > I
> > am heading? Better let's have a CompressUtils in compress.
> >
> > Compress doesn't work with files while IO does. On the other hand IO
> > doesn't
> > work with compression while Compress does ;-)
> > I think it would be good idea to add compress to IO :-)
>
>
> I agree with Torsten that what you are suggesting would be a better fit for
> the Compress component. The way I look at it is that IO is a more general
> purpose library, and handling compression is more specialised. Once we start
> adding specialised functionality to IO, where would we draw the line? It
> would quickly become bloated and unwieldy. Better to keep specialised
> functionality in a component focussed on that specialisation.
>
> --
> Martin Cooper
>
>
> IMHO My codes fits better IO (I took the idea from IO source code).
> > But if the community won't reject I'll post a patch to IO.
> >
> > Regards,
> > Vitaliy S
> >
> >
> > On 6/18/06, Torsten Curdt <tc...@apache.org> wrote:
> > >
> > > > re: http://jakarta.apache.org/commons/sandbox/compress/
> > > > Thanks for a link, but my code couldn't be applied to compress.
> > Compress
> > > > does nothing with jar.
> > >
> > > Doesn't mean that could not be changed ;-)
> > >
> > > ...but AFAIK zip and jar share the same compression algorithm anyway.
> > > So why the two methods? (Did I miss something?)
> > >
> > > > re:IMO compression is beyond the scope of IO.
> > > > Consider this example from
> > > > http://weblogs.java.net/blog/kgh/archive/2005/11/my_favorite_dea.html
> > >
> > > <snip/>
> > >
> > > > To me apache commons is a set of projects that provide short cuts for
> > > common
> > > > things.
> > > > Of course we all like clean disgin, but I like "clean design" unless
> > it
> > > > doesn't make me to write 20 lines of code to simply zip or jar the
> > > folder
> > > > (same goes for file reading).
> > >
> > > I agree. All I am saying is that it should probably better go into the
> > > compress component.
> > >
> > > > IO Commons provides means to read file into byte array, why not to add
> > a
> > > > method to read a file or dir as compressed byte array too?
> > >
> > > ...and then add a methods for bzip2, compress and gzip, too? See where
> > > I am heading? Better let's have a CompressUtils in compress.
> > >
> > > WDYT?
> > >
> > > cheers
> > > --
> > > Torsten
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> > >
> >
> >
> > --
> > Regards,
> > Vitaliy S
> >
> >
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: I wrote several methods for IOCommons FileUtil. How can I donate it to IOCommons?
Posted by Martin Cooper <ma...@apache.org>.
On 6/18/06, Vitaliy S <ru...@gmail.com> wrote:
>
> re:but AFAIK zip and jar share the same compression algorithm anyway.
>
> The algorithms are similar but not the same.
>
> re:...and then add a methods for bzip2, compress and gzip, too? See where
> I
> am heading? Better let's have a CompressUtils in compress.
>
> Compress doesn't work with files while IO does. On the other hand IO
> doesn't
> work with compression while Compress does ;-)
> I think it would be good idea to add compress to IO :-)
I agree with Torsten that what you are suggesting would be a better fit for
the Compress component. The way I look at it is that IO is a more general
purpose library, and handling compression is more specialised. Once we start
adding specialised functionality to IO, where would we draw the line? It
would quickly become bloated and unwieldy. Better to keep specialised
functionality in a component focussed on that specialisation.
--
Martin Cooper
IMHO My codes fits better IO (I took the idea from IO source code).
> But if the community won't reject I'll post a patch to IO.
>
> Regards,
> Vitaliy S
>
>
> On 6/18/06, Torsten Curdt <tc...@apache.org> wrote:
> >
> > > re: http://jakarta.apache.org/commons/sandbox/compress/
> > > Thanks for a link, but my code couldn't be applied to compress.
> Compress
> > > does nothing with jar.
> >
> > Doesn't mean that could not be changed ;-)
> >
> > ...but AFAIK zip and jar share the same compression algorithm anyway.
> > So why the two methods? (Did I miss something?)
> >
> > > re:IMO compression is beyond the scope of IO.
> > > Consider this example from
> > > http://weblogs.java.net/blog/kgh/archive/2005/11/my_favorite_dea.html
> >
> > <snip/>
> >
> > > To me apache commons is a set of projects that provide short cuts for
> > common
> > > things.
> > > Of course we all like clean disgin, but I like "clean design" unless
> it
> > > doesn't make me to write 20 lines of code to simply zip or jar the
> > folder
> > > (same goes for file reading).
> >
> > I agree. All I am saying is that it should probably better go into the
> > compress component.
> >
> > > IO Commons provides means to read file into byte array, why not to add
> a
> > > method to read a file or dir as compressed byte array too?
> >
> > ...and then add a methods for bzip2, compress and gzip, too? See where
> > I am heading? Better let's have a CompressUtils in compress.
> >
> > WDYT?
> >
> > cheers
> > --
> > Torsten
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> Regards,
> Vitaliy S
>
>
Re: I wrote several methods for IOCommons FileUtil. How can I donate it to IOCommons?
Posted by Vitaliy S <ru...@gmail.com>.
re:but AFAIK zip and jar share the same compression algorithm anyway.
The algorithms are similar but not the same.
re:...and then add a methods for bzip2, compress and gzip, too? See where I
am heading? Better let's have a CompressUtils in compress.
Compress doesn't work with files while IO does. On the other hand IO doesn't
work with compression while Compress does ;-)
I think it would be good idea to add compress to IO :-)
IMHO My codes fits better IO (I took the idea from IO source code).
But if the community won't reject I'll post a patch to IO.
Regards,
Vitaliy S
On 6/18/06, Torsten Curdt <tc...@apache.org> wrote:
>
> > re: http://jakarta.apache.org/commons/sandbox/compress/
> > Thanks for a link, but my code couldn't be applied to compress. Compress
> > does nothing with jar.
>
> Doesn't mean that could not be changed ;-)
>
> ...but AFAIK zip and jar share the same compression algorithm anyway.
> So why the two methods? (Did I miss something?)
>
> > re:IMO compression is beyond the scope of IO.
> > Consider this example from
> > http://weblogs.java.net/blog/kgh/archive/2005/11/my_favorite_dea.html
>
> <snip/>
>
> > To me apache commons is a set of projects that provide short cuts for
> common
> > things.
> > Of course we all like clean disgin, but I like "clean design" unless it
> > doesn't make me to write 20 lines of code to simply zip or jar the
> folder
> > (same goes for file reading).
>
> I agree. All I am saying is that it should probably better go into the
> compress component.
>
> > IO Commons provides means to read file into byte array, why not to add a
> > method to read a file or dir as compressed byte array too?
>
> ...and then add a methods for bzip2, compress and gzip, too? See where
> I am heading? Better let's have a CompressUtils in compress.
>
> WDYT?
>
> cheers
> --
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
Regards,
Vitaliy S
Re: I wrote several methods for IOCommons FileUtil. How can I donate it to IOCommons?
Posted by Torsten Curdt <tc...@apache.org>.
> re: http://jakarta.apache.org/commons/sandbox/compress/
> Thanks for a link, but my code couldn't be applied to compress. Compress
> does nothing with jar.
Doesn't mean that could not be changed ;-)
...but AFAIK zip and jar share the same compression algorithm anyway.
So why the two methods? (Did I miss something?)
> re:IMO compression is beyond the scope of IO.
> Consider this example from
> http://weblogs.java.net/blog/kgh/archive/2005/11/my_favorite_dea.html
<snip/>
> To me apache commons is a set of projects that provide short cuts for common
> things.
> Of course we all like clean disgin, but I like "clean design" unless it
> doesn't make me to write 20 lines of code to simply zip or jar the folder
> (same goes for file reading).
I agree. All I am saying is that it should probably better go into the
compress component.
> IO Commons provides means to read file into byte array, why not to add a
> method to read a file or dir as compressed byte array too?
...and then add a methods for bzip2, compress and gzip, too? See where
I am heading? Better let's have a CompressUtils in compress.
WDYT?
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: I wrote several methods for IOCommons FileUtil. How can I donate it to IOCommons?
Posted by Vitaliy S <ru...@gmail.com>.
re: http://jakarta.apache.org/commons/sandbox/compress/
Thanks for a link, but my code couldn't be applied to compress. Compress
does nothing with jar.
re:IMO compression is beyond the scope of IO.
Consider this example from
http://weblogs.java.net/blog/kgh/archive/2005/11/my_favorite_dea.html
--cut--
#1: Opening a Text File
In JDK 1.1 to 1.4, in order to open a simple text output file you needed to
do:
FileWriter fout = new FileWriter("fred.txt");
BufferedWriter bout = new BufferedWriter(fout);
PrintWriter pout = new PrintWriter(bout);
Say what? Why are we having to type three "new"s in order to do what should
be a simple operation?
In Tiger we have finally added direct support for the common case and now
you can do:
PrintWriter pout = new PrintWriter("fred.txt");
This is an interesting example of a common glitch in our thinking. In the
Java platform we often like to provide lots of well designed, well separated
components that can be plugged together in interesting ways. In fact some
people might argue be that the design is cleaner if the PrintWriter class
doesn't know anything about files. Well, personally, I don't think so. I
think it is good to provide clean, well separated components, but we also
need to provide simple shortcuts to support the most common use cases.
--cut--
To me apache commons is a set of projects that provide short cuts for common
things.
Of course we all like clean disgin, but I like "clean design" unless it
doesn't make me to write 20 lines of code to simply zip or jar the folder
(same goes for file reading).
IO Commons provides means to read file into byte array, why not to add a
method to read a file or dir as compressed byte array too?
Regards,
Vitaliy S
On 6/18/06, Torsten Curdt <tc...@apache.org> wrote:
>
> > Sorry, what is compress?
> > I don't know a class or project in apache commons with such name.
>
> http://jakarta.apache.org/commons/sandbox/compress/
>
> Chris is working of an overhaul of the API and implementations though.
>
> > I think these methods could be added to IOUtils or FileUtils.
>
> IMO compression is beyond the scope of IO.
>
> cheers
> --
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
Regards,
Vitaliy S
Re: I wrote several methods for IOCommons FileUtil. How can I donate it to IOCommons?
Posted by Torsten Curdt <tc...@apache.org>.
> Sorry, what is compress?
> I don't know a class or project in apache commons with such name.
http://jakarta.apache.org/commons/sandbox/compress/
Chris is working of an overhaul of the API and implementations though.
> I think these methods could be added to IOUtils or FileUtils.
IMO compression is beyond the scope of IO.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: I wrote several methods for IOCommons FileUtil. How can I donate it to IOCommons?
Posted by Vitaliy S <ru...@gmail.com>.
Sorry, what is compress?
I don't know a class or project in apache commons with such name.
I think these methods could be added to IOUtils or FileUtils.
Regards
Vitaliy S
On 6/18/06, Torsten Curdt <tc...@apache.org> wrote:
> > > /** converts file (or directory) to byte array using jar algorithm */
> > > byte[] toJarBytesArray(File file) throws IOException
> > >
> > > /** converts file (or directory) to byte array using zip algorithm */
> > > byte[] toZipBytesArray(File file) throws IOException
>
> Shouldn't this better go into compress?
>
> cheers
> --
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
Regards,
Vitaliy S
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: I wrote several methods for IOCommons FileUtil. How can I donate it to IOCommons?
Posted by Torsten Curdt <tc...@apache.org>.
> > /** converts file (or directory) to byte array using jar algorithm */
> > byte[] toJarBytesArray(File file) throws IOException
> >
> > /** converts file (or directory) to byte array using zip algorithm */
> > byte[] toZipBytesArray(File file) throws IOException
Shouldn't this better go into compress?
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: I wrote several methods for IOCommons FileUtil. How can I donate it to IOCommons?
Posted by Niall Pemberton <ni...@gmail.com>.
On 6/16/06, Vitaliy S <ru...@gmail.com> wrote:
> Hello
>
> I wrote several methods that I'd like to donate to IOCommons FileUtil class
>
> /** converts file (or directory) to byte array using jar algorithm */
> byte[] toJarBytesArray(File file) throws IOException
>
> /** converts file (or directory) to byte array using zip algorithm */
> byte[] toZipBytesArray(File file) throws IOException
>
> /*lists all files in folder and it's subfolders */
> File[] listRecursive(File file)
>
> also I can provide ArrayCommons class (don't know to what commons
> project it should be addressed,probably it fits collections)
> This class provides mean to inseart, delete, find, etc elements in array.
The best way is to submit an Issue ticket using JIRA:
http://jakarta.apache.org/commons/io/issue-tracking.html
A patch against the current version of the file is the preferred method:
http://jakarta.apache.org/commons/io/cvs-usage.html
http://jakarta.apache.org/commons/patches.html
Niall
> Regards,
> Vitaliy S
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org