[forge-dev] Questions about migrating git-tools to Forge 2
George Gastaldi
ggastald at redhat.com
Mon Sep 2 16:53:09 EDT 2013
BTW,
I reverted #2 because it was causing some test failures. I'll put it
back when I find the root cause.
Thanks
On 09/02/2013 05:34 PM, George Gastaldi wrote:
> Ok,
>
> 3) First you need to create a class that implements the
> ResourceGenerator interface (Check
> org.jboss.forge.addon.maven.resources.MavenResourceGenerator for an
> example). Forge will automatically find your ResourceGenerator class
> and use it to create the GitIgnoreResource (be sure to create tests
> that assert this behavior)
>
> 7) Basically the
> org.jboss.forge.git.gitignore.GitIgnoreTemplateCompleter.candidates(String)
> method is only what you need. Create a class that implements
> UICompleter, and add that behavior to the getCompletionProposals method.
>
> 2) Right, I moved it to projects-api under a "ui" subpackage and
> removed it from the javaee-impl. That should work.
>
> 8) Your getMetadata should be something like:
>
> super.getMetadata().name("GIT: Ignore").description("Add pattern to
> .gitignore").category(Categories.create("Git"));
>
> that will be translated to "git-ignore" in shell.
>
>
> On 09/02/2013 04:52 PM, Ivan St. Ivanov wrote:
>> 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
>> <mailto: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 <mailto: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 <mailto: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 <mailto:forge-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev at lists.jboss.org <mailto:forge-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev at lists.jboss.org <mailto:forge-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20130902/d1f1a053/attachment-0001.html
More information about the forge-dev
mailing list