Re: [D-haven-developer] Several new releases out

[Alex Karasulu <ao...@bellsouth.net>]

On Tue, 2004-06-29 at 00:00, Berin Loritsch wrote:
> Alex Karasulu wrote:
> > Berin,
> > 
> > I had asked ages ago on how we can consolidate our efforts what was the
> > final verdict on that - can't remember off the top of my head right now.
> > 
> 
> 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?  

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.  

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.

Alex

Re: [D-haven-developer] Several new releases out

[Berin Loritsch <bl...@d-haven.org>]

Alex Karasulu wrote:

>>
>>What's done is done.  I personally don't care where a library comes from
>>as long as its good and it does the job.  To not include a library that
>>does the job you want when there are no license issues and no community
>>issues (I assume you don't hate me...) 
> 
> 
> Berin have I ever shown you that?  All you have is my highest respect.

Sorry, didn't mean for it to come across that way.  It was meant to be
a little toungue in cheek humor.


-- 

"Programming today is a race between software engineers striving to 
build bigger and better idiot-proof programs, and the Universe trying to 
produce bigger and better idiots. So far, the Universe is winning."
                 - Rich Cook

Re: [D-haven-developer] Several new releases out

[Alex Karasulu <ao...@bellsouth.net>]

> Take a look at what's there.  There is a callback provided to handle
> errors and such.  In something as small as an EventBus, any logging
> internal to the system is a symptom of not having proper unit testing.
> As you can see by the JUnitReport at http://api.d-haven.org/event-bus,
> we have 100% pass rate, and according to Clover we have 100% coverage.

That's good I don't think we can say the same.

> >>>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?
> 
> What's done is done.  I personally don't care where a library comes from
> as long as its good and it does the job.  To not include a library that
> does the job you want when there are no license issues and no community
> issues (I assume you don't hate me...) 

Berin have I ever shown you that?  All you have is my highest respect.

> I really see no problem in
> adopting it.  It has an ASF license, isn't that good enough?

No no its just fine.  I think you even gave me committer prives to it a
while back - don't remember right at this moment.
 
> > 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.
> 
> Personally, I don't see what the problem is to have it hosted here.
> If you want to use it, it is available.  If not, then go ahead and
> repeat the work.  There are probably subtle differences based on what
> I learned from the app I built using GUIApp, and I am benefiting from
> it.

The problem is I already repeated the work ages ago.  You see I learned
a few things myself from using it with Eve.  I just want to make sure
these ideas flow and are communicated between us.  Anyway no worries.  I
might start using your version when I get to cleaning up our repo a
little.  

Alex

Re: [D-haven-developer] Several new releases out

[Berin Loritsch <bl...@d-haven.org>]

Alex Karasulu wrote:

>>>>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.

Take a look at what's there.  There is a callback provided to handle
errors and such.  In something as small as an EventBus, any logging
internal to the system is a symptom of not having proper unit testing.
As you can see by the JUnitReport at http://api.d-haven.org/event-bus,
we have 100% pass rate, and according to Clover we have 100% coverage.

>>>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?

What's done is done.  I personally don't care where a library comes from
as long as its good and it does the job.  To not include a library that
does the job you want when there are no license issues and no community
issues (I assume you don't hate me...) I really see no problem in
adopting it.  It has an ASF license, isn't that good enough?

Really, EventBus was created here in D-Haven, and it is the logical
place for it.  The user/developer lists are low traffic enough (almost
none) that I can kep track of it without issue.  You will be able to
incorporate it through Maven, so there shouldn't be any major problems.

>>>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.

Personally, I don't see what the problem is to have it hosted here.
If you want to use it, it is available.  If not, then go ahead and
repeat the work.  There are probably subtle differences based on what
I learned from the app I built using GUIApp, and I am benefiting from
it.

> 
> 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?

IRC?  No, not yet.  I do have an MSN messenger account and an ICQ
account though.  I like to keep discussions in the mail list as much
as possible.

-- 

"Programming today is a race between software engineers striving to 
build bigger and better idiot-proof programs, and the Universe trying to 
produce bigger and better idiots. So far, the Universe is winning."
                 - Rich Cook

Re: [D-haven-developer] Several new releases out

[Alex Karasulu <ao...@bellsouth.net>]

> >>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