4:14 p.m.
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.
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
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)?
4) Is there such a thing as setup command? I think there's no need, but
still I'd like to ask
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?
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
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
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?
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
So, that's all from me for now. Next to come - the questions about the
migration about the tests ;)
Cheers,
Ivan
5:34 p.m.
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>
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
https://lists.jboss.org/mailman/listinfo/forge-dev
7:30 a.m.
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>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>
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
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
10:13 a.m.
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(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
3:52 p.m.
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(a)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(a)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>
> 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
> 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
>
_______________________________________________
forge-dev mailing
listforge-dev@lists.jboss.orghttps://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
4:34 p.m.
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(a)redhat.com
<mailto:ggastald@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(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 <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
4:53 p.m.
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(a)redhat.com
> <mailto:ggastald@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(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 <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
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
3886
days inactive
3887
days old
6 comments
2 participants
participants (2)
-
George Gastaldi -
Ivan St. Ivanov