James Carman wrote:
Thank you for your feedback (finally somebody said *something*). I made
this a vote based on the instructions found at
http://wiki.apache.org/jakarta-commons/MovingFromSandboxToProperSVN. Maybe
we should update that WIKI to suggest making a proposal first and then
starting a vote if there are no objections. I really just wanted to know if
there were any technical objections to having proxy move into the commons
proper so that I could fix the problems. I would really like to see this
become a full-fledged commons component. I think it's a very useful idea
and a pretty intuitive API.
I took a look this morning, and also thought it could be quite useful,
and I could follow reasonably well what was going on.
Technically, I remember a couple of oddities, although there may be more:
- the Logging interceptor used Javassist, an odd dependency
- the core ProxyFactory interface could limit you in the future, as you
can't change released interfaces
The more fundamental question however, is whether this is a true commons
component. The sheer number of dependencies is a real question. Now
while a lot are probably optional, some will not be.
This component looks rather like a framework to me, although a very low
level framework. Commons does have other components that have interfaces
and plugin points, but doesn't this one go further than we've had
before? Will most users have to write their own code implementing an
interface defining in [proxy], or can they just used the existing
implementations?
Stephen
As for your suggestion to cut a release candidate now, I like it. I do
think that I need some simple tutorials/examples on the site before it's
ready for a real release, so I'll try to take care of that sometime soon.
Then, I'll cut a release candidate, per your suggestion. I will try to
follow the directions found at
http://jakarta.apache.org/commons/releases/prepare.html to prepare the
release candidate, but I'm probably bound to make mistakes as I'm new to
this project management stuff. I'll probably have a few questions along the
way too!
Also, I would still like to hear if anyone else has any suggestions for
things that I need to take care of before they would consider it ready for
release. Resolving the 1.5 dependency helped of course, even if it did make
the API a lot uglier IMHO. I liked the var-args feature for specifying the
interfaces/classes that the proxy should support and I would rather use the
core JDK Executor class rather than the one from the "concurrent" API. Oh
well.
James
-----Original Message-----
From: robert burrell donkin [mailto:[EMAIL PROTECTED]
Sent: Saturday, October 15, 2005 6:28 AM
To: Jakarta Commons Developers List
Subject: Re: [VOTE] Moving Proxy to Commons Proper
hi james
IMO it would be better to make this a proposal. quite often, small
changes will are needed and discussion required. votes tend to get a
little confused and lost when that happens. usually, it's a bit cleaner
to make a proposal then move to a vote when there are no remaining
objections.
On Fri, 2005-10-14 at 08:17 -0400, James Carman wrote:
All,
Outside projects (currently my Syringe project and the "Crispy" project at
sourceforge) are beginning to want to use Commons Proxy, but are finding
it
difficult since it's in the sandbox and no releases are available. I
believe Proxy's API is close to being ready for a release candidate.
Currently, I don't have any other bright ideas for it, but I'm open to
suggestions. Moving it to the proper will help us prepare it for an
official release.
being ready for an official release is one of my personal criteria for
promotion (so that's good). part of being ready is demonstrating to the
community that the committers know how to cut commons releases.
might i suggest that you cut an example release candidate and upload it
to your apache home directory. not only will this speed the time taken
to cut the first release (we can spot any problems now rather than
later) but it will also give us a better idea of where proxy actually is
right now.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
