March 2016 - forge-issues - Jboss List Archives

[JBoss JIRA] (FORGE-2616) Upgrade JGit to version 4.2.0.201601211800-r

by Andrea Cosentino (JIRA)

Andrea Cosentino created FORGE-2616: --------------------------------------- Summary: Upgrade JGit to version 4.2.0.201601211800-r Key: FORGE-2616 URL: https://issues.jboss.org/browse/FORGE-2616 Project: Forge Issue Type: Component Upgrade Components: Git Reporter: Andrea Cosentino Priority: Minor I guess we can upgrade to the latest Jgit. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2615) Forge addon - From one command be able to easily split into a wizard with N pages

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-2615?page=com.atlassian.jira.plugin... ] Lincoln Baxter III commented on FORGE-2615: ------------------------------------------- You could possibly implement this by passing Lambdas into each step for the various functions. A builder pattern would certainly make this possible. > Forge addon - From one command be able to easily split into a wizard with N pages > --------------------------------------------------------------------------------- > > Key: FORGE-2615 > URL: https://issues.jboss.org/browse/FORGE-2615 > Project: Forge > Issue Type: Feature Request > Components: UI - API > Affects Versions: 3.0.0.CR1 > Reporter: Claus Ibsen > Fix For: 3.x Future > > > Problem > When you build commands in forge that you want to be like a wizard, with 3 pages, where you on page 1 have 3 inputs, on page 2 4 inputs, and on page 3 2 inputs. Then today you need to build that in multiple classes with UIStep and initialize the ui for each step, and put them all together and whatnot. > This seems sometimes a bit too much for those simpler commands, where basically you wish you could write all that in just *one* java class. And then tell forge to split the UI elements into 3 pages, and tell it which UI elements go into what page. Then forge makes that automatic a wizard with next/back/finish buttons. > Then from the logic point of view. It works 100% as if would do if there was just 1 page with all the inputs on the same page. So validation / listeners and so on all react. > The idea is just to allow the end user to much easier break this up into steps that makes the command better to use for end users. You may on the first page to have ui fields that take in some mandatory fields, and then on page 2 some fields that are related together in some way, and then on page 3 yet another group of related options. > You should also be able to configure the title of each page in that steps. So maybe you can in the initiizeUI method do: > {code} > builder.add(one).add(to).next().add(three).add(four).next().add(five); > {code} > Notice how we use next to tell forge that we want the following inputs on the next page. > Or maybe you can specify the title also as: > {code} > builder.add(one).add(to).nextWithTitle("Configure foo stuff").add(three).add(four).nextWithTitle("Configure bar stuff").add(five); > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2615) Forge addon - From one command be able to easily split into a wizard with N pages

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2615?page=com.atlassian.jira.plugin... ] George Gastaldi updated FORGE-2615: ----------------------------------- Fix Version/s: 3.x Future > Forge addon - From one command be able to easily split into a wizard with N pages > --------------------------------------------------------------------------------- > > Key: FORGE-2615 > URL: https://issues.jboss.org/browse/FORGE-2615 > Project: Forge > Issue Type: Feature Request > Components: UI - API > Affects Versions: 3.0.0.CR1 > Reporter: Claus Ibsen > Fix For: 3.x Future > > > Problem > When you build commands in forge that you want to be like a wizard, with 3 pages, where you on page 1 have 3 inputs, on page 2 4 inputs, and on page 3 2 inputs. Then today you need to build that in multiple classes with UIStep and initialize the ui for each step, and put them all together and whatnot. > This seems sometimes a bit too much for those simpler commands, where basically you wish you could write all that in just *one* java class. And then tell forge to split the UI elements into 3 pages, and tell it which UI elements go into what page. Then forge makes that automatic a wizard with next/back/finish buttons. > Then from the logic point of view. It works 100% as if would do if there was just 1 page with all the inputs on the same page. So validation / listeners and so on all react. > The idea is just to allow the end user to much easier break this up into steps that makes the command better to use for end users. You may on the first page to have ui fields that take in some mandatory fields, and then on page 2 some fields that are related together in some way, and then on page 3 yet another group of related options. > You should also be able to configure the title of each page in that steps. So maybe you can in the initiizeUI method do: > {code} > builder.add(one).add(to).next().add(three).add(four).next().add(five); > {code} > Notice how we use next to tell forge that we want the following inputs on the next page. > Or maybe you can specify the title also as: > {code} > builder.add(one).add(to).nextWithTitle("Configure foo stuff").add(three).add(four).nextWithTitle("Configure bar stuff").add(five); > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2615) Forge addon - From one command be able to easily split into a wizard with N pages

by Claus Ibsen (JIRA)

[ https://issues.jboss.org/browse/FORGE-2615?page=com.atlassian.jira.plugin... ] Claus Ibsen commented on FORGE-2615: ------------------------------------ >From the chat today with ggastaldi [15:10:53] <davsclaus> one thing i thought of this morning that would be nice [15:11:08] <davsclaus> was having 1 class being able to have the ui elements and the execute [15:11:10] <davsclaus> as today [15:11:17] <davsclaus> but being able to mark some of the uis [15:11:18] ggrzybek is now known as ggrzybek_bbl [15:11:20] <davsclaus> to be on page 2, 3 etc [15:11:29] <davsclaus> and then forge automatic turn that into a wizard with next/back [15:11:47] <davsclaus> so you dont have to move it into new UIStep classes and whatnot [15:11:51] <davsclaus> but can keep it all in 1 file [15:11:59] <@gastaldi> hmm [15:12:02] <davsclaus> for those simpler commands where [15:12:10] <davsclaus> you start with 3-4 ui\s [15:12:17] <davsclaus> and then add some more and then you have 8 or so [15:12:26] <davsclaus> and find out it makes the ui better if it was 2 pages [15:12:26] <@gastaldi> right, I think we can have a command that splits that into multiple UISteps internally [15:12:32] <davsclaus> yep [15:13:25] <@gastaldi> or a fluent language builder [15:13:49] <davsclaus> yeah [15:13:55] <@gastaldi> something like: Command.named("").having(UIInput, UIInput) [15:14:15] <davsclaus> builder.add(one).add(to).next().add(three).add(four).next().add(five); [15:14:27] <davsclaus> in that initializeUI method [15:14:31] <davsclaus> where you add the ui elements [15:14:34] <@gastaldi> ah you mean the UIBuilder [15:14:56] <davsclaus> yeah [15:14:58] <@gastaldi> hmm [15:15:13] <davsclaus> the pain today is to break up your command into N steps in the wizard [15:15:18] <@gastaldi> I see [15:15:23] <davsclaus> for simpler uis that is just straight line [15:15:37] <davsclaus> i can understand the complex ones you need more code and to code in the next() etc [15:15:44] <davsclaus> but for 90% ui's [15:15:54] <davsclaus> its N options you want to show the users [15:15:56] <davsclaus> but not all at once [15:16:02] <davsclaus> to not overload/confuse the user [15:16:07] <davsclaus> but spread out in N pages [15:16:21] <davsclaus> having all that in 1 java file [15:16:27] <@gastaldi> what about the conditions of showing an Input on a Nth page? [15:16:27] <davsclaus> makes it easier to code and "overview" [15:16:46] <davsclaus> from forge pov it is as if all the options are on the same page [15:16:56] <@gastaldi> right, I see [15:16:59] <davsclaus> but imageing people dont have big monitors [15:17:15] <davsclaus> so somehow it automatic overflow [15:17:27] <davsclaus> that can work for the simpler cases [15:17:38] <davsclaus> if you need conditional and branches, or whatnot [15:17:41] <davsclaus> then you can code it [15:18:30] <@gastaldi> by overflow you mean automatically adding a vertical scroll bar to the Wizard panel? [15:19:02] <davsclaus> if you add to many options to a command then today it will show a dialog [15:19:06] <davsclaus> that cannot fit the screen [15:19:10] <davsclaus> an you cannot see all the options [15:19:15] <davsclaus> and the next / finish button either [15:19:29] <davsclaus> that is okay if you keep to max 20-30 options etc [15:19:36] <davsclaus> but that happens seldom [15:19:40] <@gastaldi> in any IDE? or is that just in Eclipse? [15:19:45] <davsclaus> any of them [15:19:52] <@gastaldi> gotcha, that looks like a bug [15:20:06] <davsclaus> i dont think anyone builds ui like that [15:20:15] <davsclaus> we only see it in those camel wizards with camel endpoints [15:20:22] <davsclaus> where you have maybe 90+ options [15:20:37] <davsclaus> and we do not want 90 on one page either [15:20:45] <davsclaus> so that is why we have that dynamic wizard with the camel [15:20:46] <@gastaldi> right. What if you could split these options into fine grained commands? [15:20:53] <davsclaus> where we compute how many pages and all that [15:21:07] <davsclaus> i cannot its 100% dynamic [15:21:12] <@gastaldi> Right [15:21:23] <davsclaus> that is okay, its all the other commands i talk about really [15:21:31] <davsclaus> we often have commands with 4-10 options [15:21:36] <davsclaus> but would like 2 or 3 pages [15:21:42] <davsclaus> instead of 1 [15:21:50] <davsclaus> and today i have to code a fair bit to do that [15:21:56] <@gastaldi> I see [15:21:58] <davsclaus> hence why i would love to keep it in 1 java file [15:22:10] <@gastaldi> right [15:22:15] <davsclaus> and just tell forge that these X inputs = page 1, these Y inputs = page 2 [15:22:34] <@gastaldi> or have Forge automatically calculate that for you [15:22:36] <davsclaus> and optionally be able to set the title for each page as well [15:22:39] <@gastaldi> like, 10 elements/page [15:22:45] <davsclaus> yeah that too [15:23:02] <davsclaus> but often you may want only these 3 together as they are kinda grouped [15:23:04] <davsclaus> and then on next page [15:23:06] <@gastaldi> hmm, that's something to think about, would you mind JIRAing this? [15:23:14] <davsclaus> ok > Forge addon - From one command be able to easily split into a wizard with N pages > --------------------------------------------------------------------------------- > > Key: FORGE-2615 > URL: https://issues.jboss.org/browse/FORGE-2615 > Project: Forge > Issue Type: Feature Request > Components: UI - API > Affects Versions: 3.0.0.CR1 > Reporter: Claus Ibsen > > Problem > When you build commands in forge that you want to be like a wizard, with 3 pages, where you on page 1 have 3 inputs, on page 2 4 inputs, and on page 3 2 inputs. Then today you need to build that in multiple classes with UIStep and initialize the ui for each step, and put them all together and whatnot. > This seems sometimes a bit too much for those simpler commands, where basically you wish you could write all that in just *one* java class. And then tell forge to split the UI elements into 3 pages, and tell it which UI elements go into what page. Then forge makes that automatic a wizard with next/back/finish buttons. > Then from the logic point of view. It works 100% as if would do if there was just 1 page with all the inputs on the same page. So validation / listeners and so on all react. > The idea is just to allow the end user to much easier break this up into steps that makes the command better to use for end users. You may on the first page to have ui fields that take in some mandatory fields, and then on page 2 some fields that are related together in some way, and then on page 3 yet another group of related options. > You should also be able to configure the title of each page in that steps. So maybe you can in the initiizeUI method do: > {code} > builder.add(one).add(to).next().add(three).add(four).next().add(five); > {code} > Notice how we use next to tell forge that we want the following inputs on the next page. > Or maybe you can specify the title also as: > {code} > builder.add(one).add(to).nextWithTitle("Configure foo stuff").add(three).add(four).nextWithTitle("Configure bar stuff").add(five); > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2615) Forge addon - From one command be able to easily split into a wizard with N pages

by Claus Ibsen (JIRA)

Claus Ibsen created FORGE-2615: ---------------------------------- Summary: Forge addon - From one command be able to easily split into a wizard with N pages Key: FORGE-2615 URL: https://issues.jboss.org/browse/FORGE-2615 Project: Forge Issue Type: Feature Request Components: UI - API Affects Versions: 3.0.0.CR1 Reporter: Claus Ibsen Problem When you build commands in forge that you want to be like a wizard, with 3 pages, where you on page 1 have 3 inputs, on page 2 4 inputs, and on page 3 2 inputs. Then today you need to build that in multiple classes with UIStep and initialize the ui for each step, and put them all together and whatnot. This seems sometimes a bit too much for those simpler commands, where basically you wish you could write all that in just *one* java class. And then tell forge to split the UI elements into 3 pages, and tell it which UI elements go into what page. Then forge makes that automatic a wizard with next/back/finish buttons. Then from the logic point of view. It works 100% as if would do if there was just 1 page with all the inputs on the same page. So validation / listeners and so on all react. The idea is just to allow the end user to much easier break this up into steps that makes the command better to use for end users. You may on the first page to have ui fields that take in some mandatory fields, and then on page 2 some fields that are related together in some way, and then on page 3 yet another group of related options. You should also be able to configure the title of each page in that steps. So maybe you can in the initiizeUI method do: {code} builder.add(one).add(to).next().add(three).add(four).next().add(five); {code} Notice how we use next to tell forge that we want the following inputs on the next page. Or maybe you can specify the title also as: {code} builder.add(one).add(to).nextWithTitle("Configure foo stuff").add(three).add(four).nextWithTitle("Configure bar stuff").add(five); {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2614) MavenModelResource.getModel() should return a cloned version of the underlying model

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2614?page=com.atlassian.jira.plugin... ] George Gastaldi closed FORGE-2614. ---------------------------------- Resolution: Done > MavenModelResource.getModel() should return a cloned version of the underlying model > ------------------------------------------------------------------------------------ > > Key: FORGE-2614 > URL: https://issues.jboss.org/browse/FORGE-2614 > Project: Forge > Issue Type: Enhancement > Components: Build Tools - Maven > Affects Versions: 3.0.0.CR1 > Reporter: George Gastaldi > Assignee: George Gastaldi > Fix For: 3.0.0.CR2 > > > The model returned in {{MavenModelResource.getModel()}} should be cloned, so changes in model will only work when setModel() is called. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2614) MavenModelResource.getModel() should return a cloned version of the underlying model

by George Gastaldi (JIRA)

George Gastaldi created FORGE-2614: -------------------------------------- Summary: MavenModelResource.getModel() should return a cloned version of the underlying model Key: FORGE-2614 URL: https://issues.jboss.org/browse/FORGE-2614 Project: Forge Issue Type: Enhancement Components: Build Tools - Maven Affects Versions: 3.0.0.CR1 Reporter: George Gastaldi Assignee: George Gastaldi Fix For: 3.0.0.CR2 The model returned in {{MavenModelResource.getModel()}} should be cloned, so changes in model will only work when setModel() is called. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (FORGE-440) A pom.xml which contains comments loses all of them after Forge operates on it.

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-440?page=com.atlassian.jira.plugin.... ] Lincoln Baxter III commented on FORGE-440: ------------------------------------------ George is awesome and knocked out the problem handily :) Thank you for prodding us to take action on this issue again! > A pom.xml which contains comments loses all of them after Forge operates on it. > ------------------------------------------------------------------------------- > > Key: FORGE-440 > URL: https://issues.jboss.org/browse/FORGE-440 > Project: Forge > Issue Type: Bug > Components: Build Tools - Maven > Affects Versions: 1.0.6.Final > Environment: HEAD > Reporter: Pete Muir > Assignee: George Gastaldi > Fix For: 3.0.0.CR2 > > Attachments: pomComments.png > > > Also looses formatting, but this is less of an issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2613) Upgrade to Furnace 2.23.3.Final

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2613?page=com.atlassian.jira.plugin... ] George Gastaldi closed FORGE-2613. ---------------------------------- Resolution: Done > Upgrade to Furnace 2.23.3.Final > ------------------------------- > > Key: FORGE-2613 > URL: https://issues.jboss.org/browse/FORGE-2613 > Project: Forge > Issue Type: Component Upgrade > Components: Furnace (Container) > Affects Versions: 3.0.0.CR1 > Reporter: George Gastaldi > Assignee: George Gastaldi > Priority: Minor > Fix For: 3.0.0.CR2 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2613) Upgrade to Furnace 2.23.3.Final

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2613?page=com.atlassian.jira.plugin... ] George Gastaldi updated FORGE-2613: ----------------------------------- Priority: Minor (was: Major) > Upgrade to Furnace 2.23.3.Final > ------------------------------- > > Key: FORGE-2613 > URL: https://issues.jboss.org/browse/FORGE-2613 > Project: Forge > Issue Type: Component Upgrade > Components: Furnace (Container) > Affects Versions: 3.0.0.CR1 > Reporter: George Gastaldi > Assignee: George Gastaldi > Priority: Minor > Fix For: 3.0.0.CR2 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

forge-issues March 2016