Hi,
> First sorry for this late reply, the mail strangely went out of my radar.
> I cannot give you an exact date for iPOJO 2.0. My goal is to release iPOJO
> 2.0 in 2011 (June is my first target).
>
> Right now, I'm collecting requirements, and ideas and starting to write that
> down. For sure, inheritance will be part of the new release as well as new
> handlers such as a kind of JPA handler... I also want to reduce the
> complexity of some mechanisms as the 'component type type' definition.
Well then maybe I should supply some of the things we came up with
when we were starting to get to grips with ipojo. Note that these
should not be considered criticisms as such - just things that didn't
behave as expected :)
* There is lots of name collisions between annotations which make the
use of them painful at best. For example @Property could either be
associated with jmx handler or it could be a config property. Why not
just have annotations named @ConfigProperty and @JmxProperty instead?
Much easier for end user as don't need to fully qualify everything.
There is also namespace collisions between annotations and classes
(i.e. @Publisher vs Publisher) which means more ugly fully qualified
names (why not rename the annotation to something like @Publishes or
similar.
* Non-java ish names seem to be scattered through the annotations. Why
have data_key rather than the more javaish dataKey. ie.
- @Subscriber.data_key
- @Subscriber.data_type
- @Publisher.data_key
- @Publisher.data_type
- @Component.factory_method
* Annotations on parent classes ignored!
* Why can't you set static service properties via annotations that are
not mirrored in fields? (Not sure if you can do this via xml). I could
easily imagine extending the @Provides annotation such as
@Provides{ specifications = {Foo.class},
properties = {...@serviceproperty{name="x",
value="1"},@ServiceProperty{name="y", value="2"}}} )
* Why not inject BundleContext via @Require?
* Why does not validation of annotations occur until runtime? If you
use annotation and refer to a method that does not exist it should
fail at build time! Likewise if you annotate a method that does not
have expected parameter types
* @Update annotated methods should not require a Dictionary parameter
- especially if all expected fields configured by @Property before
hand.
* @Provides have to be parent classes or interfaces not the class
itself ... seems like an arbitrary decision???
Anyhoo - thats all that is on this list. Other than the above iPojo
has worked a charm. We were planning on having a custom set of
annotations that fit more with our expectations and generated the
appropriate xml .
--
Cheers,
Peter Donald
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
