Hi Benedikt, having test dependencies is fine, the "restriction" is just for the main distribution.
looking forward to apply more from you! alles gute, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Feb 8, 2012 at 7:48 PM, Benedikt Ritter <b...@systemoutprintln.de> wrote: > Hey Simo, > > no hurry! :-) > I'm just figuring how to implement the tests for populate(). For example I > want do do something like (properties is an empty map in this case): > > @Test > public void populateEmpty() > throws Exception > { > on( target ).populate( properties ); > assertTrue( target.equals( new TestBean() ) ); > } > > The problem is, that equals is not implemented on TestBean. I wanted to > implement it myself, but that would take a lot of boilerplate code (checking > if properties are null, before invoking equals on them etc.) The nicest way > would be use EqualsBuilder from commons.lang. Can we add lang as a > dependency in the test scope? > > If not, what is your recommendation for implementing the populateEmpty test? > I could implement asserts for each and every property, but again that would > be a lot of boilerplate, that obscures the test. An alternative would be to > write assertEquals(TestBean expected, TestBean actual) that has all that > stuff in it. > > Regards, > Benedikt > > > Am 07.02.2012 20:34, schrieb Simone Tripodi: > >> Excellent :) >> >> I'll take care to apply your patches tomorrow, unfortunately I have >> still some task to complete today :/ >> >> alles gute, >> -Simo >> >> http://people.apache.org/~simonetripodi/ >> http://simonetripodi.livejournal.com/ >> http://twitter.com/simonetripodi >> http://www.99soft.org/ >> >> >> >> On Tue, Feb 7, 2012 at 5:56 PM, Benedikt Ritter >> <b...@systemoutprintln.de> wrote: >>> >>> Am 07.02.2012 16:19, schrieb Simone Tripodi: >>> >>>> Hola, >>>> >>>>> I've read your email twice yesterday evening and again today. Sorry, >>>>> but >>>>> I >>>>> honestly do not understand, what you are talking about :-) >>>>> I assume, that you are referring to my comment on svn commit r1241124 >>>>> on >>>>> moving Assertions to a new package?! (rather then the behavior of >>>>> populate()) >>>> >>>> >>>> >>>> yes indeed, I replied to your last message >>>> >>>>> >>>>> If so, I would say, yes you're right when saying, that exposing the >>>>> minimal >>>>> possible API is a good thing. At least it is a good thing for users. >>>>> OTOH >>>>> for developers it is more complicated to understand the code if >>>>> everything >>>>> is contained in just one package. >>>>> >>>> >>>> :| complicated?!? do you see how small is the actual the codebase? >>>> have you never raw Hibernate or Spring2.X source code? :) >>>> >>>>> >>>>> I think we can live with an internal package. Everybody should know, >>>>> that >>>>> it >>>>> is not intended to be used outside the library. >>>>> A nice thing about OSGi Bundles is that you can explicitly specify >>>>> which >>>>> packages should be visible to other bundles. Looking at the generated >>>>> MANIFEST after calling mvn clean test, I can see that the internal >>>>> package >>>>> will be exported to. >>>>> Is there any possibility to configure the build, so that it generates a >>>>> MANIFEST, that does not export the internal package? >>>>> >>>> >>>> yes, there are few configuration properties that have to be set, see >>>> the parent pom if you're interested on providing the patch ;) >>> >>> >>> >>> done ;) >>> >>> >>>> >>>> alles gute! >>>> -Simo >>>> >>>> http://people.apache.org/~simonetripodi/ >>>> http://simonetripodi.livejournal.com/ >>>> http://twitter.com/simonetripodi >>>> http://www.99soft.org/ >>>> >>>> >>>> >>>> On Tue, Feb 7, 2012 at 3:47 PM, Benedikt Ritter >>>> <b...@systemoutprintln.de> wrote: >>>>> >>>>> >>>>> Hi Simo, >>>>> >>>> >>>>> >>>>> If so, I would say, yes you're right when saying, that exposing the >>>>> minimal >>>>> possible API is a good thing. At least it is a good thing for users. >>>>> OTOH >>>>> for developers it is more complicated to understand the code if >>>>> everything >>>>> is contained in just one package. >>>>> >>>>> I think we can live with an internal package. Everybody should know, >>>>> that >>>>> it >>>>> is not intended to be used outside the library. >>>>> A nice thing about OSGi Bundles is that you can explicitly specify >>>>> which >>>>> packages should be visible to other bundles. Looking at the generated >>>>> MANIFEST after calling mvn clean test, I can see that the internal >>>>> package >>>>> will be exported to. >>>>> Is there any possibility to configure the build, so that it generates a >>>>> MANIFEST, that does not export the internal package? >>>>> >>>>> Regards, >>>>> Benedikt >>>>> >>>>> >>>>> Am 06.02.2012 21:31, schrieb Simone Tripodi: >>>>> >>>>>> anyway, just for the record: the reason is just because I introduced a >>>>>> new package that needs to access to same methods, otherwise there >>>>>> wouldn't have been any reason to expose it. >>>>>> do you see a valid motivation? >>>>>> -Simo >>>>>> >>>>>> http://people.apache.org/~simonetripodi/ >>>>>> http://simonetripodi.livejournal.com/ >>>>>> http://twitter.com/simonetripodi >>>>>> http://www.99soft.org/ >>>>>> >>>>>> >>>>>> >>>>>> On Sun, Feb 5, 2012 at 9:27 PM, Simone >>>>>> Tripodi<simonetrip...@apache.org> >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Benedikt, >>>>>>> >>>>>>> let's keep the `skip readonly property` behavior ATM, that is >>>>>>> something BeanUtils users are already used to. >>>>>>> Same for null key, skip them. >>>>>>> >>>>>>> Moreover, iterate over properties.entrySet()[1] instead of keySet(). >>>>>>> >>>>>>> all the best, >>>>>>> -Simo >>>>>>> >>>>>>> [1] >>>>>>> >>>>>>> http://docs.oracle.com/javase/6/docs/api/java/util/Map.html#entrySet() >>>>>>> >>>>>>> http://people.apache.org/~simonetripodi/ >>>>>>> http://simonetripodi.livejournal.com/ >>>>>>> http://twitter.com/simonetripodi >>>>>>> http://www.99soft.org/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, Feb 5, 2012 at 2:50 PM, Benedikt Ritter >>>>>>> <b...@systemoutprintln.de> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'm working on populate and tried to stick to the convention of >>>>>>>> throwing >>>>>>>> exceptions for illegal inputs: >>>>>>>> >>>>>>>> * passing null will cause NullPointerException >>>>>>>> * passing an empty Map will have no effect >>>>>>>> * passing a Map with null keys will cause NullPointerException >>>>>>>> * passing a Map with null values will set those properties to null >>>>>>>> * passing a Map with null values for primitive properties will cause >>>>>>>> a >>>>>>>> IllegalArgumentException >>>>>>>> >>>>>>>> But this is in contrast to BeanUtils1. Looking at the implementation >>>>>>>> of >>>>>>>> BeanUtilsBean.populate() I can see that: >>>>>>>> >>>>>>>> * passing null does nothing >>>>>>>> * passing an empty map does nothing >>>>>>>> * Null keys will be ignored >>>>>>>> >>>>>>>> Now I think, that throwing exceptions is better than just accepting >>>>>>>> every >>>>>>>> value. Am I right with that? >>>>>>>> >>>>>>>> Also, I'm wondering how populate should behave if a value for a read >>>>>>>> only >>>>>>>> property is passed. Looking at BeanUtils1 I've seen that >>>>>>>> BeanUtilsBean.populate() just ignores those properties (line 974 in >>>>>>>> BeanUtilsBean). >>>>>>>> Currently I've a pretty straight forward implementation: >>>>>>>> >>>>>>>> public void populate( Map<String, Object> properties ) throws >>>>>>>> IllegalAccessException, IllegalArgumentException, >>>>>>>> InvocationTargetException, >>>>>>>> NoSuchMethodException, IntrospectionException >>>>>>>> { >>>>>>>> checkNotNull( properties, "Can not populate null!" ); >>>>>>>> for ( String propertyName : properties.keySet() ) >>>>>>>> { >>>>>>>> checkNotNull( propertyName, "Null is not an allowed property >>>>>>>> key!" ); >>>>>>>> setProperty( propertyName ).withValue( properties.get( >>>>>>>> propertyName ) >>>>>>>> ); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> Calling setProperty will result in a NoSuchMethodException been >>>>>>>> thrown, >>>>>>>> if >>>>>>>> there is no setter method for a given key. I thing that is >>>>>>>> convenient >>>>>>>> looking at the overall design of BeanUtils2. >>>>>>>> >>>>>>>> To sum this all up: How should populate() behave, if the property >>>>>>>> for >>>>>>>> a >>>>>>>> given key is read only? >>>>>>>> >>>>>>>> Regards, >>>>>>>> Benedikt >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
