July 2013 - forge-issues - Jboss List Archives

[JBoss JIRA] (FORGE-1031) Synchronize repository.yaml model with Forge's plugin installation model

by Lennart Jörelid (JIRA)

Lennart Jörelid created FORGE-1031: -------------------------------------- Summary: Synchronize repository.yaml model with Forge's plugin installation model Key: FORGE-1031 URL: https://issues.jboss.org/browse/FORGE-1031 Project: Forge Issue Type: Enhancement Components: Documentation, Plugin API, Plugin Repository Affects Versions: 1.3.3.Final Reporter: Lennart Jörelid Priority: Minor The repository.yaml file holds a Maven GAV to each Forge Plugin. However, Forge's resolution only retrieves the latest/HEAD revision of a particular Git Branch, ignoring the Maven GAV given in the repository.yaml. Thus, one *must* release SNAPSHOT plugin versions in order to be able to bugfix Forge plugins. This is quite contrary to a normal Maven release, where SNAPSHOT versions are not permitted (for example by the release plugin). So ... # Forge only uses HEAD of a branch to find a plugin source code revision # Repository.yaml indicates that a particular Maven GAV for a project should be used for the plugin # During resolution, Forge ignores the Maven GAV in repository.yaml # Maven releases are normally not permitted to contain SNAPSHOTs, but the two facts above *requires* Forge plugins to be Maven SNAPSHOTs. It seems that two different (and not particularly coherent) models are used to define Forge's resolution here. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1030) Repository.yaml does not use given project in multi-module Forge plugins

by Lennart Jörelid (JIRA)

Lennart Jörelid created FORGE-1030: -------------------------------------- Summary: Repository.yaml does not use given project in multi-module Forge plugins Key: FORGE-1030 URL: https://issues.jboss.org/browse/FORGE-1030 Project: Forge Issue Type: Bug Components: Documentation, Plugin API, Plugin Repository Affects Versions: 1.3.3.Final Reporter: Lennart Jörelid Priority: Critical It seems that Forge really needs better support for the default Maven development process. In repository.yaml, Forge plugins are defined by giving a Maven project GAV for the project holding the forge plugin definitions, as well as the GitHub repository holding the plugin source. Yet, Forge seems to ignore the Maven GAV information given in repository.yaml when checking out and building the plugin locally. This is a rather nasty bug, which in its current state effectively prevents anyone from using a multi-module build for their plugins (and it is also undocumented). An example is shown below: {code} [no project] Nazgul $ forge install-plugin nazgul ***INFO*** Preparing to install plugin: nazgul ***INFO*** Checking out plugin source files to [/var/folders/6g/9n7r543d2bv9n2qjvnvf_hsh0000gn/T/forgetemp6186363544408555570] via 'git' ***INFO*** Switching to branch/tag [refs/heads/1.3.3.Final] ? The project does not appear to be a Forge Plugin Project, install anyway? [y/N] {code} While this analysis by Forge is incorrect (the Maven GAV given in the repository.yaml is indeed a project which holds plugins), it gets worse after installation: {code} [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] nazgul-forge-parent ............................... SUCCESS [7.921s] [INFO] nazgul-forge-api-parent ........................... SUCCESS [4.345s] [INFO] nazgul-forge-model-parent ......................... SUCCESS [1.274s] [INFO] nazgul-forge-reactor .............................. SUCCESS [0.847s] [INFO] nazgul-forge-poms-reactor ......................... SUCCESS [0.058s] [INFO] nazgul-forge-analyzer-api ......................... SUCCESS [5.562s] [INFO] nazgul-forge-analyzer-impl-nazgul ................. SUCCESS [1.666s] [INFO] nazgul-forge-analyzer-reactor ..................... SUCCESS [0.020s] [INFO] nazgul-forge-factory-model ........................ SUCCESS [2.434s] [INFO] nazgul-forge-factory-api .......................... SUCCESS [7.634s] [INFO] nazgul-forge-factory-impl-nazgul .................. SUCCESS [2.724s] [INFO] nazgul-forge-factory-reactor ...................... SUCCESS [0.032s] [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 36.580s [INFO] Finished at: Mon Jul 22 07:46:48 CEST 2013 [INFO] Final Memory: 49M/247M [INFO] ------------------------------------------------------------------------ ***INFO*** Cleaning up temp workspace [/var/folders/6g/9n7r543d2bv9n2qjvnvf_hsh0000gn/T/forgetemp6186363544408555570] Deleted /var/folders/6g/9n7r543d2bv9n2qjvnvf_hsh0000gn/T/forgetemp6186363544408555570 ***ERROR*** Exception encountered: Build artifact [nazgul-forge-reactor-1.0.1-SNAPSHOT.pom] is missing and cannot be installed. Please resolve build errors and try again. (type "set VERBOSE true" to enable stack traces) {code} So ... # The repository.yaml includes a full Maven GAV to the project which holds Forge plugins. # Forge uses repository.yaml to download the source from GitHub and build it # Forge ignores the Maven GAV given in repository.yaml, and simply uses the root reactor project to inspect and attempt to install the plugins. To fix this bug, Forge needs to find the project given within the repository.yaml within the downloaded reactor and install the plugins from *that* project. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1029) Develop an Intellij Idea plugin as a Forge 2 UI Provider

by George Gastaldi (JIRA)

George Gastaldi created FORGE-1029: -------------------------------------- Summary: Develop an Intellij Idea plugin as a Forge 2 UI Provider Key: FORGE-1029 URL: https://issues.jboss.org/browse/FORGE-1029 Project: Forge Issue Type: Feature Request Components: UI - IntelliJ IDEA Reporter: George Gastaldi Assignee: Andrei Simionescu Fix For: 2.x Future This should allow us to execute Forge 2 under Idea. GitHub repository: https://github.com/forge/intellij-idea-plugin -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1025) FileResource<?> should accept Charset as an argument for get/setContents() to/from String

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-1025?page=com.atlassian.jira.plugin... ] George Gastaldi closed FORGE-1025. ---------------------------------- Assignee: George Gastaldi Fix Version/s: 2.0.0.Alpha7 Resolution: Done Fixed > FileResource<?> should accept Charset as an argument for get/setContents() to/from String > ----------------------------------------------------------------------------------------- > > Key: FORGE-1025 > URL: https://issues.jboss.org/browse/FORGE-1025 > Project: Forge > Issue Type: Feature Request > Components: Resources API > Affects Versions: 2.0.0.Alpha6 > Reporter: Lincoln Baxter III > Assignee: George Gastaldi > Labels: Starter > Fix For: 2.0.0.Alpha7 > > > Character encoding is important to maintain when dealing with Strings on various file-types. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1028) Add support in the Java Parser to resolve JDT bindings

by Vineet Reynolds (JIRA)

Vineet Reynolds created FORGE-1028: -------------------------------------- Summary: Add support in the Java Parser to resolve JDT bindings Key: FORGE-1028 URL: https://issues.jboss.org/browse/FORGE-1028 Project: Forge Issue Type: Feature Request Components: Parsers / File Manipulation Reporter: Vineet Reynolds Eclipse JDT allows bindings to be resolved from an AST tree, provided that the compilation units are accessible. This allows for the bindings to be inspected at runtime. See the [setResolveBindings method|http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.jdt....] in the Eclipse ASTParser API. We do not provide the ASTParser with an {{IProject}} nor do we configure the {{Environment}}, thus resulting in an inability to resolve the bindings. This should preferably be done with the sources of the project dependencies and the project sources, so that we can retrieve the type information in the JavaParser. This may also help in resolving FORGE-773, although it still requires the sources to be available. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (FORGE-918) Faces Scaffolding interprets long x[][] fields as long

by Vineet Reynolds (JIRA)

[ https://issues.jboss.org/browse/FORGE-918?page=com.atlassian.jira.plugin.... ] Vineet Reynolds closed FORGE-918. --------------------------------- > Faces Scaffolding interprets long x[][] fields as long > ------------------------------------------------------ > > Key: FORGE-918 > URL: https://issues.jboss.org/browse/FORGE-918 > Project: Forge > Issue Type: Bug > Components: Scaffold > Reporter: Vineet Reynolds > Assignee: Vineet Reynolds > Fix For: 1.x Future > > > This is from TicketMonster. The {{SectionAllocation}} class contains a {{long allocated[][]}} field. With the getters and setters (one may need to add the setters; see FORGE-917), the generated view does not contain a widget for the n-dimensional array type, and instead displays a single numerical entry widget. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (FORGE-918) Faces Scaffolding interprets long x[][] fields as long

by Vineet Reynolds (JIRA)

[ https://issues.jboss.org/browse/FORGE-918?page=com.atlassian.jira.plugin.... ] Vineet Reynolds resolved FORGE-918. ----------------------------------- Resolution: Done Fixed in the Forge Java Parser via FORGE-1026. Upgraded to the newer version of the parser in FORGE-1027. > Faces Scaffolding interprets long x[][] fields as long > ------------------------------------------------------ > > Key: FORGE-918 > URL: https://issues.jboss.org/browse/FORGE-918 > Project: Forge > Issue Type: Bug > Components: Scaffold > Reporter: Vineet Reynolds > Assignee: Vineet Reynolds > Fix For: 1.x Future > > > This is from TicketMonster. The {{SectionAllocation}} class contains a {{long allocated[][]}} field. With the getters and setters (one may need to add the setters; see FORGE-917), the generated view does not contain a widget for the n-dimensional array type, and instead displays a single numerical entry widget. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1024) The generated scaffold may fail to compile when array-typed fields are present in the JPA entities

by Vineet Reynolds (JIRA)

[ https://issues.jboss.org/browse/FORGE-1024?page=com.atlassian.jira.plugin... ] Vineet Reynolds resolved FORGE-1024. ------------------------------------ Fix Version/s: 1.3.4.Final Resolution: Done Fixed in the Forge Java Parser via FORGE-1026. Upgraded to the newer version of the parser in FORGE-1027. > The generated scaffold may fail to compile when array-typed fields are present in the JPA entities > -------------------------------------------------------------------------------------------------- > > Key: FORGE-1024 > URL: https://issues.jboss.org/browse/FORGE-1024 > Project: Forge > Issue Type: Bug > Components: Scaffold > Affects Versions: 1.3.3.Final > Reporter: Burr Sutter > Assignee: Vineet Reynolds > Priority: Critical > Fix For: 1.3.4.Final > > Attachments: Staff.java, StaffBean.java > > > This is from the Sakila-h2 model and happens occasionally in this model depending on JPA field order in the {{Staff}} class, but could be more frequent in other models. > The scaffold generator is unable to distinguish between array types and corresponding primitive types, thus resulting in code that is syntactically invalid, like: > {noformat} > byte picture = this.example.getPicture(); > if (picture != 0) > { > predicatesList.add(builder.equal(root.get("picture"), picture)); > } > {noformat} > where the {{picture}} field in the JPA entity is of type {{byte[]}}. > This also seems related to FORGE-918 where information about array-types is lost. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1024) The generated scaffold may fail to compile when array-typed fields are present in the JPA entities

by Vineet Reynolds (JIRA)

[ https://issues.jboss.org/browse/FORGE-1024?page=com.atlassian.jira.plugin... ] Vineet Reynolds closed FORGE-1024. ---------------------------------- > The generated scaffold may fail to compile when array-typed fields are present in the JPA entities > -------------------------------------------------------------------------------------------------- > > Key: FORGE-1024 > URL: https://issues.jboss.org/browse/FORGE-1024 > Project: Forge > Issue Type: Bug > Components: Scaffold > Affects Versions: 1.3.3.Final > Reporter: Burr Sutter > Assignee: Vineet Reynolds > Priority: Critical > Fix For: 1.3.4.Final > > Attachments: Staff.java, StaffBean.java > > > This is from the Sakila-h2 model and happens occasionally in this model depending on JPA field order in the {{Staff}} class, but could be more frequent in other models. > The scaffold generator is unable to distinguish between array types and corresponding primitive types, thus resulting in code that is syntactically invalid, like: > {noformat} > byte picture = this.example.getPicture(); > if (picture != 0) > { > predicatesList.add(builder.equal(root.get("picture"), picture)); > } > {noformat} > where the {{picture}} field in the JPA entity is of type {{byte[]}}. > This also seems related to FORGE-918 where information about array-types is lost. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1026) JavaParser fails to identify types of ArrayType in method return types

by Vineet Reynolds (JIRA)

[ https://issues.jboss.org/browse/FORGE-1026?page=com.atlassian.jira.plugin... ] Vineet Reynolds updated FORGE-1026: ----------------------------------- Status: Closed (was: Pull Request Sent) Fix Version/s: 1.3.4.Final Resolution: Done Pushed upstream: https://github.com/forge/java-parser/commit/d76afcda5cd441543f1a4c7cfaf97... > JavaParser fails to identify types of ArrayType in method return types > ---------------------------------------------------------------------- > > Key: FORGE-1026 > URL: https://issues.jboss.org/browse/FORGE-1026 > Project: Forge > Issue Type: Bug > Components: Parsers / File Manipulation > Affects Versions: 1.3.3.Final > Reporter: Vineet Reynolds > Assignee: Vineet Reynolds > Fix For: 1.3.4.Final > > > {{org.jboss.forge.parser.java.Method.getQualifiedReturnType()}} converts array types into simple types resulting in loss of information about the return type. > This is due to Arrays being stripped away when {{org.jboss.forge.parser.java.impl.AbstractJavaSource.resolveType(String)}} is invoked. The type returned by {{AbstractJavaSource}} omits any information about the ArrayType in the provided argument, and this is not accounted for when returning the qualified type. -- 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, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

forge-issues July 2013