[forge-dev] reflection to access classes in project dependencies

[John Franey]

My motivation for this email is to satisfy FORGE-773.  However, this is
also related to FORGE-563 and FORGE-424, and resolution could enable other
features.

I have written a prototype:
1) an implementation of the forge java api interfaces which delegates to
java's reflection, offering a read only perspective of java components.
2) a forge module, currently a facet, to search for a given binary class in
the project's dependencies and returns the result wrapped in the above
delegate.

These are demonstrable in a unit test.

My dilemma now is how to integrate these into the forge project.  There are
a few different areas, but I'll start with this:


For some callers, a java class is a java class, whether it originates as
source code (from the current forge project) or is a class from the
dependency set.  For example, scaffolding primarily is a read only
operation.  In this use case, it would be simpler for these clients to have
a single interface to resolve classes because whether a class is source or
binary is not relevant to the use case.

On the other hand, there is a set of classes in a user's project that are
modifiable.  In these cases, a java class is not a java class.  Forge
components might want the distinction somehow.  There ought the be some
distinction of which class is modifiable and which is not.

Naively, I took the first thinking that the existing forge java model would
be adequate.  To have separate java api for read-only and read-write java
model objects seems a fundamental addition to the java model which requires
much more effort.  In absence of such a model, I though to implement
'no-op' for those code changing methods  (e.g., Named.setName() would be
inert).  I assumed that forge component that change source code would have
necessary context to know when it is operating on a source code module,
avoiding attempts to modify a binary class.

So, I'm looking for discussion and consensus on the above.  Any thoughts?

Regards,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20130214/0b73794d/attachment.html