You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Dave Bryson <da...@miceda-data.com> on 2000/12/18 02:33:57 UTC
Using external lib for the command line client
As I'm adding more commands to the client ( cd, ls, etc... ) the code is
starting to get real ugly! So, i've started to look at an external
library that provides some nice features for parsing command line
options ( similar to getopts() ). This library is under an Apache
style license ( see http://code.werken.com).
Would anyone have any objections to using this?
--
Dave Bryson
daveb@miceda-data.com
----------------------
Re: Using external lib for the command line client
Posted by Giacomo Pati <gi...@apache.org>.
Remy Maucherat wrote:
>
> > I recommend you don't. Use the Avalon cli utils (even if you include the
> > java files themself). Why reinventing the wheel especially when there
> > are utility classes developed at Apache.
>
> I never heard that there was such a thing in Avalon. I had enough trouble
> keeping up with the API / block packaging changes, so I had missed it.
Take the avalonapi.jar from the avalon project (or out of the Cocoon 2
lib directory). If you need an example how to use it there is the
src/org/apache/cocoon/Mail.java class in the xml-cocoon2 branch which
show nicely how to use it.
Giacomo
Re: a cookie bug
Posted by "Park, Sung-Gu" <je...@thinkfree.com>.
If you don't check null value,
In apache with mod_dav, you'll get a problem with a cookie.
(As I know, originally, cookies have in trouble)
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: <sl...@jakarta.apache.org>
Sent: Tuesday, December 19, 2000 10:47 AM
Subject: Re: a cookie bug
| > need to patch this part....
|
| Not sending the cookie if it's empty looks reasonable to me :)
| However, I really don't know anything about cookies so I'll leave BC in
| charge of sorting that out.
|
| Remy
|
Re: a cookie bug
Posted by Remy Maucherat <re...@apache.org>.
> need to patch this part....
Not sending the cookie if it's empty looks reasonable to me :)
However, I really don't know anything about cookies so I'll leave BC in
charge of sorting that out.
Remy
a cookie bug
Posted by "Park, Sung-Gu" <je...@thinkfree.com>.
need to patch this part....
==========================
FILE: WebdavMethodBase.java
FROM:
if (!headers.containsKey("cookie")) {
Vector cookies = state.getCookies();
headers.put("cookie",
Cookie.createCookieHeader(host, getPath(), cookies));
}
TO:
if (!headers.containsKey("cookie")) {
Vector cookies = state.getCookies();
if (cookies.size() >0) {
headers.put("Cookie",
Cookie.createCookieHeader(host, getPath(), cookies));
}
Re: Using external lib for the command line client
Posted by Remy Maucherat <re...@apache.org>.
> I recommend you don't. Use the Avalon cli utils (even if you include the
> java files themself). Why reinventing the wheel especially when there
> are utility classes developed at Apache.
I never heard that there was such a thing in Avalon. I had enough trouble
keeping up with the API / block packaging changes, so I had missed it.
Remy
Re: Using external lib for the command line client
Posted by Giacomo Pati <gi...@apache.org>.
Remy Maucherat wrote:
>
> > As I'm adding more commands to the client ( cd, ls, etc... ) the code is
> > starting to get real ugly! So, i've started to look at an external
> > library that provides some nice features for parsing command line
> > options ( similar to getopts() ). This library is under an Apache
> > style license ( see http://code.werken.com).
What about using the Avalon cli utils?
> >
> > Would anyone have any objections to using this?
>
> I don't really like using external libraries for "simple" stuff. I spent a
> loooong time at the beginning of the project (when it went to Apache)
> getting rid of unnecessary dependencies, including Castor, Avalon and Log4j.
Sound kinda ignorant.
> At first, you think it's ok to have all these dependencies, but actually it
> doesn't work because at some point the library has important bug fixes, but
> also make significant changes to the API at the same time (all three
> libraries mentioned above did that to me).
It happend to us too (xml-cocoon). The fact is if you're not building
your community with all people involved you have to do it on your own
(and none of the people from the other project would help you
implementing the API changes that had occurred).
> Also, I have a no-JARs policy for the CVS repository (I got that from
> Craig).
The advantage of that is you have a small cvs footprint and poeple don't
have to donload alot of jars. The disadvantage of this policy is that
people having problems installing it if you depend on external library.
> Usually, if it's something which could need to be pluggable, I write an
> interface and a simple implementation, plus wrappers for other libraries
> (exemple : the logger). If it's something simple, I just reimplement it.
>
> Note 1 : There's no way your code could be that ugly ! Whatever you do, the
> only other Java DAV client (DAV Explorer) will be much worse.
>
> Note 2 : You're allowed to create new classes :))) I think a
> cmd.CommandParser class could be useful.
I recommend you don't. Use the Avalon cli utils (even if you include the
java files themself). Why reinventing the wheel especially when there
are utility classes developed at Apache.
Giacomo
Re: Using external lib for the command line client
Posted by Dave Bryson <da...@miceda-data.com>.
On Sun, 17 Dec 2000, you wrote:
> I don't really like using external libraries for "simple" stuff.
Yes it is simple to do. I was just trying not to reinvent the wheel.
I'll implement our own version and include it with our code.
--
Dave Bryson
daveb@miceda-data.com
----------------------
Re: Using external lib for the command line client
Posted by Remy Maucherat <re...@apache.org>.
> As I'm adding more commands to the client ( cd, ls, etc... ) the code is
> starting to get real ugly! So, i've started to look at an external
> library that provides some nice features for parsing command line
> options ( similar to getopts() ). This library is under an Apache
> style license ( see http://code.werken.com).
>
> Would anyone have any objections to using this?
I don't really like using external libraries for "simple" stuff. I spent a
loooong time at the beginning of the project (when it went to Apache)
getting rid of unnecessary dependencies, including Castor, Avalon and Log4j.
At first, you think it's ok to have all these dependencies, but actually it
doesn't work because at some point the library has important bug fixes, but
also make significant changes to the API at the same time (all three
libraries mentioned above did that to me).
Also, I have a no-JARs policy for the CVS repository (I got that from
Craig).
Usually, if it's something which could need to be pluggable, I write an
interface and a simple implementation, plus wrappers for other libraries
(exemple : the logger). If it's something simple, I just reimplement it.
Note 1 : There's no way your code could be that ugly ! Whatever you do, the
only other Java DAV client (DAV Explorer) will be much worse.
Note 2 : You're allowed to create new classes :))) I think a
cmd.CommandParser class could be useful.
Note 3 : Having said all that, if you really think it's a good idea to use
the library, then you can use it :)
Remy