Craig,
 
    I hear what you're saying.  At times, I feel like we're dealing with a
two-edge sword. I wish our teams could do more work with nightly builds. One
of the battles I constantly face with our management is their reluctancy to
even allow us to work with "beta" releases (or lesser) in our development
environment.  Their fear is, not knowing when an official release will
occur, that beta open-source software will end up in production.  But my
argument is, hey if we've successfully completed all levels of testing
(unit, integration, q/a, etc.), have the corresponding source code, know
what the open bugs/issues/limitatoins are, what's the worse that can happen?
We discover a bug that we have to fix (and possibly relay back to the
open-source development team).  How is this any different that with the code
we develop in-house?  I guarantee you we have in-house software running in
production that should be labeled "beta" (or less), but isn't because of a
schedule that had to be met. It's too bad the label "beta" has to be used,
it has such a negative connotation.  I did read on the mailing lists a while
back that Lands End was using a beta 1 version of Struts 1.1 in production.
I think that says something in it's own right.  I'm sure there are others
doing the same.
    There is an "open-source" mindset that I'm trying to slowly change in
our company.  I've tried to convince our management that beta "open-source"
is different than beta "commercial".  Open-source projects don't have
schedule deadlines that will affect the quarterly financial results.  Hence,
they move a slower and strive for 100% perfection. If we do a thorough job
of testing, with a high-level of confidence, it shouldn't matter whether
something is beta or not.  One issue we do have with Struts, however, is the
many other Jakarta Commons libraries that it depends upon.  Since we're
using other software that also uses the Jakarta-Commons libraries, we do
have compatability concerns.  Hence, it's a little trickier trying to use a
"unofficially" released version of Struts vs. some project that has very
little, or no dependency on other libraries.
    Additional thoughts on this are greatly appreciated,
 
Thanks,

JOHN
 
-----Original Message----- 
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] 
Sent: Fri 2/28/2003 9:52 PM 
To: Struts Users Mailing List 
Cc: 
Subject: Re: WrapDynaBean does not support contains()





On Fri, 28 Feb 2003, WILLIAMS,RAND (HP-USA,ex1) wrote: 

> Date: Fri, 28 Feb 2003 17:16:02 -0500 
> From: "WILLIAMS,RAND (HP-USA,ex1)" <[EMAIL PROTECTED]> 
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> 
> To: 'Struts Users Mailing List' <[EMAIL PROTECTED]> 
> Subject: WrapDynaBean does not support contains() 
> 
> 
> DynaBean interface declares contains(). 
> 
> Is there any plan for implementing contains() for WrapDynaBean 
> implementation? 
> Supposing that it would check the property via instanceof X and recurse if

> it 
> is a List, Map, Collection, DynaBean, etc. ? 
> 

Best way to deal with that would be an enhancement requests against 
commons-beanutils: 

  http://nagoya.apache.org/bugzilla/ <http://nagoya.apache.org/bugzilla/>  

and/or discussion on [EMAIL PROTECTED], since it's now a 
Commons package. 

> (I love beanutils, btw) 

Me too :-). 

> 
> -Rand 

Craig McClanahan 

--------------------------------------------------------------------- 
To unsubscribe, e-mail: [EMAIL PROTECTED] 
For additional commands, e-mail: [EMAIL PROTECTED] 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to