On Jan 23, 2007, at 1:55 PM, Carsten Ziegeler wrote:
Leo Simons wrote:
Ah, it seems like you took out the "implements Component" nearly
everywhere.
This will break all applications using excalibur components with a
container that depends on "Component" being implemented. Removing an
implements interface can also break stuff like serialization...
I think that unless there's a really good reason for it, you should
roll these back :-/
The reason is to remove the dependency to avalon interfaces from the
components interface and make them "real" independent interfaces.
And I think that has these dubious advantages
- one 27K jar less
- one (jar-level) dependency less
if *and only if* the component does not implement any other
interfaces in that jar, which for many of the changes you made is
false (there's still ThreadSafe, AbstractLogEnabled), and even if
that changed, for most deployments today would still be false today
(since most containers depend on avalon-framework so they can support
it).
As well as this more obvious one
- one less marker interface ("api cleanness")
anything else I'm not seeing?
Now, I thought that all avalon implementations can cope with a
component
not implementing the Component interface today.
I think this is true (at least) for the current excalibur-hosted
containers, and also for plexus and turbine. Even if a component does
not implement Component, using post-JDK-1.3 proxy-ing, you can
trivially add it through the container.
However, there's applications out there in the wild built on
different things. About a month ago, some guy named Punjib (or
something), from Bangalore, sent me private e-mail and asked about
how to re-enable JMX support for this cornerstone-connections
component thing they did, since they were moving the build to maven;
turned out his problem was that mx4j used to be called something else.
Point being, all these libraries were independently versioned and
independently released by the ASF (with no dependency on any
particular container, explicitly for use as well without a particular
container), are stable, mature, and have a track record of backwards-
compatibility.
So, even just as a matter of policy, we should only break that
compatibility for a good reason, and only after careful review. (If
my memory serves me well, waaaaay back, we said we'd only do this
stuff as part of an "Avalon5" effort. Heh.) The only reason that
seems to hold some merit, for me, is "cleaner API", and you can also
accomplish that in different ways, like using the Adapter pattern, or
the automated equivalent using some bytecode/proxying wizardry (strip
"Component" when generating the proxy).
(oh, and I'll happily admit its a bit of a pet peeve of mine, too --
these days, a lot of open source java doesn't seem to do much to be
backwards or forwards compatible, and that's a Bad Thing(tm).)
And if there are
solutions out there, they could for example stick to the old version?
If that's the decision we take, the major (or at least, minor)
version number for all these components should be changed, and
readmes/release notes updated.
So the idea is to "pojofy" the compoents stuff from excalibur.
Hmm. Marker interface or not does not impact pojo-ness, does it?
*confused*. In any case, it should not be hard to generate some
adapters that don't have the "implements Component".
What do others think about it?
I can revert the stuff, if required, no problem.
Well, let's see if we reach agreement, first :)
/LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
