[clazz] what's next?

[Dmitri Plotnikov <dp...@yahoo.com>]

I think we need to decide what to do with clazz next.

If you are just joining the discussion, here's a quick recap. Clazz is
a sandbox project that basically addresses three needs:

  a) a new generation of introspection, richer than the JDK version,
more flexible and easier to customize

  b) support for runtime types created programmatically, or from an XML
description etc, used primarily for scripting. The clazz APIs hide the
difference between these "virtual" types and "real" ones based on
reflection.

  c) support for attributes, which are arbitrary bits of meta-data
associated with such features as class, property and method.  See
XDoclet for many examples of how attributes are used.


At this point we have a relatively comprehensive cut of clazz. See
http://jakarta.apache.org/commons/sandbox/clazz/overview.html

I think we are ready for the first attempts of integration with other
projects.

Here are some ideas:

1. Integrate with XDoclet for attribute access.  This is technically
easy, just need to understand the license issue: XDoclet is not under
Apache license - very similar, but not exactly the same, I compared.

2. Integrate with BSF.  BSF is using the traditional Introspector, it
would not be a big deal to upgrade it to use Clazz.

3. BeanUtils.  Should be quite easy to add Clazz support to BeanUtils.

4. Integrate with JXPath.  Trivial - we'll just need to write an
adapter.

5. Integrate with Jexl. Jexl uses the same mechanism as Velocity,
namely Uberspect.  We need Geir's input on how to integrate with it. We
could try to wrap clazz into Uberspect APIs, or bring additional
features of Uberspect into clazz and then replace Uberspect with clazz
altogether.

6. Integrate with Betwixt.  Betwixt has its own introspection mechanism
similar to that of clazz.  Just like with Jexl we have a couple of
options and need the Betwixt team's input.

7. Integrate with BCEL. We could try to compile the clazz runtime data.


Questions:

* Which of these and what others are worth pursuing?

* How do we prioritize them?

* With most of these we will need to modify existing established
projects.  How much of a problem will this be?



- Dmitri

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

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

Re: [clazz] what's next?

[Stephen Colebourne <sc...@btopenworld.com>]

From: "Dmitri Plotnikov" <dp...@yahoo.com>
> I think we need to decide what to do with clazz next.
Somehow I need to find the time to stufy the current API in detail again. At
the moment I have a sense that it might be too complex (but it may not be
possible to simplify...)

> I think we are ready for the first attempts of integration with other
> projects.
>
> Here are some ideas:
>
> 3. BeanUtils.  Should be quite easy to add Clazz support to BeanUtils.
I suggest we create a BeanUtils like API within Clazz as a simple front end
rather than changing BeanUtils.

> 5. Integrate with Jexl. Jexl uses the same mechanism as Velocity,
> namely Uberspect.  We need Geir's input on how to integrate with it. We
> could try to wrap clazz into Uberspect APIs, or bring additional
> features of Uberspect into clazz and then replace Uberspect with clazz
> altogether.
I know of Uberspect but I've not looked at it. Some kind of interoperability
with it is probably essential.

> 6. Integrate with Betwixt.  Betwixt has its own introspection mechanism
> similar to that of clazz.  Just like with Jexl we have a couple of
> options and need the Betwixt team's input.
Here it would be nice to join the betwixt refactoring effort thats about to
start and get betwixt built around clazz. It would make it a hell of a lot
more powerful.

If we start with BeanUtils clone within clazz it can be merged back into the
real [beanutil] later if thats appropriate. [betwixt] on the other hand
would be nice to integrate directly with...

Stephen


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