The "Git Undo" functionality would certainly use the GitFacet, because you
would only want to activate Undo support when working on a Project.
*Some information about Facets:*
- Facets represent project state (E.g. Git is installed. Java is
installed. Servlet is installed)
- Facets do not work outside of projects.
- Facets avoid doing anything that prints to the shell output (sometimes
it is unavoidable)
- Facets are for encapsulating additional functionality that is usable
in one or more plugins
With that said, only some of the additional methods you suggested are not
really appropriate for a Facet:
- showLatestDiff()
probably not appropriate because it would print output - this should go
into the GitPlugin instead
- showLatestCommit()
Probably not appropriate because it would print output - this should go
into the GitPlugin instead
- getNotes()
Not sure what this does.
- showLog()
Probably not appropriate because it would print output - this should go
into the GitPlugin instead
- switchBranch()
Appropriate as an API, but not if it requires user input - this is
potentially a good method and in line with being appropriate for a Facet.
- cleanWorkingDirectory()
Not exactly sure what this would do, but yes, sounds in line with being
appropriate for a Facet.
Does that help? :)
~Lincoln
On Fri, Apr 20, 2012 at 4:52 PM, Jevgeni Zelenkov <
jevgeni.zelenkov(a)googlemail.com> wrote:
> Hi Lincoln,
>
> Thanks for the explanation, that helped me to understand it but not
> completely. So, what do you actually mean by "inspect the state of a
> Project"?
>
> I take methods provided by you:
> - getBranches()
> - getTags()
> - getRemotes()
> - getStatus()
>
> And here are some more suggestions to help inspect the state of a project:
> - showLatestDiff()
> - showLatestCommit()
> - getNotes()
> - showLog()
> - switchBranch()
- cleanWorkingDirectory()
> Would that be enough?
> I guess, I don't understand the use cases for the GitFacet yet.
> Who is going to use it and what are the potential scenarios? The git
> undo plugin will require a lot more than that. And I assume that
> GitFacet is not really a wrapper for the jGit functionality.
>
> Regards,
> Jevgeni
>
> On 04/20/2012 06:00 PM, forge-dev-request(a)lists.jboss.org wrote:
> > Message: 5
> > Date: Fri, 20 Apr 2012 09:21:10 -0400
> > From: "Lincoln Baxter, III"<lincolnbaxter(a)gmail.com>
> > Subject: Re: [forge-dev] GitPlugin Facet
> > To: forge-dev List<forge-dev(a)lists.jboss.org>
> > Message-ID:
> > <
> CAEp_U4GGVD8p8hH2M5PRm6gK_MkDGtAyXzokGcm3VVz70jeX2g(a)mail.gmail.com>
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > Hey Jevgeni,
> >
> > Welcome!
> >
> > Regarding the GitFacet - I believe it's in the right place for the
> moment,
> > but I don't believe that the GitPlugin should be referencing it, since
> the
> > commands in GitPlugin could be used even without a Project.
> >
> > GitFacet (as the issue describes poorly) is something that should be
> usable
> > to inspect the state of a Project via:
> >
> > project.hasFacet(GitFacet.class)
> >
> > After that, everything else is an added benefit. It should probably also
> > perform tasks like:
> >
> > project.getFacet(GitFacet.class).getBranches()
> > project.getFacet(GitFacet.class).getTags()
> > project.getFacet(GitFacet.class).getRemotes()
> > project.getFacet(GitFacet.class).getStatus()
> >
> > And that's where your imagination kicks in.
> >
> > Does that make sense?
> >
> > ~Lincoln
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/forge-dev
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."