Just a note/idea. Shame we're not still on Ant. We could have a system in which classes can be pulled out of cvs from other projects into the building project, package changed to a local one and the public removed.
When building a source dist, it would throw it in like that, and the build.xml for a source dist would not include the pull from cvs bit. We maintain 1 version. We distribute 2. Probably hacky and warped, but thought I'd throw it in. Hen On Thu, 6 May 2004, robert burrell donkin wrote: > > On 6 May 2004, at 22:38, Craig McClanahan wrote: > > robert burrell donkin wrote: > >> On 6 May 2004, at 21:28, Craig McClanahan wrote: > >>> robert burrell donkin wrote: > >> <snip> > >>>> 2 replace the references to FastHashMap with a private static > >>>> implementation. consider whether to replace this altogether. > >>> > >>> +1. Regarding replacement, I'm fine with any approach that lets us > >>> read from the collection without locking (which is the 99.9% use > >>> case for where the Fast* stuff is used in both BeanUtils and in > >>> Struts). In practice, nobody has reported a reproducible bug > >>> against the code in these classes, but I can certainly appreciate > >>> how difficult it would be to accomplish this. > >> > >> hmmm... > >> > >> if FastHashMap is used in struts as well as beanutils then maybe we > >> should retain this class in the source (as well as the other two)... > > > > It's used in Struts for purposes similar to where it's used in > > beanutils ... for mostly-read-only access to configuration > > collections. > > > > That's not really something that should drive a [beanutils] decision, > > though ... and this is all a temporary measure until we can deprecate > > the bad public API and fix it. I'm still fine with copying them. > > what's driving me is wanting to clean up the dependency issues for > downstream beanutils customers (such as struts). IMHO that struts needs > FastHashMap is a reasonable litmus test. it makes me inclined to think > that a copied version (packaged under org.apache.commons.collections) > should be included as part of the public API. (rather than a private > implementation.) > > >>>> 3 factor out a new bean-collections jar under > >>>> extras/bean-collections containing the (cool) implementations of > >>>> collections stuffs using beanutils bean-magic. > >>>> > >>> I'm not sure I'm parsing this sentence correctly. Does that mean we > >>> just put the ArrayStack and Buffer and Fast* classes being grabbed > >>> here, instead of in src/java? If so, +1. Otherwise, could you > >>> please explain further? > > <snip> > > >> have i explained this better now? > >> > > That makes much more sense ... thanks. I'm +1 on this idea. > > great > > >> or would it be easier for me to create a branch and commit stuff onto > >> that so that people can take a look... > >> > > HEAD branch is fine with me. > > HEAD it is then > > - robert > > > --------------------------------------------------------------------- > 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]
