Re: [forge-dev] Questions about migrating git-tools to Forge 2

Hey George! Thanks a lot for the quick feedback! I'm afraid though that I did not get some of the answers I needed: 3) How do you get the current resource (@Current as of Forge 1)? Is it context.getInitialSelection().get()? *How can I check that it is of any particular type (e.g. GitIgnoreResource)*? [George]: Yes, the current resource is always retrieved using UIContext.getInitialSelection, which can be safely assigned to a UISelection<Resource<?>> variable. [Ivan]: I did not get how can I check whether a file resource is of GitIgnoreResource type. What I can think of: check whether the current resource is file and that its name is GitIgnoreResource.RESOURCE_NAME. I'm afraid that instanceof will not work. What I am not sure is how Forge knows that a certain resource is of certain type (or more precisely: of certain subtype of FileResource) 7) How did you migrate existing completers? I see that the completer interface has changed. I am afraid I can't figure out how I can rework complete methods from Forge 1, that were *using CommandCompleterState parameter*. I couldn't find samples [George]: In the UICommand.initializeUI method, you call setCompleter for the desired injected input [Ivan]: Yes, I found how to assign a completer to an input. However I was not sure how to adapt an already existing completer, which received as parameter a CommandCompleterState object. The existing completers used that object and I don't know how to rework them to use the UIContext interface for the same purpose 2) I see that in javaee-impl you have implemented an abstract command class that exposes a class that returns the current project (or null): org.jboss.forge.addon.javaee.ui.AbstractProjectUICommand. I copy-pasted the getSelectedProject method to an abstract Git UI command class that I created just becayse I saw that addon-ui does not have access to the project API (outherwise I would put it in the AbstractUICommand class). *Can we find a better place for this code?* In Forge 1 we just @Inject-ed a Project instance, but now I am not sure what to do [George]: Make your addon depend on the projects addon and you shall access these classes normally [Ivan]: Actually I did what you proposed. But now we have one and the same "protected Project getSelectedProject(UIContext context)" method in org.jboss.forge.addon.javaee.ui.AbstractProjectUICommand and in org.jboss.forge.addon.git.ui.AbstractGitCommand. Can we find a better place for a class like AbstractProjecUICommand that is accessible from anywhere where we develop commands relying on a context of a project? Maybe in projects-impl? Both javaee and git depend on that. And one additional question: 8) In Forge 1 every plugin had a short name that we entered on the command line. Now I see that commands have some long strings as names (e.g. "JPA: New Entity"). What does the user have to enter in the shell if they want to create a new entity? Thanks, Ivan On Mon, Sep 2, 2013 at 12:34 AM, George Gastaldi <ggastald(a)redhat.com <mailto:ggastald@redhat.com>> wrote: Those are some excellent questions, I'll answer then inline: Em 01/09/2013, às 17:15, "Ivan St. Ivanov" <ivan.st.ivanov(a)gmail.com <mailto:ivan.st.ivanov@gmail.com>> escreveu: > Hey folks! > > This weekend I've been hacking on migrating the git-tools to > Forge 2 (https://issues.jboss.org/browse/FORGE-1128). And I can > say that I have pretty much finished the task (although I haven't > started yet with the git-tools-tests, but I will do that as well). > > And I have the following questions and observations: > > 1) How do you declare that a UI command requires to be executed > in the context of a project or in a context of a certain > resource? In Forge 1 we had the @RequiresProject and > @RequiresResource annotations, but now we only have > @RequiresFacet (I hope it works ;)). What I do here is: implement > isEnabled and work with the initialSelection method of the > UIContext to check what is selected. BTW I find quite more > declarative approaches in Forge 1 than in Forge 2. > Exactly, this is the way to do it. We haven't migrated @RequiresProject and @RequiresResources yet, so you're doing the right thing. > 2) In Forge 1 we had one plugin class that represented a command > with a lot of options as methods of that class. Did I get it > right that in Forge 2 I have to create a separate UICommand > implementation for every option (i.e. method) of the plugin > class? I don't say it's bad, I just want to understand whether > this is the way > Right again. We prototyped in a separate branch the "command-per-method" strategy but we haven't completed it yet. > 3) How do you get the current resource (@Current as of Forge 1)? > Is it context.getInitialSelection().get()? How can I check that > it is of any particular type (e.g. GitIgnoreResource)? > Yes, the current resource is always retrieved using UIContext.getInitialSelection, which can be safely assigned to a UISelection<Resource<?>> variable. > 4) Is there such a thing as setup command? I think there's no > need, but still I'd like to ask There is not, but setup commands should be implemented as UICommands as you may have already noticed. > 5) If a facet has to write a message to a provider (GUI, shell), > how does it do it? Commands do that via the Result object, but I > didn't get how facets can. Or should they at all write anything? Facets can't write messages for now, but we should consider doing it so it if makes sense. > 6) I saw that some of the git commands in Forge 1 fire pickup events: > Event<PickupResource>::fire(new PickupResource(gitIgnoreResource())); > How is this done in Forge 2. I would appreciate a sample in > existing plugin You have to call UIContext.setSelection in your UICommand.execute method. > 7) How did you migrate existing completers? I see that the > completer interface has changed. I am afraid I can't figure out > how I can rework complete methods from Forge 1, that were > using CommandCompleterState parameter. I couldn't find samples In the UICommand.initializeUI method, you call setCompleter for the desired injected input > And of course I have some questions about the git-tools > implementation that have nothing to do with the migration: > > 1) At the moment the GitUtils class, which I have made an > interface and plan to export as addon, exposes some JGit classes > as parameters. Do you think it's a good idea to wrap them in our > own classes like you have done with the JDT parser API for example? That would be a good idea, so it could be possible to use native git if needed. > 2) I see that in javaee-impl you have implemented an abstract > command class that exposes a class that returns the current > project (or null): > org.jboss.forge.addon.javaee.ui.AbstractProjectUICommand. I > copy-pasted the getSelectedProject method to an abstract Git UI > command class that I created just becayse I saw that addon-ui > does not have access to the project API (outherwise I would put > it in the AbstractUICommand class). Can we find a better place > for this code? In Forge 1 we just @Inject-ed a Project instance, > but now I am not sure what to do Make your addon depend on the projects addon and you shall access these classes normally > So, that's all from me for now. Next to come - the questions > about the migration about the tests ;) > Bring'em on! :) > Cheers, > Ivan > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev