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

Mon Sep 2 15:52:15 EDT 2013

Hey George,

3) Could you please explain me a little bit, just for my curiosity? How
would Forge know that when I "cd" to .gitignore file it is not merely
FileResource but it is GitIgnoreResource? Thanks!

7) I mean the GitIgnoreTemplateCompleter. There in the beginning of the
complete method you can see some acrobatics with the CommandCompleterState
parameter. I was wondering how that can be done in the new API

2) At the moment AbstractProjectUICommand is in the *javaee-impl* project.
I don't want to introduce dependency to that just to extend that class in
order to use the getSelectedProject. That is why I thought that maybe we
can find a better place for this abstract class.

8) OK, so if my getMetadata method declared that the name of the command is:

super.getMetadata().name("GIT: Add pattern to .gitignore")

How would that map to a shell command? Should we have some kind of
convention for these names?

Thanks again!
Ivan

On Mon, Sep 2, 2013 at 5:13 PM, George Gastaldi <ggastald at redhat.com> wrote:

>  Hi Ivan!
>
> 3) You can safely use instanceof. It should work. Another option is using
> the reify method, so it will convert your resource to the desired type if
> it's not the expected type or return null if it's not possible.
>
> 7) The completer API has completely changed from Forge 1. Now you just
> need to return a list of the objects that matches the value passed as a
> parameter. Do you need anything specific that it is not covered in the
> UICompleter interface? Which completer are you trying to migrate?
>
> 2) You no longer need getSelectedProject in AbstractGitCommand, use the
> one from AbstractProjectUICommand. I don't think this code fits in another
> place, but we can review that.
>
> 8) In Forge 2, the shell no longer has a "sub-command" concept (Eg: cdi
> setup was replaced by cdi-setup). The shell addon automatically converts
> spaces into dashes so it's easier to find the command you need from the
> first auto-complete.
>
> Best Regards,
>
> George Gastaldi
>
>
>
> On 09/02/2013 08:30 AM, Ivan St. Ivanov wrote:
>
> 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 at 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 at 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 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 listforge-dev at lists.jboss.orghttps://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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20130902/a30d7a55/attachment-0001.html 