[forge-dev] Questions about migrating git-tools to Forge 2
George Gastaldi
ggastald at redhat.com
Mon Sep 2 16:34:17 EDT 2013
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20130902/4f8125b0/attachment-0001.html
More information about the forge-dev
mailing list