directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: [D-haven-developer] Several new releases out
Date Tue, 29 Jun 2004 03:52:15 GMT
> >>Consolidating efforts on EventBus? or something else?
> > 
> > 
> > EventBus specifically.  Perhaps event bus as a pojo can go into commons
> > or somewhere else we can draw from.  WDYT?  
> 
> Just released as its own project.  See
> 
> http://projects.d-haven.org/
> http://api.d-haven.org/event-bus/
> 
> I figured this was much easier than dealing with political stuff and
> the potential of dependency creep because commons wants commons logging
> to infect every codebase.
> 

Not a problem if you follow Paul Hammant's method of using monitors. 
This way the specific monitor implementation can be logger based and
have any dependency you would like.  Plus commons logging is an ok
dependency to have for anyone.  It's a minimal abstraction layer on top
of logging API's to use anything at all.  It's a good thing with so many
Logging API's out there - it leaves the decision upto the deployer.

> > I don't want to impose too many dependencies and if I do I want them all
> > to be internal to Apache projects where ever possible.  
> 
> EventBus does not have any external dependencies.
> 

Right but if I have a dependency on EventBus that goes outside of the
ASF to D-Haven.  I know you want to build up D-Haven (It's your baby)
but ... well I kinda wanna keep things Apache en toto.  You're an Apache
member and you no doubt understand this and see it as good.  It just the
politics you want to avoid right?

> > I see a merlin wrapper in Avalon and perhaps a Fortress wrapper on the
> > excalibur side.  Basically we want the component to be standalone as a
> > POJO so others like the Spring folks for example can use it too if they
> > decide to without our specific philosophies imposed upon them.
> 
> The EventBus is a POJO, and GUIApp does present one way of incorporating
> it into an Avalon context.

Sounds like you've made your decision on this one.  I can't really twist
your arm too much eh :-)?  Ok we'll keep things separate but if you
would like we can revisit it in the future.

Essentially this the same pattern and virtually the same implementation
(there is only so much variance you can inject).  There is no reason why
we should be keeping it as two separate code bases.

You guys have an IRC channel out there btw?

Alex



Mime
View raw message