excalibur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <m...@leosimons.com>
Subject Re: svn commit: r492447
Date Thu, 25 Jan 2007 17:25:51 GMT
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: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org


Mime
View raw message