[forge-issues] [JBoss JIRA] (FORGE-773) entities for scaffold could be binary, not source

[Lincoln Baxter III (JIRA)]

    [ https://issues.jboss.org/browse/FORGE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12751738#comment-12751738 ] 

Lincoln Baxter III commented on FORGE-773:
------------------------------------------

Hey John!

That's excellent. A working prototype gives me hope.

As far as changing the scaffold plugin, it's fine to add to the API, but we can't remove or change anything that we have right now. So it's possible we could simply add another option / command in the ScaffoldPlugin that would kick things off using your reflection loading system.

An issue that might be related here is the following: https://issues.jboss.org/browse/FORGE-563

Since you are already building an implementation of the JavaClass API on top of Reflection, would it be conceivable to use that information to create a type of cache for each object inspected in this way? The index could be parsed on-demand, and enable retrieving the information needed for the scaffold. It would also enable wildcard expansion in the JavaParser itself -> https://issues.jboss.org/browse/FORGE-424

Thoughts? Would enhancing the scaffold provider meet your goals?
                
> entities for scaffold could be binary, not source
> -------------------------------------------------
>
>                 Key: FORGE-773
>                 URL: https://issues.jboss.org/browse/FORGE-773
>             Project: Forge
>          Issue Type: Feature Request
>            Reporter: John Franey
>
> I have already a jar file full of JPA entity classes, built by another project.  To generate scaffold on forge 1.2.1, I create a forge project and unpack the source code of the jpa project into the forge project, then I can run the scaffold.
> I'd like a parameter to accept a dependency and a package or class name: scaffold from-entity [groupId:artifactId:]entity-name
> if groupId:artifactId were provided, then the plugin would find that dependency, open that jar and look for the class(es) with that name, convert those to JavaClass implementation that wraps a java.lang.Class and call the scaffold provider.
> FacesScaffold facet operates on JavaClass.  Thanks to architects that made this an interface, its not hard to implement as a wrapper to java.lang.Class; same for other interfaces in forge's java api.  In other words, using these wrappers, FacesScaffold can operate on java class data.
> However, there seem to be a few roadblocks for me:
> # The ScaffoldPlugin can accept a JavaResource, a source file.  There is no method on the plugin to accept a JavaClass  Is it possible to override, perhaps by defining a brand new plugin that derives from ScaffoldPlugin and provides the method that accepts a JavaClass?
> # The ShellImpl has a fixed conversion from string to JavaResource.  Is it possible to provide a custom conversion in order for the shell to call a plugin method with a JavaCLass parameter?
> # The Dependency facet does not have a method that gives access to the jar file of the dependency.  I'm not confident that getSystemPath() returns the path to the actual jar file.  This data derives from the apache Maven's method Dependency.getSystemPath() which has a javadoc saying: "don't call this method."  I think Eclipse and maven have different dependency resolution mechanisms, so this facet would be different in each.
> Have I read the forge code wrong?  Is there a roadmap that navigates these issues?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira