[JBoss JIRA] (FORGE-2473) Webhook Test
by Vlastimil Eliáš (JIRA)
Vlastimil Eliáš created FORGE-2473:
--------------------------------------
Summary: Webhook Test
Key: FORGE-2473
URL: https://issues.jboss.org/browse/FORGE-2473
Project: Forge
Issue Type: Quality Risk
Environment:
*Location*: http://forge.jboss.org/
*User-Agent*: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0
*Screen Resolution*: 1680 x 1050
Reporter: Vlastimil Eliáš
test
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (FORGE-2469) Getting a design pattern right for add commands
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/FORGE-2469?page=com.atlassian.jira.plugin... ]
Antonio Goncalves commented on FORGE-2469:
------------------------------------------
19:58:21 gastaldi In order to make that possible, I think we need to model them as decorators
19:58:56 gastaldi Or create proxies for these interfaces, which I dont like personally
20:00:11 gastaldi We can have an AbstractUIInputDelegate
20:00:39 agoncal gastaldi Hum..... decorators..... could be a good idea actually
20:00:50 agoncal It adds extra behavior to a UIComponent
20:00:56 gastaldi Yes
20:01:09 agoncal Not bad at all actually
20:01:23 gastaldi I want to make that interface extend UIInput, but I don't want people to extend the impl class
20:02:02 gastaldi The UIInput original implementation I mean
20:03:39 gastaldi So we'll have a interface TargetPackage extends UIInput<String>
20:04:14 gastaldi And a class TargetPackageImpl extends AbstractUIInputDelegate<String> extends TargetPackage
20:04:28 agoncal And that would be the decorator ?
20:04:34 gastaldi Yes
20:04:56 gastaldi It will take the original UIInput in the constructor
20:05:04 agoncal And same question : what if we need to "customize" the behavior of targetClass ?
20:05:22 gastaldi How so?
20:05:43 agoncal Let's say :
20:06:11 agoncal 1) targetClass in java-add-method points at *all* the classes in the project
20:06:48 agoncal 2) targetClass in jpa-add-lifecycle method point at *just* @Entity classes
20:07:02 gastaldi That could be defined as methods in the TargetPackage interface
20:07:11 agoncal Both are implementation of TargetClass interface
20:07:41 agoncal But different implementation.... or different decorator actually
20:08:18 gastaldi JPATargetClass?
20:08:26 agoncal Too restrictive
20:08:32 gastaldi Agreed
20:08:49 agoncal We are coming back to the inheritance model we want to leave
20:08:56 gastaldi Yes
20:09:44 gastaldi Well. You could do that in the initializeUI method of your command
20:11:09 gastaldi Basically by having a interface TargetPackage extends UIInput<String> we are releasing the burden of the developer to remember which UIInput to use in this case
20:11:49 gastaldi All the necessary methods are there, and they are populated as they are meant to be
20:11:52 agoncal gastaldi Yes, I think it's a better compromise : use the initializeUI method to customize the target package or target class
20:12:30 gastaldi agoncal: yes, because that is a very specific scenario (only @Entities)
20:13:22 agoncal gastaldi Hum... not so sure because we could be very precise then faces-add-method, servlet-add-method....
20:13:44 agoncal and have several targetClass "implementation"
20:14:00 agoncal But basically, this will cover most of the cases, and as you say, ease the life of new comers
20:14:46 gastaldi Yes, this won't replace what we already have, just ease the life as you said
> Getting a design pattern right for add commands
> -----------------------------------------------
>
> Key: FORGE-2469
> URL: https://issues.jboss.org/browse/FORGE-2469
> Project: Forge
> Issue Type: Sub-task
> Components: Java EE
> Affects Versions: 2.19.0.Final
> Reporter: Antonio Goncalves
> Fix For: 2.x Future
>
>
> The {{new}} commands are straight forward, we just create a new artifact (mostly classes in the Java EE addon). {{add}} commands are meant to add code to existing code. So all the add}} commands have a {{targetClass}} attribute. The {{targetClass}} points to the current class, or can point to a different one.
> The algorithm to get the {{targetClass}} is very different from command to command (see below). It would be very helpfull to find a generic design pattern that could be applicable to most of the {{add}} commands.
> {code:title=JavaEqualsHashcodeCommand}
> @Override
> public void initializeUI(UIBuilder builder) throws Exception
> {
> (...)
> UISelection<Object> initialSelection = uiContext.getInitialSelection();
> if (initialSelection.get() instanceof JavaResource)
> {
> targetClass.setValue((JavaResource) initialSelection.get());
> }
> targetClass.setValueChoices(projectOperations.getProjectClasses(project));
> @Override
> public Result execute(UIExecutionContext context) throws Exception
> {
> (...)
> if (targetClass.hasMethodSignature("equals", Object.class))
> {
> if (prompt.promptBoolean("Class already has an equals method. Would you like it to be overwritten?"))
> {code}
> {code:title=CDIAddInjectionPointCommand}
> private void setupTargetClasses(UIContext uiContext)
> {
> UISelection<FileResource<?>> selection = uiContext.getInitialSelection();
> Project project = getSelectedProject(uiContext);
> final List<JavaResource> classes = cdiOperations.getProjectInjectionPointBeans(project);
> targetClass.setValueChoices(classes);
> int idx = -1;
> if (!selection.isEmpty())
> {
> idx = classes.indexOf(selection.get());
> }
> if (idx == -1)
> {
> idx = classes.size() - 1;
> }
> if (idx != -1)
> {
> targetClass.setDefaultValue(classes.get(idx));
> }
> }
> {code}
> {code:title=CDIAddObserverMethodCommand}
> private void setupTargetClass(UIContext uiContext, Project project)
> {
> UISelection<Resource<?>> resource = uiContext.getInitialSelection();
> if (resource.get() instanceof JavaResource)
> {
> targetClass.setDefaultValue((JavaResource) resource.get());
> }
> targetClass.setValueChoices(projectOperations.getProjectClasses(project));
> }
> {code}
> {code:title=FacesNewValidatorMethodCommand}
> public void initializeUI(UIBuilder builder) throws Exception
> {
> Object selection = builder.getUIContext().getInitialSelection().get();
> if (selection instanceof JavaResource)
> {
> targetClass.setDefaultValue((JavaResource) selection);
> }
> builder.add(targetClass).add(named);
> }
> @Override
> public void validate(UIValidationContext validator)
> {
> try
> {
> JavaClassSource source = targetClass.getValue().reify(JavaResource.class).getJavaType();
> (...)
> }
> catch (FileNotFoundException e)
> {
> validator.addValidationError(targetClass, "Target Java class not found.");
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[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:
------------------------------------------
Yes, for the named and target package (and others if needed).
{code}
public interface Named extends UIInput<String>
public interface TargetPackage extends UIInput<String>
public interface TargetClass extends UISelectOne<JavaResource>
public interface Overwrite extends UIInput<Boolean>
@Produces @Typed(Named.class) public Named produceNamed()
@Produces @Typed(TargetPackage.class) public TargetPackage produceTargetPackage()
@Produces public TargetClass produceTargetClass()
@Produces public Overwrite produceTargetClass()
@Inject private TargetPackage targetPackage ;
@Inject private TargetClass targetClass ;
@Inject private Named named ;
@Inject private Overwrite overwrite ;
{code}
PS : that's when we realize that {{Named}} is a bit confusing ;o)
> 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.4.11#64026)
10 years, 8 months
[JBoss JIRA] (FORGE-2470) List of JIRAs Antoine and Antonio would like to get fixed for their Devoxx Univeristy (by mid-November 2015)
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/FORGE-2470?page=com.atlassian.jira.plugin... ]
Antonio Goncalves updated FORGE-2470:
-------------------------------------
Description:
Here are a few JIRAs that would get to be implemented so it makes the talk smoother :
* [FORGE-2374] - Being able to generate an abstract or final Java class implementing serialiazable or not
* [ROASTER-51] - Add interface or abstract class should implement inherited methods
* [FORGE-2466] - Cannot use '~' in most of the command parameters
* [FORGE-2099] - scaffold-generate command should have a --targetPackage attribute
* [FORGE-1808] - Being able to have inheritance in CDI
* [FORGE-1478] - Being able to have inheritance in JPA
* [FORGE-1594] - Being able to create a new JSF View
* [FORGE-2081] - Being able to add a new CDI event producer to an existing class
* [FORGE-2079] - Being able to add a new CDI producer field
* [FORGE-2225] - Being able to add a new CDI producer method to an existing class
* [FORGE-2468] - Being able to add methods to an existing JSF backing bean
* [FORGE-2318] - Being able to setup a logger
was:
Here are a few JIRAs that would get to be implemented so it makes the talk smoother :
* [ROASTER-51] - Add interface or abstract class should implement inherited methods
* [FORGE-1808] - Being able to have inheritance in CDI
* [FORGE-1478] - Being able to have inheritance in JPA
* [FORGE-1594] - Being able to create a new JSF View
* [FORGE-2081] - Being able to add a new CDI event producer to an existing class
* [FORGE-2079] - Being able to add a new CDI producer field
* [FORGE-2099] - scaffold-generate command should have a --targetPackage attribute
* [FORGE-2225] - Being able to add a new CDI producer method to an existing class
* [FORGE-2318] - Being able to setup a logger
* [FORGE-2374] - Being able to generate an abstract or final Java class implementing serialiazable or not
* [FORGE-2466] - Cannot use '~' in most of the command parameters
* [FORGE-2468] - Being able to add methods to an existing JSF backing bean
> List of JIRAs Antoine and Antonio would like to get fixed for their Devoxx Univeristy (by mid-November 2015)
> ------------------------------------------------------------------------------------------------------------
>
> Key: FORGE-2470
> URL: https://issues.jboss.org/browse/FORGE-2470
> Project: Forge
> Issue Type: Task
> Components: Brainstorming
> Affects Versions: 2.19.0.Final
> Reporter: Antonio Goncalves
> Fix For: 2.x Future
>
>
> Here are a few JIRAs that would get to be implemented so it makes the talk smoother :
> * [FORGE-2374] - Being able to generate an abstract or final Java class implementing serialiazable or not
> * [ROASTER-51] - Add interface or abstract class should implement inherited methods
> * [FORGE-2466] - Cannot use '~' in most of the command parameters
> * [FORGE-2099] - scaffold-generate command should have a --targetPackage attribute
> * [FORGE-1808] - Being able to have inheritance in CDI
> * [FORGE-1478] - Being able to have inheritance in JPA
> * [FORGE-1594] - Being able to create a new JSF View
> * [FORGE-2081] - Being able to add a new CDI event producer to an existing class
> * [FORGE-2079] - Being able to add a new CDI producer field
> * [FORGE-2225] - Being able to add a new CDI producer method to an existing class
> * [FORGE-2468] - Being able to add methods to an existing JSF backing bean
> * [FORGE-2318] - Being able to setup a logger
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (FORGEPLUGINS-211) Being able to setup a logger
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGEPLUGINS-211?page=com.atlassian.jira.... ]
George Gastaldi moved FORGE-2318 to FORGEPLUGINS-211:
-----------------------------------------------------
Project: Forge Plugins/Addons (was: Forge)
Key: FORGEPLUGINS-211 (was: FORGE-2318)
Component/s: (was: Java EE)
Affects Version/s: (was: 2.16.0.Final)
Fix Version/s: (was: 2.x Future)
> Being able to setup a logger
> ----------------------------
>
> Key: FORGEPLUGINS-211
> URL: https://issues.jboss.org/browse/FORGEPLUGINS-211
> Project: Forge Plugins/Addons
> Issue Type: Feature Request
> Reporter: Antonio Goncalves
>
> It would be good to have a few commands to setup a logger and inject it into bean. And because logs are a pain (too many frameworks) it would help to have a {{logger-setup}} command. It will create the needed dependency (in the {{pom.xml}}) and add some basic configuration (eg. {{logback.xml}}) and why not, create a producer method so it can be injected.
> A basic logger would use JUL :
> {code}
> logger-setup
> {code}
> Or we could choose a provider and a version
> {code}
> logger-setup --provider LOG4J --version 4.1
> {code}
> The different logging frameworks are :
> * JUL (out of the box, no need to have a dependency)
> * LOG4J2 : http://logging.apache.org/log4j/2.x/
> * LOG4J1 : http://logging.apache.org/log4j/2.x/manual/migration.html
> * SLF4J : http://www.slf4j.org/
> * COMMONS_LOGGING : http://commons.apache.org/proper/commons-logging/
> * LOGBACK : http://logback.qos.ch/
> Setting up a logger would add the right dependency but also generate a producer that would look like that, and therefore could be injected :
> {code}
> public class LoggingProducer {
> @Produces
> public Logger produceLogger(InjectionPoint injectionPoint) {
> return Logger.getLogger(injectionPoint.getMember().getDeclaringClass().getName());
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (FORGE-2318) Being able to setup a logger
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-2318?page=com.atlassian.jira.plugin... ]
George Gastaldi updated FORGE-2318:
-----------------------------------
Parent: (was: FORGE-1926)
Issue Type: Feature Request (was: Sub-task)
> Being able to setup a logger
> ----------------------------
>
> Key: FORGE-2318
> URL: https://issues.jboss.org/browse/FORGE-2318
> Project: Forge
> Issue Type: Feature Request
> Components: Java EE
> Reporter: Antonio Goncalves
> Fix For: 2.x Future
>
>
> It would be good to have a few commands to setup a logger and inject it into bean. And because logs are a pain (too many frameworks) it would help to have a {{logger-setup}} command. It will create the needed dependency (in the {{pom.xml}}) and add some basic configuration (eg. {{logback.xml}}) and why not, create a producer method so it can be injected.
> A basic logger would use JUL :
> {code}
> logger-setup
> {code}
> Or we could choose a provider and a version
> {code}
> logger-setup --provider LOG4J --version 4.1
> {code}
> The different logging frameworks are :
> * JUL (out of the box, no need to have a dependency)
> * LOG4J2 : http://logging.apache.org/log4j/2.x/
> * LOG4J1 : http://logging.apache.org/log4j/2.x/manual/migration.html
> * SLF4J : http://www.slf4j.org/
> * COMMONS_LOGGING : http://commons.apache.org/proper/commons-logging/
> * LOGBACK : http://logback.qos.ch/
> Setting up a logger would add the right dependency but also generate a producer that would look like that, and therefore could be injected :
> {code}
> public class LoggingProducer {
> @Produces
> public Logger produceLogger(InjectionPoint injectionPoint) {
> return Logger.getLogger(injectionPoint.getMember().getDeclaringClass().getName());
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (FORGE-2374) Being able to generate an abstract or final Java class implementing serializable or not
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-2374?page=com.atlassian.jira.plugin... ]
George Gastaldi updated FORGE-2374:
-----------------------------------
Summary: Being able to generate an abstract or final Java class implementing serializable or not (was: Being able to generate an abstract or final Java class implementing serialiazable or not)
> Being able to generate an abstract or final Java class implementing serializable or not
> ---------------------------------------------------------------------------------------
>
> Key: FORGE-2374
> URL: https://issues.jboss.org/browse/FORGE-2374
> Project: Forge
> Issue Type: Sub-task
> Components: UI - API
> Affects Versions: 2.16.2.Final
> Reporter: Antonio Goncalves
> Labels: starter
> Fix For: 2.19.1.Final
>
>
> At the moment the {{java-new-class}} only has a {{targetPackage}} and {{named}} parameter. It would be good to be able to generate abstract or final classes with serializable interfaces
> {code}
> $ java-new-class --named MyClass --isAbstract
> public abstract class MyClass {
> }
> {code}
> Or final :
> {code}
> $ java-new-class --named MyClass --isFinal
> public final class MyClass {
> }
> {code}
> What we have to be careful is that a class cannot be abstract and final. So the following is illegal :
> {code}
> $ java-new-class --named MyClass --isFinal --isAbstract --serializable
> public final abstract class MyClass implements Serializable {
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (FORGE-2374) Being able to generate an abstract or final Java class implementing serializable or not
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-2374?page=com.atlassian.jira.plugin... ]
George Gastaldi closed FORGE-2374.
----------------------------------
Fix Version/s: 2.19.1.Final
(was: 2.x Future)
Assignee: George Gastaldi
Resolution: Done
> Being able to generate an abstract or final Java class implementing serializable or not
> ---------------------------------------------------------------------------------------
>
> Key: FORGE-2374
> URL: https://issues.jboss.org/browse/FORGE-2374
> Project: Forge
> Issue Type: Sub-task
> Components: UI - API
> Affects Versions: 2.16.2.Final
> Reporter: Antonio Goncalves
> Assignee: George Gastaldi
> Labels: starter
> Fix For: 2.19.1.Final
>
>
> At the moment the {{java-new-class}} only has a {{targetPackage}} and {{named}} parameter. It would be good to be able to generate abstract or final classes with serializable interfaces
> {code}
> $ java-new-class --named MyClass --isAbstract
> public abstract class MyClass {
> }
> {code}
> Or final :
> {code}
> $ java-new-class --named MyClass --isFinal
> public final class MyClass {
> }
> {code}
> What we have to be careful is that a class cannot be abstract and final. So the following is illegal :
> {code}
> $ java-new-class --named MyClass --isFinal --isAbstract --serializable
> public final abstract class MyClass implements Serializable {
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months