<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Those are some excellent questions, I'll answer then inline:</div><div><br>Em 01/09/2013, às 17:15, "Ivan St. Ivanov" <<a href="mailto:ivan.st.ivanov@gmail.com">ivan.st.ivanov@gmail.com</a>> escreveu:<br><br></div><blockquote type="cite"><div><div dir="ltr">Hey folks!<div><br></div><div>This weekend I've been hacking on migrating the git-tools to Forge 2 (<a href="https://issues.jboss.org/browse/FORGE-1128">https://issues.jboss.org/browse/FORGE-1128</a>). 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).</div>
<div><br></div><div>And I have the following questions and observations:</div><div><br></div><div>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.</div>
<div><br></div></div></div></blockquote>Exactly, this is the way to do it. We haven't migrated @RequiresProject and @RequiresResources yet, so you're doing the right thing. <div><br><blockquote type="cite"><div><div dir="ltr"><div>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</div>
<div><br></div></div></div></blockquote>Right again. We prototyped in a separate branch the "command-per-method" strategy but we haven't completed it yet.</div><div><br><blockquote type="cite"><div dir="ltr"><div>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)?</div><div><br></div></div></blockquote>Yes, the current resource is always retrieved using UIContext.getInitialSelection, which can be safely assigned to a UISelection<Resource<?>> variable.</div><div><br><blockquote type="cite"><div dir="ltr">
<div>4) Is there such a thing as setup command? I think there's no need, but still I'd like to ask</div></div></blockquote>There is not, but setup commands should be implemented as UICommands as you may have already noticed.</div><div><br><blockquote type="cite"><div dir="ltr"><div>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?</div></div></blockquote>Facets can't write messages for now, but we should consider doing it so it if makes sense.</div><div><br></div><div><blockquote type="cite"><div dir="ltr"><div>6) I saw that some of the git commands in Forge 1 fire pickup events:</div><div>Event<PickupResource>::fire(new PickupResource(gitIgnoreResource()));<br></div><div>How is this done in Forge 2. I would appreciate a sample in existing plugin</div></div></blockquote>You have to call UIContext.setSelection in your UICommand.execute method.</div><div><br><blockquote type="cite"><div dir="ltr"><div>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</div></div></blockquote>In the UICommand.initializeUI method, you call setCompleter for the desired injected input</div><div><br><blockquote type="cite"><div dir="ltr"><div>And of course I have some questions about the git-tools implementation that have nothing to do with the migration:</div><div><br></div><div>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?</div></div></blockquote>That would be a good idea, so it could be possible to use native git if needed.</div><div><br><blockquote type="cite"><div dir="ltr"><div>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</div></div></blockquote>Make your addon depend on the projects addon and you shall access these classes normally</div><div><br><blockquote type="cite"><div dir="ltr"><div>So, that's all from me for now. Next to come - the questions about the migration about the tests ;)</div><div><br></div></div></blockquote>Bring'em on! :)</div><div><br><blockquote type="cite"><div dir="ltr"><div>Cheers,</div><div>Ivan</div></div>
</blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>forge-dev mailing list</span><br><span><a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a></span><br><span><a href="https://lists.jboss.org/mailman/listinfo/forge-dev">https://lists.jboss.org/mailman/listinfo/forge-dev</a></span></div></blockquote></div></body></html>