August 2013 - forge-issues - Jboss List Archives

[JBoss JIRA] (FORGEPLUGINS-126) Rework the AngularJS scaffolding to support the new REST resource representations

by Vineet Reynolds (JIRA)

Vineet Reynolds created FORGEPLUGINS-126: -------------------------------------------- Summary: Rework the AngularJS scaffolding to support the new REST resource representations Key: FORGEPLUGINS-126 URL: https://issues.jboss.org/browse/FORGEPLUGINS-126 Project: Forge Plugins Issue Type: Feature Request Components: AngularJS Scaffold Reporter: Vineet Reynolds Assignee: Vineet Reynolds Based on the ongoing work for FORGE-1060, it would be necessary to rework the logic for handling associations (both n-to-many and n-to-one) since only Ids of the associated fields are required now. Additional fields that are not a part of the associated resource's representation should not be sent to the server, since it is possible that the server may treat such fields in the incoming JSON representation as not ignorable and respond with a HTTP 400 error. -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1093) Unit tests should not require "clean install" goals be set for build to succeed with dynamic versions

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-1093?page=com.atlassian.jira.plugin... ] Lincoln Baxter III updated FORGE-1093: -------------------------------------- Issue Type: Bug (was: Feature Request) > Unit tests should not require "clean install" goals be set for build to succeed with dynamic versions > ----------------------------------------------------------------------------------------------------- > > Key: FORGE-1093 > URL: https://issues.jboss.org/browse/FORGE-1093 > Project: Forge > Issue Type: Bug > Components: Forge Build > Affects Versions: 2.0.0.Alpha10 > Reporter: Lincoln Baxter III > Fix For: 2.x Future > > > See FORGE-1045 -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1093) Unit tests should not require "clean install" goals be set for build to succeed with dynamic versions

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-1093?page=com.atlassian.jira.plugin... ] Lincoln Baxter III updated FORGE-1093: -------------------------------------- Fix Version/s: 2.x Future > Unit tests should not require "clean install" goals be set for build to succeed with dynamic versions > ----------------------------------------------------------------------------------------------------- > > Key: FORGE-1093 > URL: https://issues.jboss.org/browse/FORGE-1093 > Project: Forge > Issue Type: Feature Request > Components: Forge Build > Affects Versions: 2.0.0.Alpha10 > Reporter: Lincoln Baxter III > Fix For: 2.x Future > > > See FORGE-1045 -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1093) Unit tests should not require "clean install" goals be set for build to succeed with dynamic versions

by Lincoln Baxter III (JIRA)

Lincoln Baxter III created FORGE-1093: ----------------------------------------- Summary: Unit tests should not require "clean install" goals be set for build to succeed with dynamic versions Key: FORGE-1093 URL: https://issues.jboss.org/browse/FORGE-1093 Project: Forge Issue Type: Feature Request Components: Forge Build Affects Versions: 2.0.0.Alpha10 Reporter: Lincoln Baxter III See FORGE-1045 -- 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

10 years, 11 months

1
0
0 / 0

[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 reassigned FORGE-957: ------------------------------------- Assignee: George Gastaldi > 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-988) Refactor AddonManager to support addon version conflicts

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-988?page=com.atlassian.jira.plugin.... ] George Gastaldi updated FORGE-988: ---------------------------------- Fix Version/s: 2.x Future (was: 2.0.0.Alpha10) > Refactor AddonManager to support addon version conflicts > -------------------------------------------------------- > > Key: FORGE-988 > URL: https://issues.jboss.org/browse/FORGE-988 > Project: Forge > Issue Type: Enhancement > Components: Addon Manager > Affects Versions: 2.0.0.Alpha6 > Reporter: George Gastaldi > Assignee: George Gastaldi > Priority: Critical > Fix For: 2.x Future > > > Given that Addons A(1.0), B (1.0), C(1.0) are installed in an AddonRepository, and C(1.0) depends on B(1.0), when an addon D(1.0) to be installed requires B(1.1), there should be a way to warn against incompatibilities and let the user decide what to do. Same when D(1.0) depends on B(2.0) > Basically an addon version is composed of Major.Minor.Micro > In relation to the installed addon version and the requested addon version the following rules should be followed: > - When Major version is different, the addons are assumed be completely incompatible (even if in practice that is not true). Fail installation > - When Minor version is different, compatibility may be assured only if the requested version is less or equal to the required version. Prompt for installation of necessary version. > - When Micro version is different, the addon is totally compatible, thus no compatibility check is required. No problem to install -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1067) Adopt WebJars as encapsulation for Bootstrap and JQuery resources

by Vineet Reynolds (JIRA)

[ https://issues.jboss.org/browse/FORGE-1067?page=com.atlassian.jira.plugin... ] Vineet Reynolds commented on FORGE-1067: ---------------------------------------- We could consider this sometime in the 2.x series when the existing Faces scaffold would be written to use the templated form. It would be a matter of having a new scaffold provider like the default Faces scaffolding, but with separate templates apart from the WebJars dependency installers. > Adopt WebJars as encapsulation for Bootstrap and JQuery resources > ----------------------------------------------------------------- > > Key: FORGE-1067 > URL: https://issues.jboss.org/browse/FORGE-1067 > Project: Forge > Issue Type: Enhancement > Components: Scaffold > Affects Versions: 1.3.3.Final > Reporter: Antonio Goncalves > Fix For: 1.x Future > > > At the moment JBoss Forge copies the {{bootstrap.css}} into the resources directory. It would be nice to use WebJar [1] to package Bootstrap (and JQuery) into the war file. > For this to happen you just need to add the following Maven dependencies to the {{pom.xml}} : > {code} > <dependency> > <groupId>org.webjars</groupId> > <artifactId>bootstrap</artifactId> > <version>2.3.2</version> > </dependency> > <dependency> > <groupId>org.webjars</groupId> > <artifactId>jquery</artifactId> > <version>2.0.3</version> > </dependency> > {code} > Then, change the {{pageTemplate.xhtml}} so it looks like this : > {code} > <!DOCTYPE html> > <html xmlns="http://www.w3.org/1999/xhtml" > xmlns:h="http://java.sun.com/jsf/html" > xmlns:ui="http://java.sun.com/jsf/facelets"> > <h:head> > <title>#{empty pageTitle ? '{#pageTitle}' : pageTitle}</title> > <link rel="icon" href="#{resource['favicon.ico']}"/> > <h:outputStylesheet library="webjars/bootstrap/2.3.2/css" name="bootstrap.min.css"/> > <h:outputStylesheet name="forge-style.css"/> > </h:head> > <h:body> > ... > ... > ... >  >  > <h:outputScript name="webjars/jquery/2.0.3/jquery.min.js"/> > <h:outputScript library="webjars/bootstrap/2.3.2/js" name="bootstrap.min.js"/> > </h:body> > </html> > {code} > And of course, get rid of the {{bootstrap.css}} file ;o) > [1] http://www.webjars.org/ > [1] http://www.jamesward.com/2012/10/31/webjars-officially-launched > See also : https://issues.jboss.org/browse/RF-12584 -- 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

10 years, 11 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 edited comment on FORGE-918 at 8/5/13 8:04 PM: --------------------------------------------------------------- Reopening this, as this seems to be an issue with the Eclipse JDT parser. To clarify, FORGE-1026 and FORGE-1086 have resolved issues involving parsing of array types in method return value types and field types. However, for some reason, the Eclipse JDT parser itself has trouble disambiguating between {{long[][] x;}} and {{long x[][];}} and treats the latter as {{long}}. was (Author: vineet.reynolds): Reopening this, as this seems to be an issue with the Eclipse JDT parser. > 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

10 years, 11 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 reopened FORGE-918: ----------------------------------- Reopening this, as this seems to be an issue with the Eclipse JDT parser. > 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1045) Unit tests should not have a fixed version

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-1045?page=com.atlassian.jira.plugin... ] Lincoln Baxter III commented on FORGE-1045: ------------------------------------------- I'm not sure actually. I think that the ClasspathWorkspaceReader should be able to figure this out based on what's added. We can close this issue, but a new bug should be reopened for this problem. > Unit tests should not have a fixed version > ------------------------------------------ > > Key: FORGE-1045 > URL: https://issues.jboss.org/browse/FORGE-1045 > Project: Forge > Issue Type: Enhancement > Components: Test Harness > Affects Versions: 2.0.0.Alpha7 > Reporter: George Gastaldi > Assignee: George Gastaldi > Fix For: 2.0.0.Alpha10 > > > Tests now depend on 2.0.0-SNAPSHOT, which may fail when a new version of the addon dependency is released. > We should find some way to avoid declaring the addon dependencies version directly in the Java class. > Excerpt from IRC: > {quote} > <gastaldi> lincolnthree, about the version in the dependencies > <gastaldi> in the tests > <lincolnthree> yes > <gastaldi> What if we consider that if no @Dependencies annotation were provided it should use the pom's dependencies ? > <lincolnthree> can't do that > <gastaldi> why ? > <lincolnthree> because you should be able to depend on dependencies that don't exist > <lincolnthree> without having to remove them from the pom > <lincolnthree> it's a valid failure scenario (laughs at that wording) > <lincolnthree> so we need to be able to test it > <lincolnthree> gastaldi: i would much prefer setting the version to "POM" > <lincolnthree> or omitting the version entirely > <lincolnthree> from the @AddonDependency annotation > <gastaldi> I think it's already optional, no ? > <lincolnthree> it is > <lincolnthree> and the default is LATEST > <lincolnthree> default should probably be POM, which we should intercept and replace with the pom version > <lincolnthree> or throw a deployment exception if it could not be resolved > <gastaldi> I see > <lincolnthree> thoughts? > <gastaldi> What about the AddonDependencyEntry.create statements ? > <gastaldi> sounds fair so far > <gastaldi> we could introduce a new method in ForgeArchive > <gastaldi> addAddonDependenciesAsDeclaredInPOMForGodsSake() > <lincolnthree> ah… right > <lincolnthree> well > <lincolnthree> the version there doesn't matter, remember? > <lincolnthree> so we could actually make the version optional > <lincolnthree> it could default to "anything" > <gastaldi> so so we need a AnythingGoesVersion implements Version subclass > <gastaldi> an enum > <gastaldi> public enum Anything implements Version { INSTANCE;} > <gastaldi> hum, or the version could be empty, right > <gastaldi> in that case there is already the EmptyVersion class > <lincolnthree> right > {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

10 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

forge-issues August 2013