I forgot an important factor:
in the current API are methods that do not make any
sense for my use case. Especially:

       void set(Object instance, Object value);

on ClazzProperty is absolutely undefined, if I have
loaded the Clazz from an XML model file. Because
there is (yet?) no settable Property. 
So to make the meta model useful for me, 
reflection specific code would have to be moved down to the 
ReflectionProperty. I am not sure that this
solution suits the needs of anyone besides myself.


Victor


> Dmitri
> 
> Dmitri wrote:
> > Victor Volle wrote:
> > > PS: I am hesitating to offer my help, yet (besides criticism :-))
> > > because I am still not sure that I can use it for my own project
> > > and I would like to wait for the "dust to settle".
> > Critisizm is in fact extremely valuable help.  What I want to know
> > is what you think needs to be done in clazz for it to be useful for your
> > project.
> 
> What I am working at is a simple but generic code generator.
> It creates a model from different sources (reflection, XML, XMI,
> direct integration with IDEs and so on). 
> So I could use clazz in to ways:
>    1) Simply use its advanced reflection features to load
>        my own meta model AND use it when loading from
>        XML (where I currently use my own hack of BeanUtils code)
>    2) Additionally reuse the clazz meta model but then I would
>        have to add a whole bunch of things: Packages as model
>        elements (because they meight have Attributes), 
>        InnerClasses, CompilationUnits (for Import handling
>        and type resolving (currently integrated in my MetaClass)),
>        MetaTypes (again for (lazy) type resolving). 
> 
> I am quite sure that I will use clazz for the first purpose,
> because I am convinced that clazz is on a good way. 
> But since the focus of clazz is not (yet) the meta model
> but the advanced reflection, I am not sure that the different
> use cases could or should be aligned. 
> 
> Victor
> 
> 
> 
> --
> To unsubscribe, e-mail:  
> <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:commons-dev-help@;jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>

Reply via email to