Costin Manolache wrote:
> I don't know if I have any voting rights on this issue, but I must send
> my -1 ( as a user at least ) on gratuitous API changes.
I have to agree. Providing a facade with different package
names means a lot of effort, though it may not seem so
at first glance. Passing arguments to methods is easy, but
there are also return values that need to be downcasted
or wrapped, and exceptions that need to be declared or
wrapped.
With the big API overhaul in sight, I'd prefer to keep the
package names for the 3.0 release and switch to the new
namespace for 4.0. In fact, this might even make it clearer
for people whether they are using the old or new API, and
both versions could be used simultaneously in the same
classloader. That's a much smoother migration path than
creating a facade now, and having name clashes later.
cheers,
Roland
Costin Manolache <[EMAIL PROTECTED]>
22.04.2004 02:15
Please respond to "Commons HttpClient Project"
To: Jakarta Project Management Committee List
<[EMAIL PROTECTED]>
cc: Commons HttpClient Project
<[EMAIL PROTECTED]>
Subject: Re: misc related to moving to Jakarta sub-project
Daniel L. Rall wrote:
> [...snip...]
> Jeff, how about providing a set of transitional
> org.apache.commons.httpclient facades or extension classes for a one
> release deprecation period? These classes would ship along side the
> real org.apache.httpclient structure, and all be marked as deprecated,
> allowing consumers of HTTP Client some warning and a brief period for
> transition at little cost to the development community.
>
> - Dan
I don't know if I have any voting rights on this issue, but I must send
my -1 ( as a user at least ) on gratuitous API changes.
The fact that HttpClient moved to jakarta or it may later move to TLP or
in some other place is not a good reason to change it's name.
Ant still has the same package name it had in 1.0 release ( or it had
last time I checked ). The pain you would inflict on users by
requiring them to change code just because you become a jakarta
subproject is completely unjustified.
Yes, sometimes consistancy is good - but consistancy with the current
codebase and users is far more important.
The only reasonable measure to minimize the disruption is to not change
the package name. I can't see any reasonability in hurting
the project users with cosmetic changes.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
