January 2013 - forge-issues - Jboss List Archives

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

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-773?page=com.atlassian.jira.plugin.... ] 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

11 years, 3 months

1
0
0 / 0

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

by John Franey (JIRA)

[ https://issues.jboss.org/browse/FORGE-773?page=com.atlassian.jira.plugin.... ] John Franey commented on FORGE-773: ----------------------------------- You are correct. The reflection part is not hard. I've done it mostly already. I implemented JavaClass using reflection. Method, Field, etc... also. URLClassloader can be used to load all the project's dependency jars. I don't think that is big either. Of course I wonder what the response time will be like. I think the big change is for ScaffoldPlugin to be changed so generateFromEntity takes a class name as string, not a JavaResource, alleviating ShellImpl from making the choice to get a class or a java resource; the plugin will find either the class on the dependency path or the java resource; and for Dependency plugin to give over a list of the compile time dependencies of the project. Are these kinds of changes to the forge system acceptable? > 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

11 years, 3 months

1
0
0 / 0

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

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-773?page=com.atlassian.jira.plugin.... ] Lincoln Baxter III commented on FORGE-773: ------------------------------------------ Yes, this would be a very nice thing to fix. I think in order to do this, we would need to classload the entire project, then use Java Reflection to handle this. It's certainly possible, but a big endeavor. Thoughts? > 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (FORGE-214) Plugin constraints should apply to commands (at a more granular level)

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-214?page=com.atlassian.jira.plugin.... ] Lincoln Baxter III closed FORGE-214. ------------------------------------ Fix Version/s: (was: 2.0.0.Alpha1) Resolution: Won't Fix No longer applies since Forge 2 changes how this works entirely. > Plugin constraints should apply to commands (at a more granular level) > ---------------------------------------------------------------------- > > Key: FORGE-214 > URL: https://issues.jboss.org/browse/FORGE-214 > Project: Forge > Issue Type: Feature Request > Components: Plugin API > Affects Versions: 1.0.0.Alpha1 > Reporter: Lincoln Baxter III > > @RequiresFacet > @RequiresProject > @RequiresPackagingType > ... etc > Should all be able to apply to individual commands, not just Plugins at the class level. -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (FORGE-291) Contextual injection of Completion Proposals

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-291?page=com.atlassian.jira.plugin.... ] Lincoln Baxter III closed FORGE-291. ------------------------------------ Assignee: Lincoln Baxter III Resolution: Done Done. This can be accomplished simply by asking the current input for completion proposals. Injection is no longer required. > Contextual injection of Completion Proposals > -------------------------------------------- > > Key: FORGE-291 > URL: https://issues.jboss.org/browse/FORGE-291 > Project: Forge > Issue Type: Feature Request > Components: Shell > Reporter: Max Rydahl Andersen > Assignee: Lincoln Baxter III > Fix For: 2.0.0.Alpha1 > > > from irc: > "just wondering if that shouldn't be something like a @Current CompletionProposals getProposals(String prompt) on Commands ? > a producer method for possible completion values." -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (FORGE-597) Completer API should allow inter-dependent completion proposals for command arguments

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-597?page=com.atlassian.jira.plugin.... ] Lincoln Baxter III closed FORGE-597. ------------------------------------ Assignee: Lincoln Baxter III Resolution: Done Done, see UICompleter API on UIInput > Completer API should allow inter-dependent completion proposals for command arguments > ------------------------------------------------------------------------------------- > > Key: FORGE-597 > URL: https://issues.jboss.org/browse/FORGE-597 > Project: Forge > Issue Type: Feature Request > Components: Plugin API > Affects Versions: 1.0.5.Final > Reporter: Lincoln Baxter III > Assignee: Lincoln Baxter III > Fix For: 2.0.0.Alpha1 > > > For example > "jdbc setup --database MYSQL" > (future options and completable values should be constrained to rules defined by the case where MYSQL was selected as a database. these options and values would be different, for example, if the user had selected --database POSTGRESQL) -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (FORGE-753) Generate Atom feed for the Website for JBoss Weekly Editorial

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-753?page=com.atlassian.jira.plugin.... ] Lincoln Baxter III closed FORGE-753. ------------------------------------ Resolution: Done Done, nice work! > Generate Atom feed for the Website for JBoss Weekly Editorial > ------------------------------------------------------------- > > Key: FORGE-753 > URL: https://issues.jboss.org/browse/FORGE-753 > Project: Forge > Issue Type: Enhancement > Components: Website > Affects Versions: 1.2.0.Final > Reporter: George Gastaldi > Assignee: George Gastaldi > Fix For: 1.2.1.Final > > > From Kevin Conner email about the JBoss Weekly Editorial: > {quote} > We take the information from the project feeds, either from those listed through http://planet.jboss.org/list and/or from http://planet.jboss.org/feed/all. If you can make sure that your postings show up on those feeds then we will see the announcements and be able to include them. > {quote} -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (FORGE-753) Generate Atom feed for the Website for JBoss Weekly Editorial

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-753?page=com.atlassian.jira.plugin.... ] Lincoln Baxter III reassigned FORGE-753: ---------------------------------------- Assignee: George Gastaldi > Generate Atom feed for the Website for JBoss Weekly Editorial > ------------------------------------------------------------- > > Key: FORGE-753 > URL: https://issues.jboss.org/browse/FORGE-753 > Project: Forge > Issue Type: Enhancement > Components: Website > Affects Versions: 1.2.0.Final > Reporter: George Gastaldi > Assignee: George Gastaldi > Fix For: 1.2.1.Final > > > From Kevin Conner email about the JBoss Weekly Editorial: > {quote} > We take the information from the project feeds, either from those listed through http://planet.jboss.org/list and/or from http://planet.jboss.org/feed/all. If you can make sure that your postings show up on those feeds then we will see the announcements and be able to include them. > {quote} -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (FORGE-719) Design an user interface API for addons

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-719?page=com.atlassian.jira.plugin.... ] Lincoln Baxter III reassigned FORGE-719: ---------------------------------------- Assignee: Lincoln Baxter III > Design an user interface API for addons > --------------------------------------- > > Key: FORGE-719 > URL: https://issues.jboss.org/browse/FORGE-719 > Project: Forge > Issue Type: Story > Components: Brainstorming > Reporter: George Gastaldi > Assignee: Lincoln Baxter III > Fix For: 2.0.0.Alpha1 > > > Requirements: > - It must be usable in a Shell UI > - It should be usable in a Visual UI (SWT, Swing) > - It must be typesafe, therefore allowing the use of complex types. > Let's use this JIRA to brainstorm about it. -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (FORGE-719) Design an user interface API for addons

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-719?page=com.atlassian.jira.plugin.... ] Lincoln Baxter III closed FORGE-719. ------------------------------------ Resolution: Done Done. Still improving but mostly there. > Design an user interface API for addons > --------------------------------------- > > Key: FORGE-719 > URL: https://issues.jboss.org/browse/FORGE-719 > Project: Forge > Issue Type: Story > Components: Brainstorming > Reporter: George Gastaldi > Assignee: Lincoln Baxter III > Fix For: 2.0.0.Alpha1 > > > Requirements: > - It must be usable in a Shell UI > - It should be usable in a Visual UI (SWT, Swing) > - It must be typesafe, therefore allowing the use of complex types. > Let's use this JIRA to brainstorm about it. -- 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

11 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

forge-issues January 2013