January 2015 - forge-issues - Jboss List Archives

[JBoss JIRA] (FORGE-2204) Furnace CDI container should not depend on Groovy

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2204?page=com.atlassian.jira.plugin... ] George Gastaldi closed FORGE-2204. ---------------------------------- Resolution: Done > Furnace CDI container should not depend on Groovy > ------------------------------------------------- > > Key: FORGE-2204 > URL: https://issues.jboss.org/browse/FORGE-2204 > Project: Forge > Issue Type: Enhancement > Components: Furnace CDI > Affects Versions: 2.13.1.Final > Reporter: George Gastaldi > Assignee: George Gastaldi > Fix For: 2.14.0.Final > > > Weld-SE-Core has a direct dependency with groovy-all. That should not be used in the furnace-cdi container and needs to be excluded. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2204) Furnace CDI container should not depend on Groovy

by George Gastaldi (JIRA)

George Gastaldi created FORGE-2204: -------------------------------------- Summary: Furnace CDI container should not depend on Groovy Key: FORGE-2204 URL: https://issues.jboss.org/browse/FORGE-2204 Project: Forge Issue Type: Enhancement Components: Furnace CDI Affects Versions: 2.13.1.Final Reporter: George Gastaldi Assignee: George Gastaldi Fix For: 2.14.0.Final Weld-SE-Core has a direct dependency with groovy-all. That should not be used in the furnace-cdi container and needs to be excluded. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2203) Can't download Intellij plugin fron Intellij 14

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2203?page=com.atlassian.jira.plugin... ] George Gastaldi closed FORGE-2203. ---------------------------------- Resolution: Done Download link fixed > Can't download Intellij plugin fron Intellij 14 > ----------------------------------------------- > > Key: FORGE-2203 > URL: https://issues.jboss.org/browse/FORGE-2203 > Project: Forge > Issue Type: Bug > Reporter: Dustin Kut Moy Cheung > Assignee: George Gastaldi > > When trying to update the Forge plugin from Intellij 14, a 404 error is obtained. > Upon further investigation, when going to the Forge Intellij page (https://plugins.jetbrains.com/plugin/7515), the Download link is dead. It seems the user who provided that link deleted the plugin from its Dropbox repository. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2202) Provide formatter configuration when using Forge

by Devanshu Singh (JIRA)

[ https://issues.jboss.org/browse/FORGE-2202?page=com.atlassian.jira.plugin... ] Devanshu Singh commented on FORGE-2202: --------------------------------------- George , I'll update the code with a PR. > Provide formatter configuration when using Forge > ------------------------------------------------ > > Key: FORGE-2202 > URL: https://issues.jboss.org/browse/FORGE-2202 > Project: Forge > Issue Type: Feature Request > Components: Builtin Plugins, Configuration, Parsers / File Manipulation > Affects Versions: 2.x Future > Reporter: Ivan St. Ivanov > Assignee: George Gastaldi > Fix For: 2.14.0.Final > > > When Forge generates code it formats it with the current Forge [Eclipse-based] formatter: 3 spaces indentation and opening braces on the next line. As mentioned by George in the mailing list, if you develop an addon, it is possible to control that via the Roaster API by calling Roaster.format() passing as an argument the Eclipse formatter profile XML. > However, it would be a good idea if I am just a Forge user to be able to configure the already existing addons that generate code (e.g. the new entity command) to use a formatter that I have provided, so that the generated code follows the code conventions adopted in the project/team I work in -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2202) Provide formatter configuration when using Forge

by Ivan St. Ivanov (JIRA)

[ https://issues.jboss.org/browse/FORGE-2202?page=com.atlassian.jira.plugin... ] Ivan St. Ivanov commented on FORGE-2202: ---------------------------------------- George, you are simply awesome! :) > Provide formatter configuration when using Forge > ------------------------------------------------ > > Key: FORGE-2202 > URL: https://issues.jboss.org/browse/FORGE-2202 > Project: Forge > Issue Type: Feature Request > Components: Builtin Plugins, Configuration, Parsers / File Manipulation > Affects Versions: 2.x Future > Reporter: Ivan St. Ivanov > Assignee: George Gastaldi > Fix For: 2.14.0.Final > > > When Forge generates code it formats it with the current Forge [Eclipse-based] formatter: 3 spaces indentation and opening braces on the next line. As mentioned by George in the mailing list, if you develop an addon, it is possible to control that via the Roaster API by calling Roaster.format() passing as an argument the Eclipse formatter profile XML. > However, it would be a good idea if I am just a Forge user to be able to configure the already existing addons that generate code (e.g. the new entity command) to use a formatter that I have provided, so that the generated code follows the code conventions adopted in the project/team I work in -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2202) Provide formatter configuration when using Forge

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2202?page=com.atlassian.jira.plugin... ] George Gastaldi commented on FORGE-2202: ---------------------------------------- [~d911], I believe we may need to change the {{java-format-sources}} command to use the utility class created in ROASTER-58. I don't think that using {{Properties.load()}} will be enough. > Provide formatter configuration when using Forge > ------------------------------------------------ > > Key: FORGE-2202 > URL: https://issues.jboss.org/browse/FORGE-2202 > Project: Forge > Issue Type: Feature Request > Components: Builtin Plugins, Configuration, Parsers / File Manipulation > Affects Versions: 2.x Future > Reporter: Ivan St. Ivanov > Assignee: George Gastaldi > Fix For: 2.14.0.Final > > > When Forge generates code it formats it with the current Forge [Eclipse-based] formatter: 3 spaces indentation and opening braces on the next line. As mentioned by George in the mailing list, if you develop an addon, it is possible to control that via the Roaster API by calling Roaster.format() passing as an argument the Eclipse formatter profile XML. > However, it would be a good idea if I am just a Forge user to be able to configure the already existing addons that generate code (e.g. the new entity command) to use a formatter that I have provided, so that the generated code follows the code conventions adopted in the project/team I work in -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2202) Provide formatter configuration when using Forge

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2202?page=com.atlassian.jira.plugin... ] George Gastaldi closed FORGE-2202. ---------------------------------- Fix Version/s: 2.14.0.Final (was: 2.x Future) Resolution: Done Feature implemented. Created command {{Java: Set Default Formatter}} to specify the formatter XML to be used. This information will be stored in the {{~/.forge/config.xml}} file. After that, every call to JavaResource.setContents() will format the sources before persisting. An improvement to this issue is to store the formatter path/name in the Project's configuration thru {{ConfigurationFacet}}. > Provide formatter configuration when using Forge > ------------------------------------------------ > > Key: FORGE-2202 > URL: https://issues.jboss.org/browse/FORGE-2202 > Project: Forge > Issue Type: Feature Request > Components: Builtin Plugins, Configuration, Parsers / File Manipulation > Affects Versions: 2.x Future > Reporter: Ivan St. Ivanov > Assignee: George Gastaldi > Fix For: 2.14.0.Final > > > When Forge generates code it formats it with the current Forge [Eclipse-based] formatter: 3 spaces indentation and opening braces on the next line. As mentioned by George in the mailing list, if you develop an addon, it is possible to control that via the Roaster API by calling Roaster.format() passing as an argument the Eclipse formatter profile XML. > However, it would be a good idea if I am just a Forge user to be able to configure the already existing addons that generate code (e.g. the new entity command) to use a formatter that I have provided, so that the generated code follows the code conventions adopted in the project/team I work in -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-58) Create an utility class to read Eclipse profile XMLs

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/ROASTER-58?page=com.atlassian.jira.plugin... ] George Gastaldi closed ROASTER-58. ---------------------------------- Resolution: Done > Create an utility class to read Eclipse profile XMLs > ---------------------------------------------------- > > Key: ROASTER-58 > URL: https://issues.jboss.org/browse/ROASTER-58 > Project: Roaster > Issue Type: Feature Request > Components: API > Affects Versions: 2.11.1.Final > Reporter: George Gastaldi > Assignee: George Gastaldi > Fix For: 2.11.2.Final > > > This is needed to convert profile XMLs into Properties objects, to be used in the {{Roaster.format}} method -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1790) Make adding addon deps easier in getDeployment().

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-1790?page=com.atlassian.jira.plugin... ] George Gastaldi updated FORGE-1790: ----------------------------------- Fix Version/s: 2.x Future > Make adding addon deps easier in getDeployment(). > ------------------------------------------------- > > Key: FORGE-1790 > URL: https://issues.jboss.org/browse/FORGE-1790 > Project: Forge > Issue Type: Feature Request > Components: Test Harness > Affects Versions: 2.13.1.Final > Reporter: Ondrej Zizka > Assignee: George Gastaldi > Fix For: 2.x Future > > > Currently, the deps need to be stated twice - once in annotations, and then in getDeployment(). If getDeployment() wasn't static, one could get that using reflection. But Arquillian needs getDeployment static. > This also limits usage of subclassing, because subclass can't add dependencies to it's parent. > Would be nice to come up with some solution to this. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1790) Make adding addon deps easier in getDeployment().

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-1790?page=com.atlassian.jira.plugin... ] Lincoln Baxter III edited comment on FORGE-1790 at 1/26/15 2:22 PM: -------------------------------------------------------------------- [~ozizka] That isn't really a solution, more of a workaround. This needs to be addressed in the Forge test-harness API. In order to fix this, we need to: * Copy @AddonDependency to @AddonDeployment * Deprecate existing @AddonDependency() annotation: * Create a new @AddonDeployment annotation: {code} @Documented @Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface AddonDeployment { /** The {@link AddonId} coordinates. String name(); /** Whether or not the specified addon should be imported as a dependency to the current @Deployment. **/ boolean imported(); /** Whether or not the specified addon should be exported to dependencies of the current @Deployment. **/ boolean exported(); /** Whether or not the specified addon should be marked as an optional dependency of the current @Deployment. **/ boolean optional(); /** * If version is empty, resolve to the version specified in the pom.xml of the project being tested */ String version() default ""; } {code} If we don't deprecate @AddonDependency, then we should also supplement it with the same new fields. was (Author: lincolnthree): [~ozizka] That isn't really a solution, more of a workaround. This needs to be addressed in the Forge test-harness API. In order to fix this, we need to: * Copy @AddonDependency to @AddonDeployment * Deprecate existing @AddonDependency() annotation: * Create a new @AddonDeployment annotation: {code} @Documented @Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface AddonDeployment { /** The {@link AddonId} coordinates. String name(); /** Whether or not the specified addon should be imported as a dependency to the current @Deployment. **/ boolean imported(); /** Whether or not the specified addon should be exported to dependencies of the current @Deployment. **/ boolean exported(); /** Whether or not the specified addon should be marked as an optional dependency of the current @Deployment. **/ boolean optional(); /** * If version is empty, resolve to the version specified in the pom.xml of the project being tested */ String version() default ""; } {code} > Make adding addon deps easier in getDeployment(). > ------------------------------------------------- > > Key: FORGE-1790 > URL: https://issues.jboss.org/browse/FORGE-1790 > Project: Forge > Issue Type: Feature Request > Components: Test Harness > Affects Versions: 2.13.1.Final > Reporter: Ondrej Zizka > Assignee: George Gastaldi > > Currently, the deps need to be stated twice - once in annotations, and then in getDeployment(). If getDeployment() wasn't static, one could get that using reflection. But Arquillian needs getDeployment static. > This also limits usage of subclassing, because subclass can't add dependencies to it's parent. > Would be nice to come up with some solution to this. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

forge-issues January 2015