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