commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rune Johannesen <>
Subject RE: [beanutils] new code submission
Date Tue, 13 May 2003 13:47:58 GMT
I think adding optional packages is the right thing to do to allow the
BeanUtils project to grow into new, interesting areas.


-----Original Message-----
From: robert burrell donkin [] 
Sent: 12 May 2003 21:58
To: Jakarta Commons Developers List
Subject: Re: [beanutils] new code submission

sounds interesting but i think that adding dependencies is something that 
probably needs thinking about. adding these dependencies to the core would 
probably be pretty unpopular with some of the projects that use beanutils.

this issue is a little wider than just beanutils. there are a couple of 
regex matcher implementations that i'd like to introduce into digester but 
i don't want to introduce a core dependency into digester for the 
libraries that would be used.

i was wondering whether we could go down the ant route and split into core 
and optional. the stuff will extra dependencies could go under a separate 
package which would depend on the core stuff but on which the core stuff 
could not depend. so for beanutils, this would mean creating a org.apache.
commons.beanutils.optional package which would be build separately from 
the core stuff.

what do people think about this idea?

- robert

On Friday, May 9, 2003, at 03:18 PM, Henri Yandell wrote:

> I'd like to submit/commit some code to beanutils:
> BeanTester, a JUnit extension which uses BeanUtils to test a JavaBean. 
> Usage is something like:
> BeanTester bt = new BeanTester(MyBean.class);
> bt.addTest( "name", new Object[] { "Fred", "Jim", null, "" } ); 
> bt.testProperties();
> or     new BeanTester(MyBean.class).inferTests().testProperties();
> SimpleBeanProxy. This may be in BeanUtils but I don't see it. Also it 
> infers JDK 1.3 dependency upon BeanUtils. Given a Bean interface, it 
> provides a basic implementation sitting on top of a HashMap. It would 
> additionally support DynaBean.
> RandomBeanMaker. This creates Random beans. It would need a supporting 
> Random library with a similar structure to the Convert one. It uses 
> reflection to create beans from class structures and proxying to 
> create beans when an interface type exists.
> BeanToString. This is one I'd assume BeanUtils has, but I don't see 
> it. It would create a toString under a certain scheme to show a bean's 
> values.
> That's the list for the moment :)
> Hen
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message