[JBoss JIRA] (FORGE-918) Forge Java parser interprets Type x[][] fields as Type
by Vineet Reynolds (JIRA)
[ https://issues.jboss.org/browse/FORGE-918?page=com.atlassian.jira.plugin.... ]
Vineet Reynolds updated FORGE-918:
----------------------------------
Component/s: Parsers / File Manipulation
(was: Scaffold)
> Forge Java parser interprets Type x[][] fields as Type
> ------------------------------------------------------
>
> Key: FORGE-918
> URL: https://issues.jboss.org/browse/FORGE-918
> Project: Forge
> Issue Type: Bug
> Components: Parsers / File Manipulation
> 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
[JBoss JIRA] (FORGE-918) Forge Java parser interprets Type x[][] fields as Type
by Vineet Reynolds (JIRA)
[ https://issues.jboss.org/browse/FORGE-918?page=com.atlassian.jira.plugin.... ]
Vineet Reynolds updated FORGE-918:
----------------------------------
Summary: Forge Java parser interprets Type x[][] fields as Type (was: Faces Scaffolding interprets long x[][] fields as long)
> Forge Java parser interprets Type x[][] fields as Type
> ------------------------------------------------------
>
> 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
[JBoss JIRA] (FORGE-957) Create "Stacks" addon, that allows providing stack implementations to supply default values in dialogs
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-957?page=com.atlassian.jira.plugin.... ]
George Gastaldi commented on FORGE-957:
---------------------------------------
As I was speaking with [~vineet.reynolds]:
{quote}
<gastaldi> I am not sure if the stacks.yaml may help in this scenario
<vineetreynolds> hmm well I'm not entirely sure about storing everything in a configuration file
<vineetreynolds> stacks.yaml is for jboss as only
<gastaldi> yes
<vineetreynolds> It wouldnt help for other containers
<vineetreynolds> And also for other 'stacks'
<vineetreynolds> Besides some of this configuration that we speak of, can come from Facets
<gastaldi> I think it is meant to be something like FORGE-378
<vineetreynolds> Well yes
<vineetreynolds> That is one part of the solution
<gastaldi> Do you have any suggestions ?
<vineetreynolds> The other is to read this information out from project POMs etc
<gastaldi> but the POM may not have this info
<gastaldi> I mean, if we take only the dependencies in account
<vineetreynolds> Yes, POMs are just one possible source
<vineetreynolds> We have to account for multiple sources to evaluate whether some portion of a stack is already available
<vineetreynolds> I think we should also consider extracting that info from .settings (if I'm not mistaken)
<vineetreynolds> The Eclipse .settings dir to be specific
<gastaldi> hummm
<gastaldi> that would be another source of information
<vineetreynolds> Yeah, we could start with the more definite sources and then work our way down
<vineetreynolds> Container choices could have multiple sources of info
<gastaldi> but this won't tell if the user wishes to run in Wildfly, for example
<vineetreynolds> like usage of the deploy plugins in POMs
<vineetreynolds> Hmm no, isnt the stacks addon supposed to help the user reduce the number of choices based on what's in the stack
<gastaldi> well, given the description of FORGE-957, I am not so sure
<vineetreynolds> In that case, if he wishes to run on a new stack, he'd have to configure/choose the container first
<vineetreynolds> Hmm I think there are too many feature requests in here
<vineetreynolds> All bringing their own constraints
<gastaldi> yes, that's the point where I stood
<vineetreynolds> I think we should nail down what 957 is all about
<vineetreynolds> In my opinion, it means that if WildFly is a chosen container, then in dialogs should provide inputs from stacks.yaml
<vineetreynolds> I dont think stacks.yaml supports WF but I might be wrong
<gastaldi> that's only an example
<gastaldi> it does not actually
<vineetreynolds> The idea behind stacks.yaml is that if you have AS 7.1.1 or EAP 6.0 , 6.0.1 or 6.1, then different versions of dependencies tested on those containers would be populated in the project POMs
<vineetreynolds> Thats my idea about how 957 should work
<vineetreynolds> Ditto for WF
<vineetreynolds> So if WF 8.0 Final is tested against RF 5.0
<gastaldi> Yes
<vineetreynolds> then the RichFaces 5.0 BOM should be proposed first
<vineetreynolds> or should be chosen
<vineetreynolds> Whatever
<gastaldi> it's a matter of choosing the right BOM
<vineetreynolds> Yep
<vineetreynolds> So maybe we should ask Lincoln for confirmation on the scope
<gastaldi> probably yeah, I think the scope is too abroad
<vineetreynolds> and then set out different ways to obtain info on whether the user will deploy on the containers
<vineetreynolds> Yeah
<vineetreynolds> Obtaining sources of this info is one part, plugging these inputs into various addons is another
{quote}
> Create "Stacks" addon, that allows providing stack implementations to supply default values in dialogs
> ------------------------------------------------------------------------------------------------------
>
> Key: FORGE-957
> URL: https://issues.jboss.org/browse/FORGE-957
> Project: Forge
> Issue Type: Feature Request
> Components: Blessed Plugins
> Affects Versions: 2.0.0.Alpha5
> Reporter: Lincoln Baxter III
> Assignee: George Gastaldi
> Priority: Critical
> Fix For: 2.0.0.Final
>
>
> This will allow things like, detecting that the user is on Wildfly AS, and subsequently selecting appropriate versions of specifications, libraries, and other setup configurations.
--
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
[JBoss JIRA] (FORGE-957) Create "Stacks" addon, that allows providing stack implementations to supply default values in dialogs
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-957?page=com.atlassian.jira.plugin.... ]
George Gastaldi commented on FORGE-957:
---------------------------------------
Here is an idea: Why not having a UICommand implementation to enter the default values for any (marked) type ? We could use the configuration addon to store this information in the user configuration file.
The idea is to introduce some kind of marker (interface or annotation) to allow an interface (or a class) to have a default value.
Here is an example taken from the Java EE addon:
{code}
@Exported
@Configurable
public interface PersistenceContainer {}
{code}
The @Configurable annotation indicates that the annotated type may appear as an input type in a UICommand to indicate the default value.
We could use this information when creating the UIInput to automatically set the default value as provided in the configuration addon.
Thoughts ?
> Create "Stacks" addon, that allows providing stack implementations to supply default values in dialogs
> ------------------------------------------------------------------------------------------------------
>
> Key: FORGE-957
> URL: https://issues.jboss.org/browse/FORGE-957
> Project: Forge
> Issue Type: Feature Request
> Components: Blessed Plugins
> Affects Versions: 2.0.0.Alpha5
> Reporter: Lincoln Baxter III
> Assignee: George Gastaldi
> Priority: Critical
> Fix For: 2.0.0.Final
>
>
> This will allow things like, detecting that the user is on Wildfly AS, and subsequently selecting appropriate versions of specifications, libraries, and other setup configurations.
--
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
[JBoss JIRA] (FORGE-1030) Support multi-module Forge plugins
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-1030?page=com.atlassian.jira.plugin... ]
Work on FORGE-1030 stopped by George Gastaldi.
> Support 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
> Assignee: George Gastaldi
> Priority: Blocker
> Fix For: 1.3.4.Final
>
> Attachments: forge_1030_codeAnalysis.png
>
>
> 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
[JBoss JIRA] (FORGE-1096) JavaParser fails to save a newly added constructor when Java 1.5+ features are used in the body
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-1096?page=com.atlassian.jira.plugin... ]
George Gastaldi updated FORGE-1096:
-----------------------------------
Status: Closed (was: Pull Request Sent)
Fix Version/s: 1.3.4.Final
Resolution: Done
Pull Request merged
> JavaParser fails to save a newly added constructor when Java 1.5+ features are used in the body
> -----------------------------------------------------------------------------------------------
>
> Key: FORGE-1096
> URL: https://issues.jboss.org/browse/FORGE-1096
> Project: Forge
> Issue Type: Bug
> Components: Builtin Plugins
> Affects Versions: 1.3.3.Final
> Reporter: Vineet Reynolds
> Assignee: Vineet Reynolds
> Priority: Critical
> Fix For: 1.3.4.Final
>
>
> The following exception stack trace or something similar is obtained when saving the {{JavaSource}} instance, after a constructor is added to it:
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 96
> at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.visit(CodeFormatterVisitor.java:3467)
> at org.eclipse.jdt.internal.compiler.ast.ConstructorDeclaration.traverse(ConstructorDeclaration.java:508)
> at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.format(CodeFormatterVisitor.java:593)
> at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.formatClassBodyDeclarations(CodeFormatterVisitor.java:1587)
> at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.format(CodeFormatterVisitor.java:830)
> at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.internalFormatClassBodyDeclarations(DefaultCodeFormatter.java:364)
> at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.formatClassBodyDeclarations(DefaultCodeFormatter.java:186)
> at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.format(DefaultCodeFormatter.java:161)
> at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.format(DefaultCodeFormatter.java:146)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteFormatter.formatString(ASTRewriteFormatter.java:245)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteFormatter.formatNode(ASTRewriteFormatter.java:370)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteFormatter.getFormattedResult(ASTRewriteFormatter.java:186)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.doTextInsert(ASTRewriteAnalyzer.java:1287)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer$ListRewriter.rewriteList(ASTRewriteAnalyzer.java:583)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer$ListRewriter.rewriteList(ASTRewriteAnalyzer.java:736)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.rewriteParagraphList(ASTRewriteAnalyzer.java:1109)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.visit(ASTRewriteAnalyzer.java:1727)
> at org.eclipse.jdt.core.dom.TypeDeclaration.accept0(TypeDeclaration.java:467)
> at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.doVisit(ASTRewriteAnalyzer.java:357)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.voidVisitList(ASTRewriteAnalyzer.java:395)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.voidVisit(ASTRewriteAnalyzer.java:389)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.doVisitUnchangedChildren(ASTRewriteAnalyzer.java:402)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.visit(ASTRewriteAnalyzer.java:1589)
> at org.eclipse.jdt.core.dom.CompilationUnit.accept0(CompilationUnit.java:214)
> at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514)
> at org.eclipse.jdt.core.dom.InternalASTRewrite.rewriteAST(InternalASTRewrite.java:99)
> at org.eclipse.jdt.core.dom.AST.rewrite(AST.java:2867)
> at org.eclipse.jdt.core.dom.CompilationUnit.rewrite(CompilationUnit.java:925)
> at org.jboss.forge.parser.java.impl.AbstractJavaSource.toString(AbstractJavaSource.java:632)
> ... 24 more
> {noformat}
> An example test that triggers this scenario is as follows:
> {code:java}
> @Test
> public void testSupportsGenericsSourceFromAddedConstructor() throws Exception {
> JavaClass source = JavaParser.parse(JavaClass.class, "public class Test{}");
> // Add a new method to get JDT to recognize the new ASTs
> source.addMethod().setConstructor(true).setBody("java.util.List<String> s = new java.util.ArrayList<String>(); for (String item : s){}");
> // Forces a rewrite to happen via AbstractJavaSource
> source.toString();
> Assert.assertFalse(source.hasSyntaxErrors());
> }
> {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, 8 months
[JBoss JIRA] (FORGE-1096) JavaParser fails to save a newly added constructor when Java 1.5+ features are used in the body
by Vineet Reynolds (JIRA)
[ https://issues.jboss.org/browse/FORGE-1096?page=com.atlassian.jira.plugin... ]
Vineet Reynolds updated FORGE-1096:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/forge/java-parser/pull/8
The exception was thrown on rewriting the CompilationUnit, and was most likely caused due to use of a lower source level.
Setting the source level to 1.7 gets rid of the exception.
> JavaParser fails to save a newly added constructor when Java 1.5+ features are used in the body
> -----------------------------------------------------------------------------------------------
>
> Key: FORGE-1096
> URL: https://issues.jboss.org/browse/FORGE-1096
> Project: Forge
> Issue Type: Bug
> Components: Builtin Plugins
> Affects Versions: 1.3.3.Final
> Reporter: Vineet Reynolds
> Assignee: Vineet Reynolds
> Priority: Critical
>
> The following exception stack trace or something similar is obtained when saving the {{JavaSource}} instance, after a constructor is added to it:
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 96
> at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.visit(CodeFormatterVisitor.java:3467)
> at org.eclipse.jdt.internal.compiler.ast.ConstructorDeclaration.traverse(ConstructorDeclaration.java:508)
> at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.format(CodeFormatterVisitor.java:593)
> at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.formatClassBodyDeclarations(CodeFormatterVisitor.java:1587)
> at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.format(CodeFormatterVisitor.java:830)
> at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.internalFormatClassBodyDeclarations(DefaultCodeFormatter.java:364)
> at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.formatClassBodyDeclarations(DefaultCodeFormatter.java:186)
> at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.format(DefaultCodeFormatter.java:161)
> at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.format(DefaultCodeFormatter.java:146)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteFormatter.formatString(ASTRewriteFormatter.java:245)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteFormatter.formatNode(ASTRewriteFormatter.java:370)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteFormatter.getFormattedResult(ASTRewriteFormatter.java:186)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.doTextInsert(ASTRewriteAnalyzer.java:1287)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer$ListRewriter.rewriteList(ASTRewriteAnalyzer.java:583)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer$ListRewriter.rewriteList(ASTRewriteAnalyzer.java:736)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.rewriteParagraphList(ASTRewriteAnalyzer.java:1109)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.visit(ASTRewriteAnalyzer.java:1727)
> at org.eclipse.jdt.core.dom.TypeDeclaration.accept0(TypeDeclaration.java:467)
> at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.doVisit(ASTRewriteAnalyzer.java:357)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.voidVisitList(ASTRewriteAnalyzer.java:395)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.voidVisit(ASTRewriteAnalyzer.java:389)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.doVisitUnchangedChildren(ASTRewriteAnalyzer.java:402)
> at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.visit(ASTRewriteAnalyzer.java:1589)
> at org.eclipse.jdt.core.dom.CompilationUnit.accept0(CompilationUnit.java:214)
> at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514)
> at org.eclipse.jdt.core.dom.InternalASTRewrite.rewriteAST(InternalASTRewrite.java:99)
> at org.eclipse.jdt.core.dom.AST.rewrite(AST.java:2867)
> at org.eclipse.jdt.core.dom.CompilationUnit.rewrite(CompilationUnit.java:925)
> at org.jboss.forge.parser.java.impl.AbstractJavaSource.toString(AbstractJavaSource.java:632)
> ... 24 more
> {noformat}
> An example test that triggers this scenario is as follows:
> {code:java}
> @Test
> public void testSupportsGenericsSourceFromAddedConstructor() throws Exception {
> JavaClass source = JavaParser.parse(JavaClass.class, "public class Test{}");
> // Add a new method to get JDT to recognize the new ASTs
> source.addMethod().setConstructor(true).setBody("java.util.List<String> s = new java.util.ArrayList<String>(); for (String item : s){}");
> // Forces a rewrite to happen via AbstractJavaSource
> source.toString();
> Assert.assertFalse(source.hasSyntaxErrors());
> }
> {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, 8 months
[JBoss JIRA] (FORGE-1096) JavaParser fails to save a newly added constructor when Java 1.5+ features are used in the body
by Vineet Reynolds (JIRA)
Vineet Reynolds created FORGE-1096:
--------------------------------------
Summary: JavaParser fails to save a newly added constructor when Java 1.5+ features are used in the body
Key: FORGE-1096
URL: https://issues.jboss.org/browse/FORGE-1096
Project: Forge
Issue Type: Bug
Components: Builtin Plugins
Affects Versions: 1.3.3.Final
Reporter: Vineet Reynolds
Assignee: Vineet Reynolds
Priority: Critical
The following exception stack trace or something similar is obtained when saving the {{JavaSource}} instance, after a constructor is added to it:
{noformat}
java.lang.ArrayIndexOutOfBoundsException: 96
at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.visit(CodeFormatterVisitor.java:3467)
at org.eclipse.jdt.internal.compiler.ast.ConstructorDeclaration.traverse(ConstructorDeclaration.java:508)
at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.format(CodeFormatterVisitor.java:593)
at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.formatClassBodyDeclarations(CodeFormatterVisitor.java:1587)
at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.format(CodeFormatterVisitor.java:830)
at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.internalFormatClassBodyDeclarations(DefaultCodeFormatter.java:364)
at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.formatClassBodyDeclarations(DefaultCodeFormatter.java:186)
at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.format(DefaultCodeFormatter.java:161)
at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.format(DefaultCodeFormatter.java:146)
at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteFormatter.formatString(ASTRewriteFormatter.java:245)
at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteFormatter.formatNode(ASTRewriteFormatter.java:370)
at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteFormatter.getFormattedResult(ASTRewriteFormatter.java:186)
at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.doTextInsert(ASTRewriteAnalyzer.java:1287)
at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer$ListRewriter.rewriteList(ASTRewriteAnalyzer.java:583)
at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer$ListRewriter.rewriteList(ASTRewriteAnalyzer.java:736)
at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.rewriteParagraphList(ASTRewriteAnalyzer.java:1109)
at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.visit(ASTRewriteAnalyzer.java:1727)
at org.eclipse.jdt.core.dom.TypeDeclaration.accept0(TypeDeclaration.java:467)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514)
at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.doVisit(ASTRewriteAnalyzer.java:357)
at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.voidVisitList(ASTRewriteAnalyzer.java:395)
at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.voidVisit(ASTRewriteAnalyzer.java:389)
at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.doVisitUnchangedChildren(ASTRewriteAnalyzer.java:402)
at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.visit(ASTRewriteAnalyzer.java:1589)
at org.eclipse.jdt.core.dom.CompilationUnit.accept0(CompilationUnit.java:214)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514)
at org.eclipse.jdt.core.dom.InternalASTRewrite.rewriteAST(InternalASTRewrite.java:99)
at org.eclipse.jdt.core.dom.AST.rewrite(AST.java:2867)
at org.eclipse.jdt.core.dom.CompilationUnit.rewrite(CompilationUnit.java:925)
at org.jboss.forge.parser.java.impl.AbstractJavaSource.toString(AbstractJavaSource.java:632)
... 24 more
{noformat}
An example test that triggers this scenario is as follows:
{code:java}
@Test
public void testSupportsGenericsSourceFromAddedConstructor() throws Exception {
JavaClass source = JavaParser.parse(JavaClass.class, "public class Test{}");
// Add a new method to get JDT to recognize the new ASTs
source.addMethod().setConstructor(true).setBody("java.util.List<String> s = new java.util.ArrayList<String>(); for (String item : s){}");
// Forces a rewrite to happen via AbstractJavaSource
source.toString();
Assert.assertFalse(source.hasSyntaxErrors());
}
{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, 8 months