Vincent,
I have a view that if something is in Phoenix or Framework but is equally usable to client-side graphical applications or Applets, then perhaps it should not be in those two Avalon sub-projects. Excalibur needs to be broken into multiple jars, each available directly from the Jakarta website, but you'll have to forgive us for concentrating on keeping things inside the Avalon project. It is driven from a simple need, we're trying to encourage as many as possible to start or migrate their server projects to some part of the Avalon framework.
As for Logkit, perhaps we should spend more time making interface/impl separations for the jars too. Or maybe separate jars in addition to an all in one jar..
With respect to migrations from Avalon to Commons, does that sound nearer to your vision?
There is also an issue of useful commons code being mountable in Avalon apps. Take for example the HttpClientConnection. It has constructors of ....
public HttpConnection(String host, int port);
public HttpConnection(String host, int port, boolean secure);
public HttpConnection(String proxyHost, int proxyPort, String host, int port);
public HttpConnection(String proxyHost, int proxyPort, String host, int port, boolean secure);
... this is quite usable, but with Cornerstone we have class that already grant outgoing socket connections. Whilst I am not suggesting you use then, perhaps more constructors could be made that might allow a developer choosing Avalon as platform byt wanting to use HttpConnection from commons to do so and hand a socket, streams or some abstract thing to HttpConnection. The Log abstraction in this tool is good, but you might want to have a LogKit adapter as well as a Log4J adapter :-)
Regards,
- Paul H
I'd like to have your opinion on the possible synergies between Avalon and the Commons projects on reuse and sharing.
Here are some of my thoughts :-)
* Avalon is a service framework (ok, component and service framework) and is suited for lots of projects but some projects may not need/want to use the small Avalon wrapper which is layered on top of the java classes and may want to use directly the implementation (like using a jdbc pool but not as an Avalon component which needs to be managed by a component manager)
* On the other hand, Commons is geared towards providing context neutral libraries which could be used in any context.
* Thus, one solution could be to put in Commons the bare implementation (like the jdbc pool implementation) and put in Avalon a component wrapper on top of it (and reference the commons jars).
* Thus, the bare implementation can also be used independently of Avalon.
* For example, we could easily provide an Avalon component which would wrap around the commons digester, etc.
What do you think ?
If there is an agreement, this should probably be done slowly, one library at a time. I guess, I'm not sure about the knowledge both projects have of each other. I have been using both and I see a lot of possible code reuse/benefits.
Thanks -Vincent
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
