May 2015 - forge-issues - Jboss List Archives

[JBoss JIRA] (FORGE-2337) Make promptBoolean() print the message and assume the default value in shell.

by Ondrej Zizka (JIRA)

Ondrej Zizka created FORGE-2337: ----------------------------------- Summary: Make promptBoolean() print the message and assume the default value in shell. Key: FORGE-2337 URL: https://issues.jboss.org/browse/FORGE-2337 Project: Forge Issue Type: Enhancement Components: UI - API, UI - Shell Affects Versions: 2.15.2.Final Reporter: Ondrej Zizka Please make prompt() to print the text and assume the … [View More]

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2336) UIValidationContext#addValidationWarning() doesn't show up in the shell

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/FORGE-2336?page=com.atlassian.jira.plugin... ] Ondrej Zizka reassigned FORGE-2336: ----------------------------------- Assignee: Ondrej Zizka > UIValidationContext#addValidationWarning() doesn't show up in the shell > ----------------------------------------------------------------------- > > Key: FORGE-2336 > URL: https://issues.jboss.org/browse/FORGE-2336 > Project: Forge > … [View More]

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2336) UIValidationContext#addValidationWarning() doesn't show up in the shell

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/FORGE-2336?page=com.atlassian.jira.plugin... ] Ondrej Zizka reassigned FORGE-2336: ----------------------------------- Assignee: George Gastaldi (was: Ondrej Zizka) > UIValidationContext#addValidationWarning() doesn't show up in the shell > ----------------------------------------------------------------------- > > Key: FORGE-2336 > URL: https://issues.jboss.org/browse/FORGE-2336 > Project: … [View More]

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2336) UIValidationContext#addValidationWarning() doesn't show up in the shell

by Ondrej Zizka (JIRA)

Ondrej Zizka created FORGE-2336: ----------------------------------- Summary: UIValidationContext#addValidationWarning() doesn't show up in the shell Key: FORGE-2336 URL: https://issues.jboss.org/browse/FORGE-2336 Project: Forge Issue Type: Enhancement Components: UI - API Affects Versions: 2.15.2.Final Reporter: Ondrej Zizka Test: {code:java} @Override public void validate(… [View More]

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2297) Support newer versions of Gradle

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2297?page=com.atlassian.jira.plugin... ] George Gastaldi updated FORGE-2297: ----------------------------------- Status: Open (was: Pull Request Sent) Git Pull Request: (was: https://github.com/forge/addon-gradle/pull/3) > Support newer versions of Gradle > -------------------------------- > > Key: FORGE-2297 > URL: https://issues.jboss.org/browse/FORGE-2297 > Project: … [View More]

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2297) Support newer versions of Gradle

by Daniel Cunha (soro) (JIRA)

[ https://issues.jboss.org/browse/FORGE-2297?page=com.atlassian.jira.plugin... ] Daniel Cunha (soro) updated FORGE-2297: --------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/forge/addon-gradle/pull/3 > Support newer versions of Gradle > -------------------------------- > > Key: FORGE-2297 > URL: https://issues.jboss.org/browse/FORGE-2297 > Project: … [View More]

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2335) Enhancements on the Shell progress monitor

by George Gastaldi (JIRA)

George Gastaldi created FORGE-2335: -------------------------------------- Summary: Enhancements on the Shell progress monitor Key: FORGE-2335 URL: https://issues.jboss.org/browse/FORGE-2335 Project: Forge Issue Type: Enhancement Components: UI - Shell Affects Versions: 2.16.1.Final Reporter: George Gastaldi Fix For: 2.x Future The current output when using the UIProgressMonitor in … [View More]shell is: {code} ***INFO*** Executing Rules: :Analyze Java(4%) Time until next Rule: 2 minutes, 7 seconds [24/1229] ... ***INFO*** Executing Rules: :Analyze Java(8%) Time until next Rule: 1 minutes, 34 seconds [24/1229] ... ***INFO*** Executing Rules: :Analyze Java(12%) Time until next Rule: 1 minutes, 7 seconds [24/1229] ... ***INFO*** Executing Rules: :Analyze Java(16%) Time until next Rule: 1 minutes, 3 seconds [24/1229] ... ***INFO*** Executing Rules: :Analyze Java(20%) Time until next Rule: 55 seconds [24/1229] ... ***INFO*** Executing Rules: :Analyze Java(24%) Time until next Rule: 53 seconds [24/1229] ... ***INFO*** Executing Rules: :Analyze Java(29%) Time until next Rule: 53 seconds [24/1229] ... ***INFO*** Executing Rules: :Analyze Java(33%) Time until next Rule: 49 seconds [24/1229] ... ***INFO*** Executing Rules: :Analyze Java(37%) Time until next Rule: 46 seconds [24/1229] ... ***INFO*** Executing Rules: :Analyze Java(41%) Time until next Rule: 44 seconds [24/1229] ... ***INFO*** Executing Rules: :Analyze Java(45%) Time until next Rule: 40 seconds [24/1229] ... ***INFO*** Executing Rules: :Analyze Java(49%) Time until next Rule: 38 seconds [24/1229] ... ***INFO*** Executing Rules: :Analyze Java(54%) Time until next Rule: 37 seconds [24/1229] ... ***INFO*** Executing Rules: :Analyze Java(58%) Time until next Rule: 33 seconds [24/1229] ... ***INFO*** Executing Rules: :Analyze Java(62%) Time until next Rule: 29 seconds [24/1229] ... ***INFO*** Executing Rules: :Analyze Java(66%) Time until next Rule: 25 seconds [24/1229] ... ***INFO*** Executing Rules: :Analyze Java(70%) Time until next Rule: 22 seconds [24/1229] ... ***INFO*** Executing Rules: :Analyze Java(74%) Time until next Rule: 18 seconds [24/1229] ... ***INFO*** Executing Rules: :Analyze Java(79%) Time until next Rule: 15 seconds [24/1229] ... ***INFO*** Executing Rules: :Analyze Java(83%) Time until next Rule: 12 seconds [24/1229] ... {code} This doesn't look so good in the UI. The following could be done: - add the loading spinner on each progress update - write the progress in a single line The loading spinner could appear by default on long-running tasks in the shell -- This message was sent by Atlassian JIRA (v6.3.15#6346) [View Less]

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2297) Support newer versions of Gradle

by Daniel Cunha (soro) (JIRA)

[ https://issues.jboss.org/browse/FORGE-2297?page=com.atlassian.jira.plugin... ] Daniel Cunha (soro) reassigned FORGE-2297: ------------------------------------------ Assignee: Daniel Cunha (soro) > Support newer versions of Gradle > -------------------------------- > > Key: FORGE-2297 > URL: https://issues.jboss.org/browse/FORGE-2297 > Project: Forge > Issue Type: Bug > Components: Addon Development, … [View More]

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2305) Upgrade to Furnace 2.16.1.Final

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2305?page=com.atlassian.jira.plugin... ] George Gastaldi closed FORGE-2305. ---------------------------------- Fix Version/s: (was: 2.16.1.Final) Resolution: Duplicate Issue Duplicated by FORGE-2311 > Upgrade to Furnace 2.16.1.Final > ------------------------------- > > Key: FORGE-2305 > URL: https://issues.jboss.org/browse/FORGE-2305 > Project: Forge > Issue … [View More]

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2331) Refactor New and Add commands

by Antonio Goncalves (JIRA)

[ https://issues.jboss.org/browse/FORGE-2331?page=com.atlassian.jira.plugin... ] Antonio Goncalves commented on FORGE-2331: ------------------------------------------ agoncal Basically, when you write a command, you need attributes : agoncal named (for most of the commands), targetPackage (for the new commands), targetClass (for the add commands)... agoncal And then you also end up "duplicating" attributes : example the "qualifiers" are used in several CDI commands gastaldi right agoncal … [View More] So the idea was giving up inheritance (AsbtractCDINewCommand, AbstractJPACommand....) in favor of aggragation agoncal And then gastaldi came with an idea agoncal gastaldi your turn ;o) gastaldi my idea was to introduce some classes with the common inputs containing @Inject UIInputxxx and then @Inject the aggregate class in the command gastaldi something like @Inject DefaultCDIInputs inputs; gastaldi and then in the initializeUI you could call inputs.initializeUI(builder) gastaldi and fetch the values agoncal gastaldi But also more specific ones ? Such as @Inject DefaultCDIQualifier, @Inject DefaultJPAField... ? gastaldi that could work too gastaldi hm, maybe we could introduce a "input-only" concept here gastaldi a class that has only injected inputs gastaldi that would save some memory, by lazy-injecting them gastaldi right now, every @Inject in the command is resolved every time a command is executed agoncal And one suggestion was to start with the "qualifiers" attribute (used in several new CDI commands) gastaldi agoncal, what do you mean by that, specifically? agoncal gastaldi Well, if we could start introducing the concept after this release, and if yes, the "qualifiers" attribute could be a good start gastaldi you mean having a separate class for the inputs? agoncal gastaldi Yes gastaldi yeah, we can think about it in the next version. Still needs some thought to become a pattern agoncal gastaldi Ok, let's keep on exchanging on the subject soro I didn't understand this yet. We have some issue of some document to explain about it or will be discussed in future? soro about this "qualifiers" agoncal soro "qualifiers" is just an example agoncal soro Basically, how do you aggregate common attributes into a command soro agoncal, ah... ok! soro nice! > Refactor New and Add commands > ----------------------------- > > Key: FORGE-2331 > URL: https://issues.jboss.org/browse/FORGE-2331 > Project: Forge > Issue Type: Sub-task > Components: Java EE > Affects Versions: 2.16.0.Final > Reporter: Antonio Goncalves > Fix For: 2.x Future > > > {code} > agoncal gastaldi Do you have a moment ? > gastaldi agoncal, sure, what's up? > agoncal gastaldi I'm getting more confident with Forge and I can create more and more commands.... > agoncal but actually, it's xxxNewxxxCommands > agoncal In Forge I see commands to create new classes (artifacts) : CDINewBean, JPANewEntity.... > agoncal And commands to add code to existing classes : JPAAddField, CDIAddInjectionPoint > agoncal I find xxxAddCommands more difficult to write than xxxNewCommands > agoncal For example : > agoncal ServletNewServletCommand extends from AbstractServletNewCommand which extends from AbstractJavaSourceCommand > agoncal AbstractJavaSourceCommand gives me targetPackage, named and overwrite > agoncal I would like to have the same kind of hierarchy to easy my xxxAddCommands development > agoncal Something like : > agoncal ServletAddContextCommand extends from AbstractServletAddCommand which extends from AbstractAddCommand > agoncal And AbstractAddCommand would give me targetClass, named and overwrite > agoncal gastaldi WDYT ? > gastaldi hmmm > gastaldi interesting > gastaldi do all xxxAddCommands have targetClass, named and overwrite? > agoncal gastaldi Yes. You usually want to add something that is named (attribute, method...) into a class (target class) and if it's already there you want to override it > gastaldi hmmm > gastaldi I don't see it as a rule for the Add commands > gastaldi for example, AddDependenciesCommand does not feature that > agoncal Well, the New commands are : targetPackage, named and overwrite and I think it represents most of the cases > agoncal gastaldi are you talking about project-add-dependencies ? > gastaldi yes > agoncal I'm more focused on Java EE code (project-add-dependencies is indeed different) > gastaldi hmm, maybe we don't need to inherit, but have encapsulate these properties > agoncal yes, why not, I'm trying to get as closed to the current model as possible (so it doesn't break anything) > agoncal I would like to be as confident to write a AddCommand than a NewCommand, and at the moment it's not the case > agoncal If there was an AbstractNewCommand and an AbstractAddCommand in just the JavaEE addon, it would make development easier > agoncal (most of the Java EE commands share the same common properties and behaviour) > gastaldi ok, but what about the abstract classes per technology ? > gastaldi are they becoming xxxNewCommands? > agoncal Well, we could have AbstractNewCommand with targetPackage, named and overwrite, and AbstractCDINewCommands for the prerequisite (CDI needs CDISetup) > agoncal And same for the add : > agoncal AbstractAddCommand with targetClass, named and overwrite, and AbstractCDIAddCommands > agoncal .... humm.... > agoncal Both AbstractCDINewCommands and AbstractCDIAddCommands are used for the prerequisite... > gastaldi it's awesome that you found a pattern between these command types > gastaldi but I think that at some point inheritance won't be the answer :) > agoncal gastaldi Thanks to writing the documentation ;o) > agoncal gastaldi Totally agree ! > gastaldi what documentation? > agoncal I feel a bit stuck with inheritance sometimes > agoncal Because Add and New both have a named > gastaldi agoncal, yes, perhaps we need to start looking at encapsulation instead > agoncal Add has a targetClass and New a targetPackage > gastaldi that is a more flexible approach > agoncal Yes ! > agoncal But that might break some current APIs > agoncal (don't know) > gastaldi we could have a class with these common attributes and pass them to the UIBuildder > gastaldi *UIBuilder > agoncal Yes > agoncal As a developper, I really just want to focus on writing the "business logic" of a command and less boiler plate code > gastaldi that's right > gastaldi totally agree > agoncal When writing a Add command I'm happy that the targetPackage is being taking care of > agoncal I also want the same for Add > agoncal (which is not the case at the moment) > gastaldi hmmm > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) [View Less]

9 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

forge-issues May 2015