From bartosz at redhat.com Wed Jan 25 04:20:23 2017 From: bartosz at redhat.com (Bartosz Majsak) Date: Wed, 25 Jan 2017 10:20:23 +0100 Subject: [forge-dev] Testing Forge Addons Message-ID: Hi Forgers ;) First and foremost many thanks for this great tool :) We are working on Arquillian Addon bringing more capabilities as our universe is growing. One thing which has been quite challenging is testing. There are several ways of doing it as one can figure from different addons available out in the wild. I would like to get better understanding of what would be the preferred way of testing an addon. I personally liketestShellapproach as it gives you end-to-end flow and ability to verify the behaviour of what user would do with the tool. This has obvious performance drawbacks, but I believe we could make it more efficient. I have developed small set of testing assertions based on assertjfor verifying the state of a project (e.g. classes or artifacts present). It is still work in progress and I?m eagerly looking for feedback, but eventually I would like to bring it upstream to test harness if that makes sense. You can see how it looks like for example in the test verifying junit test scaffolding . Another problematic aspect is Forge addon deployment - the documentation seems not to reflect the current state and I failed badly trying to create my own at Deployment with assertj bundled. What I ended up with is an Arquillian extension which lets you add dependencies (resolved by Shrinkwrap under the hood) as well as packages by simply using annotations - you can see both in action in the junit test mentioned above. Is it the right way? We can also think about bringing it upstream. Can we improve the docs to show what is required to create proper @Deployment for the addon? As Arquillian Addon is around for quite some time and several folks were involved in it, there is also another way of testing forge commands by using CommandController - can someone point me to the doc or briefly explain what is the difference? Here?s one test from our addon. Cheers, Bartosz. ? From ggastald at redhat.com Wed Jan 25 04:46:56 2017 From: ggastald at redhat.com (George Gastaldi) Date: Wed, 25 Jan 2017 07:46:56 -0200 Subject: [forge-dev] Testing Forge Addons In-Reply-To: References: Message-ID: Hi Bartosz, Welcome! Glad you like Forge as much as we do. Right now we have two approaches to testing an addon UI command: Using the ShellTest class or using CommandController. The main difference is that the later is meant to be UI agnostic tests, whereas the first would test your command in a shell environment only. Each has it's own pros and cons, so a good practice is to write tests for both approaches eg.: https://github.com/forge/core/blob/master/javaee/tests/ src/test/java/org/jboss/forge/addon/javaee/rest/ui/ RestNewEndpointCommandTest.java As for support for AssertJ, that depends on what you add in the AddonArchive returned in the @Deployment method. I think it would be useful to have an annotation-based solution for adding library dependencies/packages to it instead of rewriting the deployment method again. Is anyone opposed to it? As for the Docs, yes, I need to work on that to be more user-friendly. Right now they are dispersed into README files and listed in http://forge.jboss.org/documentation and maybe that's not much useful. A gitbook-like approach would be better in this case I guess. *George Gastaldi* https://onename.com/gastaldi On Wed, Jan 25, 2017 at 7:20 AM, Bartosz Majsak wrote: > Hi Forgers ;) > > First and foremost many thanks for this great tool :) > > We are working on Arquillian Addon > bringing more capabilities as > our universe is growing. One thing which has been quite challenging is > testing. There are several ways of doing it as one can figure from > different addons available out in the wild. > > I would like to get better understanding of what would be the preferred way > of testing an addon. > > I personally liketestShellapproach as it gives you end-to-end flow and > ability to verify the behaviour of what user would do with the tool. This > has obvious performance drawbacks, but I believe we could make it more > efficient. I have developed small set of testing assertions > a1684eb283345d93adeeb0789741/src/test/java/test/integration > /support/assertions> > based on assertjfor verifying the state of a project (e.g. classes or > artifacts present). It is still work in progress and I?m eagerly looking > for feedback, but eventually I would like to bring it upstream to test > harness if that makes sense. You can see how it looks like for example in > the test verifying junit test scaffolding > a1684eb283345d93adeeb0789741/src/test/java/test/integration > /JUnitTestGenerationIntegrationTest.java> > . > > Another problematic aspect is Forge addon deployment - the documentation > seems not to reflect > the > current state and I failed badly trying to create my own at Deployment with > assertj bundled. What I ended up with is an Arquillian extension > a1684eb283345d93adeeb0789741/src/test/java/test/integration/extension> > which lets you add dependencies (resolved by Shrinkwrap under the hood) as > well as packages by simply using annotations - you can see both in action > in the junit test mentioned above. Is it the right way? We can also think > about bringing it upstream. Can we improve the docs to show what is > required to create proper @Deployment for the addon? > > As Arquillian Addon is around for quite some time and several folks were > involved in it, there is also another way of testing forge commands by > using CommandController - can someone point me to the doc or briefly > explain what is the difference? Here?s one test > a1684eb283345d93adeeb0789741/src/test/java/test/integration > /AddArquillianExtensionTest.java#L47> > from our addon. > > Cheers, > Bartosz. > > ? > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev From asotobue at redhat.com Wed Jan 25 09:01:25 2017 From: asotobue at redhat.com (Alex Soto Bueno) Date: Wed, 25 Jan 2017 15:01:25 +0100 Subject: [forge-dev] Dependency check Message-ID: Hi guys, is it necessary to check every time you want to register a dependency if this dependency has been registered previously or not? Or the DependencyFacet takes care of it? Thank you so much. From ggastald at redhat.com Wed Jan 25 09:15:03 2017 From: ggastald at redhat.com (George Gastaldi) Date: Wed, 25 Jan 2017 12:15:03 -0200 Subject: [forge-dev] Dependency check In-Reply-To: References: Message-ID: I believe DependencyFacet already does the checking when you install it, if not, that may be a bug. Can you confirm that it works? *George Gastaldi* https://onename.com/gastaldi On Wed, Jan 25, 2017 at 12:01 PM, Alex Soto Bueno wrote: > Hi guys, is it necessary to check every time you want to register a > dependency if this dependency has been registered previously or not? Or the > DependencyFacet takes care of it? > > Thank you so much. > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > From asotobue at redhat.com Wed Jan 25 10:40:45 2017 From: asotobue at redhat.com (Alex Soto Bueno) Date: Wed, 25 Jan 2017 16:40:45 +0100 Subject: [forge-dev] Required Parameter is ignored although it is set Message-ID: Hello, I have next command: public class AddAlgeronFolderPublisher extends AbstractProjectCommand implements UICommand { @Inject private ProjectFactory projectFactory; @Inject private FacetFactory facetFactory; @Inject @WithAttributes(shortName = 'o', label = "Output Folder", required = true) private UISelectOne outputFolder; @Inject @WithAttributes(shortName = 'c', label = "Contracts Folder") private UISelectOne contractFolder; @Override public UICommandMetadata getMetadata(UIContext context) { return Metadata.from(super.getMetadata(context), getClass()) .category(Categories.create("Algeron")) .name("Arquillian Algeron: Add Folder Publisher") .description("This command registers a Folder Publisher for Algeron"); } @Override public void initializeUI(UIBuilder builder) throws Exception { builder.add(outputFolder).add(contractFolder); contractFolder.setDefaultValue("target/pacts"); } // ...... } When in Forge console I run: arquillian-algeron-add-folder-publisher --output-folder /tmp I got: ***INFO*** Required inputs not satisfied, entering interactive mode ***ERROR*** Output Folder must be specified. But you can see that I am setting the attribute in the command so any idea of why this is failing? From asotobue at redhat.com Wed Jan 25 10:56:16 2017 From: asotobue at redhat.com (Alex Soto Bueno) Date: Wed, 25 Jan 2017 16:56:16 +0100 Subject: [forge-dev] Required Parameter is ignored although it is set In-Reply-To: References: Message-ID: I have found that the error was that instead of using UISelectOne I need to use UIInput since it is the default input type used. But I think that error message should be improved about incompatible types instead of an error that it is not really the error it is happening. WDYT? On Wed, Jan 25, 2017 at 4:40 PM, Alex Soto Bueno wrote: > Hello, > > I have next command: > > public class AddAlgeronFolderPublisher extends AbstractProjectCommand > implements UICommand > { > > @Inject > private ProjectFactory projectFactory; > > @Inject > private FacetFactory facetFactory; > > @Inject > @WithAttributes(shortName = 'o', label = "Output Folder", required = > true) > private UISelectOne outputFolder; > > @Inject > @WithAttributes(shortName = 'c', label = "Contracts Folder") > private UISelectOne contractFolder; > > @Override > public UICommandMetadata getMetadata(UIContext context) > { > return Metadata.from(super.getMetadata(context), getClass()) > .category(Categories.create("Algeron")) > .name("Arquillian Algeron: Add Folder Publisher") > .description("This command registers a Folder Publisher for > Algeron"); > } > > @Override > public void initializeUI(UIBuilder builder) throws Exception > { > builder.add(outputFolder).add(contractFolder); > contractFolder.setDefaultValue("target/pacts"); > } > > // ...... > } > > When in Forge console I run: > > arquillian-algeron-add-folder-publisher --output-folder /tmp > > I got: > > ***INFO*** Required inputs not satisfied, entering interactive mode > ***ERROR*** Output Folder must be specified. > > But you can see that I am setting the attribute in the command so any idea > of why this is failing? > > > > > From asotobue at redhat.com Wed Jan 25 11:06:06 2017 From: asotobue at redhat.com (Alex Soto Bueno) Date: Wed, 25 Jan 2017 17:06:06 +0100 Subject: [forge-dev] Bug on XML indentation? Message-ID: Hi I am generating an XML file in an addon using: XMLParser.toXMLString(xml); The node I am creating is done: xml.getOrCreate("extension at qualifier=" + qualifier) .getOrCreate("property at name=" + key) .text(value); were value is a yaml-like expression. The problem is that the resulting XML is not well indented: provider: folder outputFolder: /tmp/contracts contractsFolder: target/pacts I can understand that YAML thing is not correctly formatted but notice that the closing tag is not correctly indented. Any idea? Alex. From ggastald at redhat.com Wed Jan 25 11:06:53 2017 From: ggastald at redhat.com (George Gastaldi) Date: Wed, 25 Jan 2017 14:06:53 -0200 Subject: [forge-dev] Required Parameter is ignored although it is set In-Reply-To: References: Message-ID: Glad you found the cause. There is a JIRA already asking to provide a more rigid option parsing strategy. Right now if you use UISelectOne and call setValue with a value that is not in its valueChoices list, it will set to null. Keep on Forgin'! *George Gastaldi* https://onename.com/gastaldi On Wed, Jan 25, 2017 at 1:56 PM, Alex Soto Bueno wrote: > I have found that the error was that instead of using UISelectOne I need to > use UIInput since it is the default input type used. But I think that error > message should be improved about incompatible types instead of an error > that it is not really the error it is happening. > > WDYT? > > On Wed, Jan 25, 2017 at 4:40 PM, Alex Soto Bueno > wrote: > > > Hello, > > > > I have next command: > > > > public class AddAlgeronFolderPublisher extends AbstractProjectCommand > > implements UICommand > > { > > > > @Inject > > private ProjectFactory projectFactory; > > > > @Inject > > private FacetFactory facetFactory; > > > > @Inject > > @WithAttributes(shortName = 'o', label = "Output Folder", required = > > true) > > private UISelectOne outputFolder; > > > > @Inject > > @WithAttributes(shortName = 'c', label = "Contracts Folder") > > private UISelectOne contractFolder; > > > > @Override > > public UICommandMetadata getMetadata(UIContext context) > > { > > return Metadata.from(super.getMetadata(context), getClass()) > > .category(Categories.create("Algeron")) > > .name("Arquillian Algeron: Add Folder Publisher") > > .description("This command registers a Folder Publisher for > > Algeron"); > > } > > > > @Override > > public void initializeUI(UIBuilder builder) throws Exception > > { > > builder.add(outputFolder).add(contractFolder); > > contractFolder.setDefaultValue("target/pacts"); > > } > > > > // ...... > > } > > > > When in Forge console I run: > > > > arquillian-algeron-add-folder-publisher --output-folder /tmp > > > > I got: > > > > ***INFO*** Required inputs not satisfied, entering interactive mode > > ***ERROR*** Output Folder must be specified. > > > > But you can see that I am setting the attribute in the command so any > idea > > of why this is failing? > > > > > > > > > > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > From asotobue at redhat.com Wed Jan 25 11:09:02 2017 From: asotobue at redhat.com (Alex Soto Bueno) Date: Wed, 25 Jan 2017 17:09:02 +0100 Subject: [forge-dev] Required Parameter is ignored although it is set In-Reply-To: References: Message-ID: :) Nice that it is already identified. I am going to convert to a Forge expert some day if I continue working on it :D On Wed, Jan 25, 2017 at 5:06 PM, George Gastaldi wrote: > Glad you found the cause. > > There is a JIRA already asking to provide a more rigid option parsing > strategy. Right now if you use UISelectOne and call setValue with a value > that is not in its valueChoices list, it will set to null. > > Keep on Forgin'! > > *George Gastaldi* > > https://onename.com/gastaldi > > On Wed, Jan 25, 2017 at 1:56 PM, Alex Soto Bueno > wrote: > > > I have found that the error was that instead of using UISelectOne I need > to > > use UIInput since it is the default input type used. But I think that > error > > message should be improved about incompatible types instead of an error > > that it is not really the error it is happening. > > > > WDYT? > > > > On Wed, Jan 25, 2017 at 4:40 PM, Alex Soto Bueno > > wrote: > > > > > Hello, > > > > > > I have next command: > > > > > > public class AddAlgeronFolderPublisher extends AbstractProjectCommand > > > implements UICommand > > > { > > > > > > @Inject > > > private ProjectFactory projectFactory; > > > > > > @Inject > > > private FacetFactory facetFactory; > > > > > > @Inject > > > @WithAttributes(shortName = 'o', label = "Output Folder", required = > > > true) > > > private UISelectOne outputFolder; > > > > > > @Inject > > > @WithAttributes(shortName = 'c', label = "Contracts Folder") > > > private UISelectOne contractFolder; > > > > > > @Override > > > public UICommandMetadata getMetadata(UIContext context) > > > { > > > return Metadata.from(super.getMetadata(context), getClass()) > > > .category(Categories.create("Algeron")) > > > .name("Arquillian Algeron: Add Folder Publisher") > > > .description("This command registers a Folder Publisher > for > > > Algeron"); > > > } > > > > > > @Override > > > public void initializeUI(UIBuilder builder) throws Exception > > > { > > > builder.add(outputFolder).add(contractFolder); > > > contractFolder.setDefaultValue("target/pacts"); > > > } > > > > > > // ...... > > > } > > > > > > When in Forge console I run: > > > > > > arquillian-algeron-add-folder-publisher --output-folder /tmp > > > > > > I got: > > > > > > ***INFO*** Required inputs not satisfied, entering interactive mode > > > ***ERROR*** Output Folder must be specified. > > > > > > But you can see that I am setting the attribute in the command so any > > idea > > > of why this is failing? > > > > > > > > > > > > > > > > > _______________________________________________ > > forge-dev mailing list > > forge-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > From ggastald at redhat.com Wed Jan 25 11:13:18 2017 From: ggastald at redhat.com (George Gastaldi) Date: Wed, 25 Jan 2017 14:13:18 -0200 Subject: [forge-dev] Bug on XML indentation? In-Reply-To: References: Message-ID: This looks like a bug indeed. Mind opening a JIRA and perhaps providing a PR on https://github.com/forge/xml-parser? :) Thanks! Em 25 de jan de 2017 14:07, "Alex Soto Bueno" escreveu: > Hi I am generating an XML file in an addon using: > > XMLParser.toXMLString(xml); > > The node I am creating is done: > > xml.getOrCreate("extension at qualifier=" + qualifier) > .getOrCreate("property at name=" + key) > .text(value); > > were value is a yaml-like expression. > > The problem is that the resulting XML is not well indented: > > > > > > > provider: folder > outputFolder: /tmp/contracts > contractsFolder: target/pacts > > > > > > I can understand that YAML thing is not correctly formatted but notice that > the closing tag is not correctly indented. > > Any idea? > > Alex. > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > From asotobue at redhat.com Fri Jan 27 06:19:11 2017 From: asotobue at redhat.com (Alex Soto Bueno) Date: Fri, 27 Jan 2017 12:19:11 +0100 Subject: [forge-dev] Metadata for projects Message-ID: Hello, is there any way to set some kind of metadata that survives to forge console life time? What I want to do is that when you run a command you set some metadata regarding an option that user has chosen. Then in the future when user runs other commands we can get that information from there and act accordantly. Alex. From ggastald at redhat.com Fri Jan 27 06:22:54 2017 From: ggastald at redhat.com (George Gastaldi) Date: Fri, 27 Jan 2017 09:22:54 -0200 Subject: [forge-dev] Metadata for projects In-Reply-To: References: Message-ID: You need to save that option in the Configuration. It can be User-scoped or Project-scoped. See https://github.com/forge/core/tree/master/configuration#features for more details. *George Gastaldi* https://onename.com/gastaldi On Fri, Jan 27, 2017 at 9:19 AM, Alex Soto Bueno wrote: > Hello, is there any way to set some kind of metadata that survives to forge > console life time? > > What I want to do is that when you run a command you set some metadata > regarding an option that user has chosen. > > Then in the future when user runs other commands we can get that > information from there and act accordantly. > > Alex. > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > From asotobue at redhat.com Fri Jan 27 06:28:58 2017 From: asotobue at redhat.com (Alex Soto Bueno) Date: Fri, 27 Jan 2017 12:28:58 +0100 Subject: [forge-dev] Metadata for projects In-Reply-To: References: Message-ID: Oh nice, this project is just awesome. You have thought all use cases. On Fri, Jan 27, 2017 at 12:22 PM, George Gastaldi wrote: > You need to save that option in the Configuration. It can be User-scoped or > Project-scoped. > > See https://github.com/forge/core/tree/master/configuration#features for > more details. > > *George Gastaldi* > > https://onename.com/gastaldi > > On Fri, Jan 27, 2017 at 9:19 AM, Alex Soto Bueno > wrote: > > > Hello, is there any way to set some kind of metadata that survives to > forge > > console life time? > > > > What I want to do is that when you run a command you set some metadata > > regarding an option that user has chosen. > > > > Then in the future when user runs other commands we can get that > > information from there and act accordantly. > > > > Alex. > > _______________________________________________ > > forge-dev mailing list > > forge-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > From ggastald at redhat.com Fri Jan 27 06:30:11 2017 From: ggastald at redhat.com (George Gastaldi) Date: Fri, 27 Jan 2017 09:30:11 -0200 Subject: [forge-dev] Metadata for projects In-Reply-To: References: Message-ID: Not all of them, I still miss a cache addon :) *George Gastaldi* https://onename.com/gastaldi On Fri, Jan 27, 2017 at 9:28 AM, Alex Soto Bueno wrote: > Oh nice, this project is just awesome. You have thought all use cases. > > On Fri, Jan 27, 2017 at 12:22 PM, George Gastaldi > wrote: > > > You need to save that option in the Configuration. It can be User-scoped > or > > Project-scoped. > > > > See https://github.com/forge/core/tree/master/configuration#features for > > more details. > > > > *George Gastaldi* > > > > https://onename.com/gastaldi > > > > On Fri, Jan 27, 2017 at 9:19 AM, Alex Soto Bueno > > wrote: > > > > > Hello, is there any way to set some kind of metadata that survives to > > forge > > > console life time? > > > > > > What I want to do is that when you run a command you set some metadata > > > regarding an option that user has chosen. > > > > > > Then in the future when user runs other commands we can get that > > > information from there and act accordantly. > > > > > > Alex. > > > _______________________________________________ > > > forge-dev mailing list > > > forge-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > _______________________________________________ > > forge-dev mailing list > > forge-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > From asotobue at redhat.com Fri Jan 27 06:32:00 2017 From: asotobue at redhat.com (Alex Soto Bueno) Date: Fri, 27 Jan 2017 12:32:00 +0100 Subject: [forge-dev] Metadata for projects In-Reply-To: References: Message-ID: Ok I am not going to do any other compliment :D On Fri, Jan 27, 2017 at 12:30 PM, George Gastaldi wrote: > Not all of them, I still miss a cache addon :) > > *George Gastaldi* > > https://onename.com/gastaldi > > On Fri, Jan 27, 2017 at 9:28 AM, Alex Soto Bueno > wrote: > > > Oh nice, this project is just awesome. You have thought all use cases. > > > > On Fri, Jan 27, 2017 at 12:22 PM, George Gastaldi > > wrote: > > > > > You need to save that option in the Configuration. It can be > User-scoped > > or > > > Project-scoped. > > > > > > See https://github.com/forge/core/tree/master/configuration#features > for > > > more details. > > > > > > *George Gastaldi* > > > > > > https://onename.com/gastaldi > > > > > > On Fri, Jan 27, 2017 at 9:19 AM, Alex Soto Bueno > > > wrote: > > > > > > > Hello, is there any way to set some kind of metadata that survives to > > > forge > > > > console life time? > > > > > > > > What I want to do is that when you run a command you set some > metadata > > > > regarding an option that user has chosen. > > > > > > > > Then in the future when user runs other commands we can get that > > > > information from there and act accordantly. > > > > > > > > Alex. > > > > _______________________________________________ > > > > forge-dev mailing list > > > > forge-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > _______________________________________________ > > > forge-dev mailing list > > > forge-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > _______________________________________________ > > forge-dev mailing list > > forge-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > From asotobue at redhat.com Mon Jan 30 07:21:53 2017 From: asotobue at redhat.com (Alex Soto Bueno) Date: Mon, 30 Jan 2017 13:21:53 +0100 Subject: [forge-dev] JavaSourceClass parameter Message-ID: Hi mates, currently I am creating a command that should receive a Test Java Class as parameter. I have created a command with an attribute of type JavaClassSource. @Inject @WithAttributes(shortName = 'j', label = "Test Class", required = true) private UIInput testClass; Then when I try to run this command from CLI the first thing I have noted is that autocompletition of the java class name does not work, and when I set it manually typing all characters i.e arquillian-algeron-create-contract-fragment --consumer consumer --provider provider --fragment myFragment --test-class org.contract.MyContract then I got No converter found from java.lang.String to org.jboss.forge.roaster.model.source.JavaClassSource I think that this is because it expects the class to be found as main java classes and not test classes, any idea on why this is happening? Thank you so much. From ggastald at redhat.com Mon Jan 30 07:57:27 2017 From: ggastald at redhat.com (George Gastaldi) Date: Mon, 30 Jan 2017 10:57:27 -0200 Subject: [forge-dev] JavaSourceClass parameter In-Reply-To: References: Message-ID: By using a UIInput, you need to specify the converter (setConverter - from string to JavaClassSource) otherwise Forge wouldn't know what to do. If you were using UISelectOne, it would be a matter of calling testClass.setItemLabelConverter(JavaClassSource::getName) since Forge would query the available valueChoices instead. Em 30 de jan de 2017 10:22, "Alex Soto Bueno" escreveu: Hi mates, currently I am creating a command that should receive a Test Java Class as parameter. I have created a command with an attribute of type JavaClassSource. @Inject @WithAttributes(shortName = 'j', label = "Test Class", required = true) private UIInput testClass; Then when I try to run this command from CLI the first thing I have noted is that autocompletition of the java class name does not work, and when I set it manually typing all characters i.e arquillian-algeron-create-contract-fragment --consumer consumer --provider provider --fragment myFragment --test-class org.contract.MyContract then I got No converter found from java.lang.String to org.jboss.forge.roaster.model.source.JavaClassSource I think that this is because it expects the class to be found as main java classes and not test classes, any idea on why this is happening? Thank you so much. _______________________________________________ forge-dev mailing list forge-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev From asotobue at redhat.com Mon Jan 30 12:15:17 2017 From: asotobue at redhat.com (Alex Soto Bueno) Date: Mon, 30 Jan 2017 18:15:17 +0100 Subject: [forge-dev] JavaSourceClass parameter In-Reply-To: References: Message-ID: I am trying to do it but I have no luck on this. Look the project is here: https://github.com/forge/addon-arquillian/pull/16 The test is https://github.com/forge/addon-arquillian/pull/16/files#diff-12d88edc779455bcebbb5bd707c56d1cR23 and the logic where it is implemented at https://github.com/forge/addon-arquillian/pull/16/files#diff-b7b01b162777c14a55ccc50945b79f51R80 But I don't know why when I run the test I got next exception: ***SUCCESS*** Created test class org.superbiz.MyContractTest yContractTest ***INFO*** Required inputs not satisfied, entering interactive mode [0] ( ) MyContractTest Press to confirm, or +C to cancel. * Test Class: [0] STDERR: BUFFER: [] But if you look at shell command I am setting the parameter so no idea why this is happening. On Mon, Jan 30, 2017 at 1:57 PM, George Gastaldi wrote: > By using a UIInput, you need to specify the converter (setConverter - from > string to JavaClassSource) otherwise Forge wouldn't know what to do. > > If you were using UISelectOne, it would be a matter of calling > testClass.setItemLabelConverter(JavaClassSource::getName) since Forge > would > query the available valueChoices instead. > > Em 30 de jan de 2017 10:22, "Alex Soto Bueno" > escreveu: > > Hi mates, > > currently I am creating a command that should receive a Test Java Class as > parameter. > > I have created a command with an attribute of type JavaClassSource. > > @Inject > @WithAttributes(shortName = 'j', label = "Test Class", required = true) > private UIInput testClass; > > Then when I try to run this command from CLI the first thing I have noted > is that autocompletition of the java class name does not work, and when I > set it manually typing all characters > i.e arquillian-algeron-create-contract-fragment --consumer consumer > --provider provider --fragment myFragment --test-class > org.contract.MyContract then I got No converter found from java.lang.String > to org.jboss.forge.roaster.model.source.JavaClassSource > > I think that this is because it expects the class to be found as main java > classes and not test classes, any idea on why this is happening? > > Thank you so much. > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > From ggastald at redhat.com Mon Jan 30 12:23:11 2017 From: ggastald at redhat.com (George Gastaldi) Date: Mon, 30 Jan 2017 15:23:11 -0200 Subject: [forge-dev] JavaSourceClass parameter In-Reply-To: References: Message-ID: Ah my bad. JavaClassSource::getName returns the class name without the package. Use getQualifiedName() instead *George Gastaldi* https://onename.com/gastaldi On Mon, Jan 30, 2017 at 3:15 PM, Alex Soto Bueno wrote: > I am trying to do it but I have no luck on this. Look the project is here: > https://github.com/forge/addon-arquillian/pull/16 > > The test is > https://github.com/forge/addon-arquillian/pull/16/files#diff- > 12d88edc779455bcebbb5bd707c56d1cR23 > and the logic where it is implemented at > https://github.com/forge/addon-arquillian/pull/16/files#diff- > b7b01b162777c14a55ccc50945b79f51R80 > > But I don't know why when I run the test I got next exception: > > ***SUCCESS*** Created test class org.superbiz.MyContractTest > yContractTest > ***INFO*** Required inputs not satisfied, entering interactive mode > > [0] ( ) MyContractTest > > Press to confirm, or +C to cancel. > * Test Class: [0] > > STDERR: > > BUFFER: [] > > But if you look at shell command I am setting the parameter so no idea why > this is happening. > > > On Mon, Jan 30, 2017 at 1:57 PM, George Gastaldi > wrote: > > > By using a UIInput, you need to specify the converter (setConverter - > from > > string to JavaClassSource) otherwise Forge wouldn't know what to do. > > > > If you were using UISelectOne, it would be a matter of calling > > testClass.setItemLabelConverter(JavaClassSource::getName) since Forge > > would > > query the available valueChoices instead. > > > > Em 30 de jan de 2017 10:22, "Alex Soto Bueno" > > escreveu: > > > > Hi mates, > > > > currently I am creating a command that should receive a Test Java Class > as > > parameter. > > > > I have created a command with an attribute of type JavaClassSource. > > > > @Inject > > @WithAttributes(shortName = 'j', label = "Test Class", required = > true) > > private UIInput testClass; > > > > Then when I try to run this command from CLI the first thing I have noted > > is that autocompletition of the java class name does not work, and when I > > set it manually typing all characters > > i.e arquillian-algeron-create-contract-fragment --consumer consumer > > --provider provider --fragment myFragment --test-class > > org.contract.MyContract then I got No converter found from > java.lang.String > > to org.jboss.forge.roaster.model.source.JavaClassSource > > > > I think that this is because it expects the class to be found as main > java > > classes and not test classes, any idea on why this is happening? > > > > Thank you so much. > > _______________________________________________ > > forge-dev mailing list > > forge-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/forge-dev > > _______________________________________________ > > forge-dev mailing list > > forge-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > From asotobue at redhat.com Mon Jan 30 12:42:08 2017 From: asotobue at redhat.com (Alex Soto Bueno) Date: Mon, 30 Jan 2017 18:42:08 +0100 Subject: [forge-dev] JavaSourceClass parameter In-Reply-To: References: Message-ID: Now it seems to work, thank you very much. I need to check because an NPE is thrown but I think it is in addon code itself. On Mon, Jan 30, 2017 at 6:23 PM, George Gastaldi wrote: > Ah my bad. JavaClassSource::getName returns the class name without the > package. Use getQualifiedName() instead > > *George Gastaldi* > > https://onename.com/gastaldi > > On Mon, Jan 30, 2017 at 3:15 PM, Alex Soto Bueno > wrote: > > > I am trying to do it but I have no luck on this. Look the project is > here: > > https://github.com/forge/addon-arquillian/pull/16 > > > > The test is > > https://github.com/forge/addon-arquillian/pull/16/files#diff- > > 12d88edc779455bcebbb5bd707c56d1cR23 > > and the logic where it is implemented at > > https://github.com/forge/addon-arquillian/pull/16/files#diff- > > b7b01b162777c14a55ccc50945b79f51R80 > > > > But I don't know why when I run the test I got next exception: > > > > ***SUCCESS*** Created test class org.superbiz.MyContractTest > > yContractTest > > ***INFO*** Required inputs not satisfied, entering interactive mode > > > > [0] ( ) MyContractTest > > > > Press to confirm, or +C to cancel. > > * Test Class: [0] > > > > STDERR: > > > > BUFFER: [] > > > > But if you look at shell command I am setting the parameter so no idea > why > > this is happening. > > > > > > On Mon, Jan 30, 2017 at 1:57 PM, George Gastaldi > > wrote: > > > > > By using a UIInput, you need to specify the converter (setConverter - > > from > > > string to JavaClassSource) otherwise Forge wouldn't know what to do. > > > > > > If you were using UISelectOne, it would be a matter of calling > > > testClass.setItemLabelConverter(JavaClassSource::getName) since Forge > > > would > > > query the available valueChoices instead. > > > > > > Em 30 de jan de 2017 10:22, "Alex Soto Bueno" > > > escreveu: > > > > > > Hi mates, > > > > > > currently I am creating a command that should receive a Test Java Class > > as > > > parameter. > > > > > > I have created a command with an attribute of type JavaClassSource. > > > > > > @Inject > > > @WithAttributes(shortName = 'j', label = "Test Class", required = > > true) > > > private UIInput testClass; > > > > > > Then when I try to run this command from CLI the first thing I have > noted > > > is that autocompletition of the java class name does not work, and > when I > > > set it manually typing all characters > > > i.e arquillian-algeron-create-contract-fragment --consumer consumer > > > --provider provider --fragment myFragment --test-class > > > org.contract.MyContract then I got No converter found from > > java.lang.String > > > to org.jboss.forge.roaster.model.source.JavaClassSource > > > > > > I think that this is because it expects the class to be found as main > > java > > > classes and not test classes, any idea on why this is happening? > > > > > > Thank you so much. > > > _______________________________________________ > > > forge-dev mailing list > > > forge-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > _______________________________________________ > > > forge-dev mailing list > > > forge-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > _______________________________________________ > > forge-dev mailing list > > forge-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > From alr at redhat.com Tue Jan 31 18:27:47 2017 From: alr at redhat.com (Andrew Lee Rubinger) Date: Tue, 31 Jan 2017 18:27:47 -0500 Subject: [forge-dev] Multitenancy for Forge as a Service Message-ID: Hi, all: We have some requests coming down the pike from the Developer Group with regards to running Forge as a Service (which is great!). Additionally, I'm suspecting this will soon be very important for us as well, as we continue to build out what's currently known as the "Obsidian Generator", using Forge as a backend. I'm hoping the Forge team will kindly advise as to our preparedness for running Forge in a multitenant environment. Concerns may include resource consumption (not running an instance-per-user), security, etc. Have we yet broached this subject specifically in the prototypes I've seen thus far using Forge Online? I've requested of the Developer Group a list of requirements they've devised; will send those along here when I have them. In the meantime, mind describing where we currently stand? S, ALR -- Red Hat Developer Group Architecture @ALRubinger From ggastald at redhat.com Tue Jan 31 19:00:50 2017 From: ggastald at redhat.com (George Gastaldi) Date: Tue, 31 Jan 2017 22:00:50 -0200 Subject: [forge-dev] Multitenancy for Forge as a Service In-Reply-To: References: Message-ID: Hey Andrew, Yes, this is a really important question, and it's something that I believe that the Forge architecture supports out-of-the-box. Every interaction with the UI API (the Forge commands, per say) is stored in a request-scoped UIContext[1] object that is initialized when a command is invoked and destroyed when the command finishes executing. That means that you can execute multiple concurrent commands in a single Forge instance and they will not affect each other. When it comes to security, as a good practice, it is important to restrict the commands that the exposed REST service can execute. That's why in the Obsidian backend[2] we only expose a REST endpoint[3] consuming the Forge API to execute a limited number of commands (more specifically, the ones exposed by the obsidian-addon[4]) Last but not least, as the Forge Online app is just a PoC illustrating how Forge can work in a web environment, it does not impose restrictions to the supported commands, therefore it shouldn't be a web app to be used in production. PS: It would be nice to ping the Fabric8 team for this matter as they are already using Forge as their project generator solution for a long time now. I hope this helps. Looking forward to this list of requirements and happy to discuss about this anytime. [1] - https://github.com/forge/core/tree/master/ui#uicommand-execution-lifecycle [2] - https://github.com/obsidian-toaster/generator-backend [3] - https://github.com/obsidian-toaster/generator-backend/blob/master/src/main/java/org/obsidiantoaster/generator/rest/ObsidianResource.java [4] - https://github.com/obsidian-toaster/obsidian-addon Best Regards, *George Gastaldi* https://onename.com/gastaldi On Tue, Jan 31, 2017 at 9:27 PM, Andrew Lee Rubinger wrote: > Hi, all: > > We have some requests coming down the pike from the Developer Group with > regards to running Forge as a Service (which is great!). > > Additionally, I'm suspecting this will soon be very important for us as > well, as we continue to build out what's currently known as the "Obsidian > Generator", using Forge as a backend. > > I'm hoping the Forge team will kindly advise as to our preparedness for > running Forge in a multitenant environment. Concerns may include resource > consumption (not running an instance-per-user), security, etc. Have we yet > broached this subject specifically in the prototypes I've seen thus far > using Forge Online? > > I've requested of the Developer Group a list of requirements they've > devised; will send those along here when I have them. In the meantime, > mind describing where we currently stand? > > S, > ALR > > -- > Red Hat Developer Group Architecture > @ALRubinger > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > From alr at redhat.com Tue Jan 31 19:17:35 2017 From: alr at redhat.com (Andrew Lee Rubinger) Date: Tue, 31 Jan 2017 19:17:35 -0500 Subject: [forge-dev] Multitenancy for Forge as a Service In-Reply-To: References: Message-ID: Thanks for the summary, George. I'll send interested parties to this thread. S, ALR On Tue, Jan 31, 2017 at 7:00 PM, George Gastaldi wrote: > Hey Andrew, > > Yes, this is a really important question, and it's something that I believe > that the Forge architecture supports out-of-the-box. Every interaction with > the UI API (the Forge commands, per say) is stored in a request-scoped > UIContext[1] object that is initialized when a command is invoked and > destroyed when the command finishes executing. That means that you can > execute multiple concurrent commands in a single Forge instance and they > will not affect each other. > > When it comes to security, as a good practice, it is important to restrict > the commands that the exposed REST service can execute. > That's why in the Obsidian backend[2] we only expose a REST endpoint[3] > consuming the Forge API to execute a limited number of commands (more > specifically, the ones exposed by the obsidian-addon[4]) > > Last but not least, as the Forge Online app is just a PoC illustrating how > Forge can work in a web environment, it does not impose restrictions to the > supported commands, therefore it shouldn't be a web app to be used in > production. > > PS: It would be nice to ping the Fabric8 team for this matter as they are > already using Forge as their project generator solution for a long time > now. > > I hope this helps. Looking forward to this list of requirements and happy > to discuss about this anytime. > > [1] - > https://github.com/forge/core/tree/master/ui#uicommand-execution-lifecycle > [2] - https://github.com/obsidian-toaster/generator-backend > [3] - > https://github.com/obsidian-toaster/generator-backend/ > blob/master/src/main/java/org/obsidiantoaster/generator/ > rest/ObsidianResource.java > [4] - https://github.com/obsidian-toaster/obsidian-addon > > Best Regards, > > *George Gastaldi* > > https://onename.com/gastaldi > > On Tue, Jan 31, 2017 at 9:27 PM, Andrew Lee Rubinger > wrote: > > > Hi, all: > > > > We have some requests coming down the pike from the Developer Group with > > regards to running Forge as a Service (which is great!). > > > > Additionally, I'm suspecting this will soon be very important for us as > > well, as we continue to build out what's currently known as the "Obsidian > > Generator", using Forge as a backend. > > > > I'm hoping the Forge team will kindly advise as to our preparedness for > > running Forge in a multitenant environment. Concerns may include > resource > > consumption (not running an instance-per-user), security, etc. Have we > yet > > broached this subject specifically in the prototypes I've seen thus far > > using Forge Online? > > > > I've requested of the Developer Group a list of requirements they've > > devised; will send those along here when I have them. In the meantime, > > mind describing where we currently stand? > > > > S, > > ALR > > > > -- > > Red Hat Developer Group Architecture > > @ALRubinger > > _______________________________________________ > > forge-dev mailing list > > forge-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > -- Twitter: @ALRubinger