[JBoss JIRA] (FORGE-368) Return list of properties based on higher-level understanding
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-368?page=com.atlassian.jira.plugin.... ]
George Gastaldi updated FORGE-368:
----------------------------------
Fix Version/s: 2.0.0.Alpha5
(was: 2.0.0.Alpha4)
> Return list of properties based on higher-level understanding
> -------------------------------------------------------------
>
> Key: FORGE-368
> URL: https://issues.jboss.org/browse/FORGE-368
> Project: Forge
> Issue Type: Feature Request
> Components: Parsers / File Manipulation
> Reporter: Richard Kennard
> Fix For: 2.0.0.Alpha5
>
>
> Hi guys,
> As I understand it, Forge has an understanding of your project that transcends Java's own understanding. So for example if I say...
> field string --named foo
> ...Forge knows I'm creating a property, and it creates getters and setters for that property. But later if I do...
> org.jboss.forge.parser.java.JavaClass.getMethods()
> ...then I get back just normal methods. I'll have to check their signature for 'get' or 'set' to see if they're properties. Equally if I do...
> org.jboss.forge.parser.java.JavaClass.getFields()
> ...I get back just normal fields. I don't know if these are property fields (and if so, what their corresponding getter/setter methods are) or whether they're just internal fields (and should be ignored).
> Is there a recommended way to 'get back out' the list of properties for a class? Something that tells me a) the field; b) the getter; c) the setter?
> If it helps, for now I am using a rough implementation at: https://github.com/kennardconsulting/forge/blob/master/scaffold-metawidge...
--
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
12 years, 10 months
[JBoss JIRA] (FORGE-331) Get online help from plugin's javadoc
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-331?page=com.atlassian.jira.plugin.... ]
George Gastaldi updated FORGE-331:
----------------------------------
Fix Version/s: 2.0.0.Alpha5
(was: 2.0.0.Alpha4)
> Get online help from plugin's javadoc
> -------------------------------------
>
> Key: FORGE-331
> URL: https://issues.jboss.org/browse/FORGE-331
> Project: Forge
> Issue Type: Feature Request
> Components: Plugin API
> Reporter: Jonathan Fuerth
> Priority: Minor
> Fix For: 2.0.0.Alpha5
>
>
> IDEs already have lots of great tooling to help write good javadoc and keep it neatly formatted and up to date. It would be excellent if forge's source of help text for plugins came straight from the javadoc. This could be done either via a doclet that operates on the Java source code, or by scraping the output of the default doclet (like Eclipse will do if you attach generated JavaDoc rather than library source code).
> Lowering the barrier to providing high-quality documentation should help encourage plugin authors to provide good help, and in turn that should help everyone pick up and learn Forge faster.
--
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
12 years, 10 months
[JBoss JIRA] (FORGE-273) Create project from Maven archetype
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-273?page=com.atlassian.jira.plugin.... ]
George Gastaldi updated FORGE-273:
----------------------------------
Fix Version/s: 2.0.0.Alpha5
(was: 2.0.0.Alpha4)
> Create project from Maven archetype
> -----------------------------------
>
> Key: FORGE-273
> URL: https://issues.jboss.org/browse/FORGE-273
> Project: Forge
> Issue Type: Feature Request
> Components: Blessed Plugins
> Reporter: Dan Allen
> Assignee: Rodney Russ
> Priority: Minor
> Fix For: 2.0.0.Alpha5
>
>
> Since the catalog of Maven archetypes is substantial, and the archetype plugin interface is so abysmal, Forge could benefit from being a stand-in replacement to archetype:generate. A command in Forge to create a new project from a Maven archetype would certainly offer a nice complement to the more basic "new-project" command. It could just be an additional flag to the new-project command, such as:
> new-project --named MyProject --fromArchetype org.jboss.weld.archetypes:jboss-javaee6-webapp
> Using the interactive prompts, you may be able to provide a list of archetypes, perhaps w/ a filtering mechanism. You could also just do a best guess based on what's found in the catalog.
> new-project --named MyProject --fromArchetype jboss-javaee6-webapp
> You could just delegate to Maven by building up the "mvn archetype:generate" command from Forge. Long term we could consider emulating the archetype:generate plugin so as just to consume the projects that are out there already w/o any linkage to Maven.
--
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
12 years, 10 months
[JBoss JIRA] (FORGE-378) Add "environments" as a first class construct
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-378?page=com.atlassian.jira.plugin.... ]
George Gastaldi updated FORGE-378:
----------------------------------
Fix Version/s: 2.0.0.Alpha5
(was: 2.0.0.Alpha4)
> Add "environments" as a first class construct
> ---------------------------------------------
>
> Key: FORGE-378
> URL: https://issues.jboss.org/browse/FORGE-378
> Project: Forge
> Issue Type: Feature Request
> Components: UI - Shell, Usability
> Reporter: Pete Muir
> Fix For: 2.0.0.Alpha5
>
>
> For example:
> {code}
> set environment JBOSS_AS7 --version 7.1.0.Final
> {code}
> Where JBOSS_AS7 is a built in profile that contains necessary info on various versions of JBoss AS 7.
> For example, the persistence plugin could read from this, changing
> {code}
> persistence setup --provider HIBERNATE --container JBOSS_AS7
> {code}
> to
> {code}
> persistence setup
> {code}
> Or, when setting up CDI, this would remove the need to ask ask which API to use (always use the Java EE BOM with JBoss AS), and as the metadata builds, remove the need to ask the version of the spec BOM to use.
> Lot's of other places where this could provide better defaulting, or remove the need to ask questions.
> This also seems fairly consistent with the Forge approach - good understanding of the project in question.
--
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
12 years, 10 months
[JBoss JIRA] (FORGE-379) Add user profiles
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-379?page=com.atlassian.jira.plugin.... ]
George Gastaldi updated FORGE-379:
----------------------------------
Fix Version/s: 2.0.0.Alpha5
(was: 2.0.0.Alpha4)
> Add user profiles
> -----------------
>
> Key: FORGE-379
> URL: https://issues.jboss.org/browse/FORGE-379
> Project: Forge
> Issue Type: Feature Request
> Components: Usability
> Affects Versions: 1.0.0.Beta3
> Reporter: Pete Muir
> Fix For: 2.0.0.Alpha5
>
>
> At the moment Forge assumes that every user needs the same level of hand-holding. This means that advanced users are shortchanged (as they want more control) and newbies can get lost. Introducing a number of user profiles (e.g. newbie, intermediate, god) could help here. For example, if in newbie mode, the faces plugin wouldn't ask if you wanted to change from jar -> war packaging, assuming that the person does...
--
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
12 years, 10 months
[JBoss JIRA] (FORGE-424) JavaParser does not understand wildcard imports like "javax.persistence.*"
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-424?page=com.atlassian.jira.plugin.... ]
George Gastaldi updated FORGE-424:
----------------------------------
Fix Version/s: 2.0.0.Alpha5
(was: 2.0.0.Alpha4)
> JavaParser does not understand wildcard imports like "javax.persistence.*"
> --------------------------------------------------------------------------
>
> Key: FORGE-424
> URL: https://issues.jboss.org/browse/FORGE-424
> Project: Forge
> Issue Type: Technical task
> Components: Parsers / File Manipulation
> Affects Versions: 1.1.0.Final
> Reporter: Lincoln Baxter III
> Fix For: 2.0.0.Alpha5
>
>
> The JavaParser Annotation.getQualifiedName() will return "Column" instead of "javax.persistence.Column" for the following example class scenario. It should be able to understand the wildcard, given the proper metadata:
> {code}package demo.entities;
> import javax.persistence.*;
> @Entity
> public class Contact implements java.io.Serializable {
> @Id
> private @GeneratedValue(strategy = GenerationType.AUTO)
> @Column(name = "id", updatable = false, nullable = false)
> Long id = null;
> @Version
> private @Column(name = "version")
> int version = 0;
> public Long getId() {
> return this.id;
> }
> public void setId(final Long id) {
> this.id = id;
> }
> public int getVersion() {
> return this.version;
> }
> public void setVersion(final int version) {
> this.version = version;
> }
> @Override
> public boolean equals(Object that) {
> if (this == that) {
> return true;
> }
> if (that == null) {
> return false;
> }
> if (getClass() != that.getClass()) {
> return false;
> }
> if (id != null) {
> return id.equals(((Contact) that).id);
> }
> return super.equals(that);
> }
> @Override
> public int hashCode() {
> if (id != null) {
> return id.hashCode();
> }
> return super.hashCode();
> }
> private String name;
> public String getName() {
> return this.name;
> }
> public void setName(final String name) {
> this.name = name;
> }
> public String toString() {
> return "" + name;
> }
> }{code}
--
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
12 years, 10 months
[JBoss JIRA] (FORGE-563) Create a class lookup index
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-563?page=com.atlassian.jira.plugin.... ]
George Gastaldi updated FORGE-563:
----------------------------------
Fix Version/s: 2.0.0.Alpha5
(was: 2.0.0.Alpha4)
> Create a class lookup index
> ---------------------------
>
> Key: FORGE-563
> URL: https://issues.jboss.org/browse/FORGE-563
> Project: Forge
> Issue Type: Feature Request
> Components: Maven Integration
> Affects Versions: 1.0.4.Final
> Reporter: Jason Porter
> Assignee: George Gastaldi
> Fix For: 2.0.0.Alpha5
>
>
> We need to support an index of classes and dependencies which contain them.
> This would allow us to do wildcard expansion, and also allow facets to depend on a class, not a specific dependency. I believe Lincoln has the information about wildcard support, for the facet dependency idea my thoughts are an index like this would allow a facet to declare a class, or collection of classes, which it requires to function. For example the faces facet could depend on FacesContext, or PhaseListener or some other class. When a facet checks to see if a project has the dependencies it could match multiple jars instead one specific jar. Again in the faces example it could match Mojarra, MyFaces, JBoss spec jars, Geromino spec jars, etc.
> We could keep a local cache and add to it, we could also have an online cache available which users could push to and also merge into their local cache.
--
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
12 years, 10 months