You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Sung-Gu <je...@apache.org> on 2003/06/25 07:09:40 UTC
[SURVEY] Commons-URI or not?
Hi all,
I suggest that jakarta-commons provides flexible URI issue implementations
as a package.
Various applications using URI concept comes in the internet world. and
they need common mechanisms and algorithms for URI.
For example, all internet programs will need fundamental functionalites of
URI like extensible parsing and manipulation container for URL reference,
URN and URC, escape codec mechanism, charset tranformation functionality,
URI transformation from real world identities or URN, or other
transformations related to DNS or telephony... If it would be prepared
commonly in Jakarta, we can save development powers. So I suggest new
commons-uri package.
FYI, currently the commons-httpclient is using it.
Any comments?
Or any +1, -1?
Sung-Gu
P.S.: If the requirement is very weak, I want to put the new package into
commons-sandbox even for a long while in my opinion...
Re[2]: [SURVEY] Commons-URI or not?
Posted by Anton Tagunov <at...@mail.cnt.ru>.
AT> is there going to be any overlap with
AT> the code project in coding/decoding the uri-s?
I meant will there be a clash in scope with
* codec
* lang//EscapeUtils
- Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [SURVEY] Commons-URI or not? - about some upgrades!
Posted by Sung-Gu <je...@apache.org>.
Anton,
----- Original Message -----
From: "Anton Tagunov" <at...@mail.cnt.ru>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Monday, June 30, 2003 5:00 PM
Subject: Re: [SURVEY] Commons-URI or not?
> Hello Sung-Gu!
>
> SG> I suggest that jakarta-commons provides flexible URI issue implementations
> SG> as a package.
>
> Looking forward to see it appear in jakarta-commons. :-)
>
> BTW, do you think that (char[] data, int start, int len)
> versions of methods should be included?
>
> (Something that I'm probably doing in now for myself)
>
> A recent test that I have carried out showed that .charAt() is
> 1.8 - 1.9 times slower then [] on a char array, just in case I attach
> the test case. This happens because with char[] I believe each char
> takes two bytes, while with String they have UTF8 and probably
> have to travel the whole string from the beginning to find charAt(i).
I see, I believe you. And I saw your test reult also. ;)
> It will be true if someone here will say that it will be premature
> optimization, but if someone is mad enough :) launch a new project
> for URI-s why not think of this also?
>
> Then, it would probably be worth looking into Tomcat internals.
> I believe they should some code of that kind internally too
> (they have to parse URI-s). I believe they should be using
> the char[] versions. Indeed some documentation even on Tomcat 3 said
> that they have found the .stratsWith() and co functions to be
> to slow. This means they've found found a way to speed it up.
> How? I believe they have switched to char[] (don't see other way
> to speed up).
>
> Is this project going to be to ambitious to become a dependency
> both for HttpClient and for Tomcat? :-))
>
> Anyway, even if it does not become one, it would be good to
> a code of equal quality in it.
>
> WBR, Anton
>
> P.S. Just a side-note (the overall ideal of the subproject
> is very much welcomed :) is there going to be any overlap with
> the code project in coding/decoding the uri-s?
>
> HttpClient have just donated something there..
>
> And there are some
> EscapeUtils in lang, aren't there?
Really? I haven't seen that yet... --a
When I try the package as commons-uri at sandbox, I'll look into those your comments.
Thank you for all your comments,
Sung-Gu
P.S.: I'm always very late to check e-mails... ^^;
Re[2]: [SURVEY] Commons-URI or not?
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello, All!
AT> A recent test that I have carried out
Thanks to Dick Zetterberg <di...@transitor.se>
DZ> I do not doubt that charAt is slower but I think your test
DZ> should be modified slightly.
DZ> First a question though:
DZ> What JDK version and what platform are you using?
java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21)
Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)
Win2K SP3, Celeron around 700-800, 512Mb RAM
DZ> Then for the tests it would be better if you ran each test
DZ> one round first (say 1000 iterations or something) in order
DZ> to warm up the hotstop compiler. And then you run it again
DZ> and this time you time the result.
No problem, I was interested myself :)
Essentially the results did not change 1.83 - 1.95
I also added mixed test, when I do not do charAt(0), charAt(1),
charAt(2) sequentially, but
charAt(0), charAt(5), charAt(1), charAt(4), ...
For this the slow down was 2.02 - 2.22.
The reason I added this test was because there is an obvious
optimization possible in String for the sequential string scan,
that is remembering one or several last chatAt() requests and the
positions in UTF8 that they corresponded to. I wanted to see
what happens if we're a bit less linear and the quotient really
increased a bit.
So, here are the new test results
Results for 'abcdefghijk'
string version: 421
array version: 230
string mixed version: 731
array mixed version: 361
coeff = 1.8304347826086957
mixed coeff = 2.0249307479224377
Results for 'abcdefghijklmnopqrstuvwxyz'
string version: 941
array version: 481
string mixed version: 1652
array mixed version: 741
coeff = 1.9563409563409564
mixed coeff = 2.229419703103914
Results for 'abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz'
string version: 1843
array version: 941
string mixed version: 3265
array mixed version: 1462
coeff = 1.9585547290116896
mixed coeff = 2.2332421340629276
Results for 'abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz'
string version: 3635
array version: 1853
string mixed version: 6470
array mixed version: 2884
coeff = 1.961683756071236
mixed coeff = 2.2434119278779474
Results for 'ab?defghijk'
string version: 410
array version: 251
string mixed version: 711
array mixed version: 360
coeff = 1.6334661354581674
mixed coeff = 1.975
Results for 'ab?defghijkab?defghijk'
string version: 801
array version: 411
string mixed version: 1392
array mixed version: 651
coeff = 1.948905109489051
mixed coeff = 2.1382488479262673
Results for 'ab?defghijkab?defghijkab?defghijkab?defghijk'
string version: 1572
array version: 791
string mixed version: 2764
array mixed version: 1242
coeff = 1.9873577749683944
mixed coeff = 2.2254428341384864
Results for 'иАБ???aaaaaaa'
string version: 511
array version: 260
string mixed version: 852
array mixed version: 410
coeff = 1.9653846153846153
mixed coeff = 2.078048780487805
Results for 'иАБ???aaaaaaaиАБ???aaaaaaaиАБ???aaaaaaaиАБ???aaaaaaaиАБ???aaaaaaa'
string version: 2273
array version: 1162
string mixed version: 4046
array mixed version: 1823
coeff = 1.9561101549053357
mixed coeff = 2.219418540866703
And here is the new test
public class B
{
public final static String STR[] =
{
"abcdefghijk",
"abcdefghijklmnopqrstuvwxyz",
"abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz",
"abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz" +
"abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz",
"ab\u1234defghijk",
"ab\u1234defghijk" +
"ab\u1234defghijk",
"ab\u1234defghijk" +
"ab\u1234defghijk" +
"ab\u1234defghijk" +
"ab\u1234defghijk",
"\u0401\u0402\u0403\u1234\u1234\u1234aaaaaaa",
"\u0401\u0402\u0403\u1234\u1234\u1234aaaaaaa" +
"\u0401\u0402\u0403\u1234\u1234\u1234aaaaaaa" +
"\u0401\u0402\u0403\u1234\u1234\u1234aaaaaaa" +
"\u0401\u0402\u0403\u1234\u1234\u1234aaaaaaa" +
"\u0401\u0402\u0403\u1234\u1234\u1234aaaaaaa",
};
public final static int WARMUP1 = 1000;
public final static int WARMUP2 = 10;
public final static int ITER = 1000000;
private static int sum;
private static long testCharAt( final String str, final int iter )
{
final int len = str.length();
sum = 0;
final long t1 = System.currentTimeMillis();
for ( int i = 0; i < iter; ++i )
{
for ( int j = 0; j < len; ++j )
{
sum += str.charAt( j );
}
}
final long t2 = System.currentTimeMillis();
return t2 - t1;
}
private static long testMixedCharAt( final String str, final int iter )
{
final int len = str.length();
final int len1 = len - 1;
sum = 0;
final long t1 = System.currentTimeMillis();
for ( int i = 0; i < iter; ++i )
{
for ( int j = 0; j < len; ++j )
{
sum += str.charAt( j );
sum += str.charAt( len1 - j );
}
}
final long t2 = System.currentTimeMillis();
return t2 - t1;
}
private static long testArr( final char[] arr, final int iter )
{
final int len = arr.length;
sum = 0;
final long t1 = System.currentTimeMillis();
for ( int i = 0; i < iter; ++i )
{
for ( int j = 0; j < len; ++j )
{
sum += arr[ j ];
}
}
final long t2 = System.currentTimeMillis();
return t2 - t1;
}
private static long testMixedArr( final char[] arr, final int iter )
{
final int len = arr.length;
final int len1 = len - 1;
sum = 0;
final long t1 = System.currentTimeMillis();
for ( int i = 0; i < iter; ++i )
{
for ( int j = 0; j < len; ++j )
{
sum += arr[ j ];
sum += arr[ len1 - j ];
}
}
final long t2 = System.currentTimeMillis();
return t2 - t1;
}
public static final void test( final String str, final int iter )
{
final int len = str.length();
final char[] arr = str.toCharArray();
/*** round 1 ***/
// warmup the hot spot compiler
for( int a = 0; a < WARMUP2; ++a )
{
testCharAt( str, WARMUP1 );
}
final long time1 = testCharAt( str, iter );
for( int a = 0; a < WARMUP2; ++a )
{
testArr( arr, WARMUP1 );
}
final long time2 = testArr( arr, iter );
/*** round 2 ***/
// warmup the hot spot compiler
for( int a = 0; a < WARMUP2; ++a )
{
testMixedCharAt( str, WARMUP1 );
}
final long time3 = testMixedCharAt( str, iter );
for( int a = 0; a < WARMUP2; ++a )
{
testMixedArr( arr, WARMUP1 );
}
final long time4 = testMixedArr( arr, iter );
System.out.println( "Results for '" + str + "'\n" +
" string version: " + time1 + "\n" +
" array version: " + time2 + "\n" +
" string mixed version: " + time3 + "\n" +
" array mixed version: " + time4 + "\n" +
" coeff = " + ((double)time1/time2) + "\n" +
" mixed coeff = " + ((double)time3/time4) + "\n" +
"" );
}
public static void main( String args[] )
{
for( int k = 0; k < STR.length; ++k )
{
test( STR[k], ITER );
}
}
}
Thanks, Dick Zetterberg!
- Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re[2]: [SURVEY] Commons-URI or not?
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hi, All!
AT> A recent test that I have carried out showed that .charAt() is
AT> 1.8 - 1.9 times slower then [] on a char array, just in case I attach
AT> the test case.
Oopps, have fogotten the test, here it is in this mail.
And here are the results I got
Results for 'abcdefghijk'
string version: 426.6
array version: 242.4
coeff = 1.75990099009901
Results for 'ab?defghijk'
string version: 441.6
array version: 233.3
coeff = 1.8928418345477926
Results for '??????aaaaaaa'
string version: 510.8
array version: 272.4
coeff = 1.8751835535976504
public class B
{
public final static String STR1 = "abcdefghijk";
public final static String STR2 = "ab\u1234defghijk";
public final static String STR3 =
"\u0401\u0402\u0403\u1234\u1234\u1234aaaaaaa";
public final static int AVG = 10;
public final static long ITER = 1000000l;
private static int sum;
public static final void test( final String str, final int avg,
final long iter )
{
final int len = str.length();
final char[] arr = str.toCharArray();
final long t1 = System.currentTimeMillis();
for ( int a = 0; a < avg; ++a )
{
sum = 0;
for ( long i = 0; i < iter; ++i )
{
for ( int j = 0; j < len; ++j )
{
sum += str.charAt( j );
}
}
}
final long t2 = System.currentTimeMillis();
for ( int a = 0; a < avg; ++a )
{
sum = 0;
for ( long i = 0; i < iter; ++i )
{
for ( int j = 0; j < len; ++j )
{
sum += arr[ j ];
}
}
}
final long t3 = System.currentTimeMillis();
System.out.println( "Results for '" + str + "'\n" +
" string version: " + ((double)( t2 - t1 ) / avg ) + "\n" +
" array version: " + ((double)( t3 - t2 ) / avg ) + "\n" +
" coeff = " + ((double)( t2 - t1 )/(double)( t3 - t2 )) );
}
public static void main( String args[] )
{
test( STR1, AVG, ITER );
test( STR2, AVG, ITER );
test( STR3, AVG, ITER );
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [SURVEY] Commons-URI or not?
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello Sung-Gu!
SG> I suggest that jakarta-commons provides flexible URI issue implementations
SG> as a package.
Looking forward to see it appear in jakarta-commons. :-)
BTW, do you think that (char[] data, int start, int len)
versions of methods should be included?
(Something that I'm probably doing in now for myself)
A recent test that I have carried out showed that .charAt() is
1.8 - 1.9 times slower then [] on a char array, just in case I attach
the test case. This happens because with char[] I believe each char
takes two bytes, while with String they have UTF8 and probably
have to travel the whole string from the beginning to find charAt(i).
It will be true if someone here will say that it will be premature
optimization, but if someone is mad enough :) launch a new project
for URI-s why not think of this also?
Then, it would probably be worth looking into Tomcat internals.
I believe they should some code of that kind internally too
(they have to parse URI-s). I believe they should be using
the char[] versions. Indeed some documentation even on Tomcat 3 said
that they have found the .stratsWith() and co functions to be
to slow. This means they've found found a way to speed it up.
How? I believe they have switched to char[] (don't see other way
to speed up).
Is this project going to be to ambitious to become a dependency
both for HttpClient and for Tomcat? :-))
Anyway, even if it does not become one, it would be good to
a code of equal quality in it.
WBR, Anton
P.S. Just a side-note (the overall ideal of the subproject
is very much welcomed :) is there going to be any overlap with
the code project in coding/decoding the uri-s?
HttpClient have just donated something there..
And there are some
EscapeUtils in lang, aren't there?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [SURVEY] Commons-URI or not?
Posted by Jandalf <js...@apache.org>.
The Guidelines of the commons charter has some guidance here:
http://jakarta.apache.org/commons/charter.html
1. The primary unit of reuse and release is the package.
2. The package library is not a framework but a collection of
components designed to be used independently.
3. Each package must have a clearly defined purpose, scope, and API
-- Do one thing well, and keep your contracts.
4. ...
HttpClient is generally concerned with URLs but URIs are useful beyond
HttpClient. URIs are well documented with relevent RFCs. I think that
a seperate RFC conforming URI package would be an excellent addition to
Jakarta.
A project of this nature should copy the current code from httpclient
and start a sandbox project. Development should continue there untill
development has been proven and a formal commons project proposal can be
made.
Likely the developers would want to seek HttpClient as a key user of the
new package, but this does not mandate that HttpClient will use the new
package. Nor does it require that a jar dependancy be added (re-use can
be achieved in multiple ways) but the new codebase could be re-used in
other ways if that was deemed preferable.
I would support having a seperate URI package. From my perspective the
possible benefits are clear and the possible drawbacks are avoidable.
Jandalf.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [SURVEY] Commons-URI or not? - about starting point
Posted by Sung-Gu <je...@apache.org>.
----- Original Message -----
From: "Martin Cooper" <ma...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Cc: "Commons HttpClient Project" <co...@jakarta.apache.org>
Sent: Thursday, June 26, 2003 2:37 AM
Subject: Re: [SURVEY] Commons-URI or not?
>
>
> On Wed, 25 Jun 2003, Sung-Gu wrote:
>
> >
> > Hi all,
> >
> > I suggest that jakarta-commons provides flexible URI issue
implementations
> > as a package.
> >
> > Various applications using URI concept comes in the internet world.
and
> > they need common mechanisms and algorithms for URI.
> >
> > For example, all internet programs will need fundamental functionalites
of
> > URI like extensible parsing and manipulation container for URL
reference,
> > URN and URC, escape codec mechanism, charset tranformation
functionality,
> > URI transformation from real world identities or URN, or other
> > transformations related to DNS or telephony... If it would be prepared
> > commonly in Jakarta, we can save development powers. So I suggest new
> > commons-uri package.
>
> If you want to do this, I would recommend starting in the sandbox. That
> way, we'll find out if it is viable as a standalone component, and, in
> particular, if a community develops around it.
Yes, I think so. That would be the proper procudure.
At this moment, I try to ask others' needs, not simply, rather than their
interests and concerns. ;)
Thank you,
Sung-Gu
> Even though the code originates from HttpClient, I would be against a
> Commons-URI component starting out in Commons Proper, because history
> shows us that a body of code does not always develop into a viable
> component, with its own community, just because it comes from an already
> successful project.
>
> --
> Martin Cooper
>
>
> >
> > FYI, currently the commons-httpclient is using it.
> >
> > Any comments?
> > Or any +1, -1?
> >
> > Sung-Gu
> >
> > P.S.: If the requirement is very weak, I want to put the new package
into
> > commons-sandbox even for a long while in my opinion...
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [SURVEY] Commons-URI or not?
Posted by Martin Cooper <ma...@apache.org>.
On Wed, 25 Jun 2003, Sung-Gu wrote:
>
> Hi all,
>
> I suggest that jakarta-commons provides flexible URI issue implementations
> as a package.
>
> Various applications using URI concept comes in the internet world. and
> they need common mechanisms and algorithms for URI.
>
> For example, all internet programs will need fundamental functionalites of
> URI like extensible parsing and manipulation container for URL reference,
> URN and URC, escape codec mechanism, charset tranformation functionality,
> URI transformation from real world identities or URN, or other
> transformations related to DNS or telephony... If it would be prepared
> commonly in Jakarta, we can save development powers. So I suggest new
> commons-uri package.
If you want to do this, I would recommend starting in the sandbox. That
way, we'll find out if it is viable as a standalone component, and, in
particular, if a community develops around it.
Even though the code originates from HttpClient, I would be against a
Commons-URI component starting out in Commons Proper, because history
shows us that a body of code does not always develop into a viable
component, with its own community, just because it comes from an already
successful project.
--
Martin Cooper
>
> FYI, currently the commons-httpclient is using it.
>
> Any comments?
> Or any +1, -1?
>
> Sung-Gu
>
> P.S.: If the requirement is very weak, I want to put the new package into
> commons-sandbox even for a long while in my opinion...
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: dependency hell
Posted by Chris Brown <br...@reflexe.fr>.
Hello all,
Concerning the "dependency hell" thread (that I sort of started on
httpclient's list), I would favour an "all-in-one, large .jar" approach as
suggested by Eric Johnson, because it should keep all versions and internal
dependencies nicely in sync, even if it complicates the release cycle. It'd
be nice to keep an option to build (from source, with
Ant/maven/<build-system-of-the-day>) independent components, rather than one
big component, for those that *really* need it. For projects outside of the
"all-in-one" jar (say, commons-sql), this'd at least reduce significantly
the number of dependencies (and the associated synchronisation problems).
On a related point, any comments on the rationale behind so many Apache
projects seemingly "competing" with each other? From a user perspective,
this is confusing and off-putting, from a developer perspective, it seems a
waste of resources (why re-invent the wheel with slight differences, instead
of making a better wheel?). Here's some examples that, as a user, seem to
illustrate this point:
- ant and maven
- torque and commons-sql
- oro and regexp
- tapestry, turbine, etc.
Hope this is constructive,
Chris
PS: I'm not subscribed to commons-dev, I'm (exceptionnally) cross-posting as
suggested by Eric ; I probably won't receive any replies unless I'm CC'd.
----- Original Message -----
From: "Eric Johnson" <er...@tibco.com>
To: "Commons HttpClient Project" <co...@jakarta.apache.org>
Cc: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Wednesday, June 25, 2003 3:38 PM
Subject: Re: [SURVEY] Commons-URI or not?
> It would seem that most if not all of the responses from the HttpClient
> crew responded only to the HttpClient list, and not to commons dev. So
> I'm not sure that all that might need/want to see the entirely negative
> feedback have seen it. I don't subscribe to commons-dev, so if this
> doesn't get through, would someone mind reposting it there?
>
> I too am against a separate URI commons package, at least for the moment.
>
> In any event, who else depends on a URI class? At the moment, there are
> three obvious sources for URI type functionality that I am aware of:
> HttpClient, Slide, and JRE 1.4. Slide, rather than using what is in
> HttpClient, is using its own, even though Slide includes HttpClient in
> its build dependencies. Without anyone even sharing the code in the
> first place, it doesn't seem like a good candidate for a separate project.
>
> One of the negatives that others have mentioned on the HttpClient list
> is the growing dependency problem within the Apache projects,
> particularly with the myriad of dependencies on commons projects, and
> among the commons projects themselves. Perhaps what we need to do is
> start clumping some of the commons projects together, as well as having
> the stand-alone pieces we have now. A first cut at combining some of
> the commons projects into one giant JAR might include:
>
> * beanutil
> * cli
> * codec
> * collections
> * dbcp
> * fileupload
> * httpclient
> * lang
> * logging
> * net
> * pool
>
> My criteria for the above list were three-fold - base requirement of JRE
> 1.2 or later, that the project should have an official blessed release,
> and that it shouldn't depend on any outside libraries - like an XML
> parser - at runtime. And I'll admit that I'm fudging on HttpClient (and
> file upload) a little, in that I don't think anyone following HttpClient
> would want to include the 1.0 release, but I'm guessing that by the time
> such a project is agreed upon and pulled together, HttpClient 2.0 will
> be final.... At least here's to hoping.
>
> Anyway, to the extent that a separate URI package would make sense, if
> we had a model such as the above, where most people used the one giant
> JAR instead of the individual ones, the creation of a separate commons
> URI project would be largely one of focus and interest, rather than an
> additional dependency quagmire.
>
> -Eric Johnson
>
> chris brown wrote:
>
> Please NO !!!
>
> We're now finding it very difficult to use a lot of Jakarta projects,
> because of "dependency hell"... it's becoming worse than Microsoft's
> famous "DLL hell" problem. The more self-contained you can keep an
> API, the better ; yes, there are issues concerning code re-use, but
> at present, we're having great difficulty using more than one Jakarta
> project at a time in our projects.
>
> If you only use one Jakarta project at a time, you're generally ok.
>
> If you try to use more than one Jakarta project at the same time
> within your own projects, you have to hope that no such library
> relies upon any other commons component, because chances are that
> they won't be expecting the same version of each library (they don't
> always include the latest version of each "basic" API, and each
> "main" Jakarta API has a different release cycle). Commons-logging
> is generally included as standard. If each version of an API was
> always backwards-compatible, maybe that'd work, but that's not always
> pratical, realistic, or efficient.
>
> Or start hacking around with classloaders... and this too becomes a
> futile exercise when you start deploying things on some versions of
> Tomcat (for example) that "helpfully" expose common functionality,
> using perhaps incompatible versions of APIs (usually from commons)
> that are obsolete (or more recent than) the versions of these APIs
> required by some other "empirical" Jakarta library.
>
> Some of the recent commons components, such as commons-sql, have a
> ridiculous number of dependencies.
>
> One other observation about Commons projects (and
> Jakarta/Apache in general)
> ; although code re-use seems like a good idea, I'm now seeing several
> different projects that aim to do more or less the same thing, such
> as :
>
> - ant and maven
> - torque and commons-sql
> - oro and regexp
> - tapestry, turbine, etc.
>
> Furthermore, if there's Log4J, why not just use it, instead of the
> Commons-Logging layer? If a project goes JDK1.4+ -only after, then
> migrate to java.util.logging ?
>
> On a personal note, I'm hoping that commons-net, which used to just
> work "as-is", doesn't start depending on lots of different API
> versions...
>
> I know this is the HttpClient list, and not some general Jakarta
> list, but I sincerely hope that one of the few remaining Jakarta
> projects that doesn't depend on many others doesn't go down the same
> dependency nightmare route as many of the others, so I wanted to
> illustrate *why* (as a user) I feel this way...
>
> - Chris
>
> Sung-Gu wrote:
>
> >Hi all,
> >
> >I suggest that jakarta-commons provides flexible URI issue
implementations
> >as a package.
> >
> >Various applications using URI concept comes in the internet world. and
> >they need common mechanisms and algorithms for URI.
> >
> >For example, all internet programs will need fundamental functionalites
of
> >URI like extensible parsing and manipulation container for URL reference,
> >URN and URC, escape codec mechanism, charset tranformation
functionality,
> >URI transformation from real world identities or URN, or other
> >transformations related to DNS or telephony... If it would be prepared
> >commonly in Jakarta, we can save development powers. So I suggest new
> >commons-uri package.
> >
> >FYI, currently the commons-httpclient is using it.
> >
> >Any comments?
> >Or any +1, -1?
> >
> >Sung-Gu
> >
> >P.S.: If the requirement is very weak, I want to put the new package
into
> >commons-sandbox even for a long while in my opinion...
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [SURVEY] Commons-URI or not? - about its needs
Posted by Sung-Gu <je...@apache.org>.
----- Original Message -----
From: "Eric Johnson" <er...@tibco.com>
> I too am against a separate URI commons package, at least for the moment.
[snip]
> Anyway, to the extent that a separate URI package would make sense, if
> we had a model such as the above, where most people used the one giant
> JAR instead of the individual ones, the creation of a separate commons
> URI project would be largely one of focus and interest, rather than an
> additional dependency quagmire.
I think so... ;)
Thank you for clearing the current true issue.
Sung-Gu
> -Eric Johnson
>
> Sung-Gu wrote:
>
> >Hi all,
> >
> >I suggest that jakarta-commons provides flexible URI issue
implementations
> >as a package.
> >
> >Various applications using URI concept comes in the internet world. and
> >they need common mechanisms and algorithms for URI.
> >
> >For example, all internet programs will need fundamental functionalites
of
> >URI like extensible parsing and manipulation container for URL reference,
> >URN and URC, escape codec mechanism, charset tranformation
functionality,
> >URI transformation from real world identities or URN, or other
> >transformations related to DNS or telephony... If it would be prepared
> >commonly in Jakarta, we can save development powers. So I suggest new
> >commons-uri package.
> >
> >FYI, currently the commons-httpclient is using it.
> >
> >Any comments?
> >Or any +1, -1?
> >
> >Sung-Gu
> >
> >P.S.: If the requirement is very weak, I want to put the new package
into
> >commons-sandbox even for a long while in my opinion...
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [SURVEY] Commons-URI or not? - jarring or ... and exposing some classes?
Posted by Sung-Gu <je...@apache.org>.
I'd like to consider the compelete opposite situation.
If a project (knows what they exactly need) wanted just several classes from
another project,
should they include a whole jar from the project? What's the possbile
solution?
Here you are, my one...
You can notice there are xxx.md5, xxx.asc xxx.tar.gz and xxx.zip at
http://www.apache.org/dist/jakarta/commons/xxxx
How about exposing some classes files at
http://www.apache.org/dist/jakarta/commons/xxxx/classes?
Is it nonsense with ant from net? They might be jarred as 'an only jar' in
build.xml of antother project
Hmmm... Just my simple thought... your opinion please...
Sung-Gu
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Cc: "Commons HttpClient Project" <co...@jakarta.apache.org>
Sent: Thursday, June 26, 2003 2:06 AM
Subject: Re: [SURVEY] Commons-URI or not?
>
>
> On Wed, 25 Jun 2003, Eric Johnson wrote:
>
> > [snip]
> > One of the negatives that others have mentioned on the HttpClient list
> > is the growing dependency problem within the Apache projects,
> > particularly with the myriad of dependencies on commons projects, and
> > among the commons projects themselves. Perhaps what we need to do is
> > start clumping some of the commons projects together, as well as having
> > the stand-alone pieces we have now. A first cut at combining some of
> > the commons projects into one giant JAR might include:
> >
>
> Have a look at the build.xml file in the "combo" subdirectory of the
> jakarta-commons CVS repository -- it lets you do exactly this sort of
> thing, and even lets you pick the versions you want (by virtue of
> specifying the CVS tags to build with).
>
> I try to maintain the "latest official release" CVS tag of all released
> commons packages (but nothing from the sandbox, since by definition they
> are not released), but don't always have a chance to do so in a timely
> manner -- others are welcome to help.
>
> Craig McClanahan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
commons-httpclient-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [SURVEY] Commons-URI or not?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 25 Jun 2003, Eric Johnson wrote:
> [snip]
> One of the negatives that others have mentioned on the HttpClient list
> is the growing dependency problem within the Apache projects,
> particularly with the myriad of dependencies on commons projects, and
> among the commons projects themselves. Perhaps what we need to do is
> start clumping some of the commons projects together, as well as having
> the stand-alone pieces we have now. A first cut at combining some of
> the commons projects into one giant JAR might include:
>
Have a look at the build.xml file in the "combo" subdirectory of the
jakarta-commons CVS repository -- it lets you do exactly this sort of
thing, and even lets you pick the versions you want (by virtue of
specifying the CVS tags to build with).
I try to maintain the "latest official release" CVS tag of all released
commons packages (but nothing from the sandbox, since by definition they
are not released), but don't always have a chance to do so in a timely
manner -- others are welcome to help.
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [SURVEY] Commons-URI or not?
Posted by Eric Johnson <er...@tibco.com>.
It would seem that most if not all of the responses from the HttpClient
crew responded only to the HttpClient list, and not to commons dev. So
I'm not sure that all that might need/want to see the entirely negative
feedback have seen it. I don't subscribe to commons-dev, so if this
doesn't get through, would someone mind reposting it there?
I too am against a separate URI commons package, at least for the moment.
In any event, who else depends on a URI class? At the moment, there are
three obvious sources for URI type functionality that I am aware of:
HttpClient, Slide, and JRE 1.4. Slide, rather than using what is in
HttpClient, is using its own, even though Slide includes HttpClient in
its build dependencies. Without anyone even sharing the code in the
first place, it doesn't seem like a good candidate for a separate project.
One of the negatives that others have mentioned on the HttpClient list
is the growing dependency problem within the Apache projects,
particularly with the myriad of dependencies on commons projects, and
among the commons projects themselves. Perhaps what we need to do is
start clumping some of the commons projects together, as well as having
the stand-alone pieces we have now. A first cut at combining some of
the commons projects into one giant JAR might include:
* beanutil
* cli
* codec
* collections
* dbcp
* fileupload
* httpclient
* lang
* logging
* net
* pool
My criteria for the above list were three-fold - base requirement of JRE
1.2 or later, that the project should have an official blessed release,
and that it shouldn't depend on any outside libraries - like an XML
parser - at runtime. And I'll admit that I'm fudging on HttpClient (and
file upload) a little, in that I don't think anyone following HttpClient
would want to include the 1.0 release, but I'm guessing that by the time
such a project is agreed upon and pulled together, HttpClient 2.0 will
be final.... At least here's to hoping.
Anyway, to the extent that a separate URI package would make sense, if
we had a model such as the above, where most people used the one giant
JAR instead of the individual ones, the creation of a separate commons
URI project would be largely one of focus and interest, rather than an
additional dependency quagmire.
-Eric Johnson
Sung-Gu wrote:
>Hi all,
>
>I suggest that jakarta-commons provides flexible URI issue implementations
>as a package.
>
>Various applications using URI concept comes in the internet world. and
>they need common mechanisms and algorithms for URI.
>
>For example, all internet programs will need fundamental functionalites of
>URI like extensible parsing and manipulation container for URL reference,
>URN and URC, escape codec mechanism, charset tranformation functionality,
>URI transformation from real world identities or URN, or other
>transformations related to DNS or telephony... If it would be prepared
>commonly in Jakarta, we can save development powers. So I suggest new
>commons-uri package.
>
>FYI, currently the commons-httpclient is using it.
>
>Any comments?
>Or any +1, -1?
>
>Sung-Gu
>
>P.S.: If the requirement is very weak, I want to put the new package into
>commons-sandbox even for a long while in my opinion...
>
>
>
>
>------------------------------------------------------------------------
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org