10:52 p.m.
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
12:14 a.m.
New subject: GitPlugin Facet (Lincoln Baxter, III)
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."
1:10 a.m.
New subject: GitPlugin Facet (Lincoln Baxter, III)
OK. I will try to rephrase you just to make sure I understood it.
GitFacet acts as a central API for the Git-related commands in a forge
project. Facet methods have dependencies on jGit but they only accept
and return objects from the standard Java API (like Strings, Arrays,
etc) this way GitFacet is the only component with jGit dependencies.
Facets neither print anything to the shell nor require user's input
(ideally). Facets can modify project's state (=files) and return
information about the project.
Example. (kept simple. Will probably require some more steps in between)
To create a new commit in the the git undo branch, GitFacet should
provide at least the following methods:
* public List<String> getBranches() // to see if undo-branch exists or
should be created first
* public String getCurrentBranch() // to see which branch we are
currently working on
* public boolean changeBranch(String newBranch) // switches to the new
branch (newBranch is provided by the undo plugin)
* public boolean createBranch(String newBranch) // creates a new branch
* public boolean commit(String msg) // adds all changes from the working
tree to the index, and creates a git commit with a given commit message
(msg is provided by the undo plugin)
the logic should be something like this:
<< forge command foo is executed, some files are modified >>
if getBranches() doesn't contain 'history-branch'
createBranch("org.forge.history")
if currentBranch() is not "org.forge.history"
changeBrach("org.forge.history")
commit("forge command foo was executed")
Does that sound right?
Was FORGE-183 planned as some kind of a general wrapper around jGit to
provide the most common use cases?
On 04/21/2012 12:14 AM, Lincoln Baxter, III wrote:
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
<mailto:jevgeni.zelenkov@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
<mailto:forge-dev-request@lists.jboss.org> wrote:
> Message: 5
> Date: Fri, 20 Apr 2012 09:21:10 -0400
> From: "Lincoln Baxter, III"<lincolnbaxter(a)gmail.com
<mailto:lincolnbaxter@gmail.com>>
> Subject: Re: [forge-dev] GitPlugin Facet
> To: forge-dev List<forge-dev(a)lists.jboss.org
<mailto:forge-dev@lists.jboss.org>>
> Message-ID:
>
<CAEp_U4GGVD8p8hH2M5PRm6gK_MkDGtAyXzokGcm3VVz70jeX2g(a)mail.gmail.com
<mailto:CAEp_U4GGVD8p8hH2M5PRm6gK_MkDGtAyXzokGcm3VVz70jeX2g@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 <mailto:forge-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
10:35 a.m.
New subject: GitPlugin Facet (Lincoln Baxter, III)
some of the most important things you want to know about facets.
please dont forget to enclose these jewels in
https://docs.jboss.org/author/display/FORGE/Enable+modular+functionality+...
:)
Am 21.04.2012 00:14, schrieb Lincoln Baxter, III:
*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
9:46 p.m.
New subject: GitPlugin Facet (Lincoln Baxter, III)
That's correct! A very good assessment of the situation.
Now that you have a handle on the Facet architecture, I'll add one more
caveat :)
To confuse things even further, I would not implement the actual JGit
features in the Facet itself (even though it would be correct to do so.) I
would instead create a utility class that the Facet itself would use. This
utility class could be reused by plugins directly (for plugins that do not
necessarily operate on a project.)
Does that make sense?
So you would have:
jGit -> GitUtils -> GitFacet -> GitPlugin
~Lincoln
On Fri, Apr 20, 2012 at 7:10 PM, Jevgeni Zelenkov <
jevgeni.zelenkov(a)googlemail.com> wrote:
OK. I will try to rephrase you just to make sure I understood it.
GitFacet acts as a central API for the Git-related commands in a forge
project. Facet methods have dependencies on jGit but they only accept and
return objects from the standard Java API (like Strings, Arrays, etc) this
way GitFacet is the only component with jGit dependencies. Facets neither
print anything to the shell nor require user's input (ideally). Facets can
modify project's state (=files) and return information about the project.
Example. (kept simple. Will probably require some more steps in between)
To create a new commit in the the git undo branch, GitFacet should provide
at least the following methods:
* public List<String> getBranches() // to see if undo-branch exists or
should be created first
* public String getCurrentBranch() // to see which branch we are currently
working on
* public boolean changeBranch(String newBranch) // switches to the new
branch (newBranch is provided by the undo plugin)
* public boolean createBranch(String newBranch) // creates a new branch
* public boolean commit(String msg) // adds all changes from the working
tree to the index, and creates a git commit with a given commit message
(msg is provided by the undo plugin)
the logic should be something like this:
<< forge command foo is executed, some files are modified >>
if getBranches() doesn't contain 'history-branch'
createBranch("org.forge.history")
if currentBranch() is not "org.forge.history"
changeBrach("org.forge.history")
commit("forge command foo was executed")
Does that sound right?
Was FORGE-183 planned as some kind of a general wrapper around jGit to
provide the most common use cases?
On 04/21/2012 12:14 AM, Lincoln Baxter, III wrote:
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."
_______________________________________________
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
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
12:49 a.m.
New subject: GitPlugin Facet (Lincoln Baxter, III)
Or better yet (and easier ;) here:
https://github.com/forge/website/blob/master/docs/plugin_development/face...
----- "Thomas Frühbeck" <fruehbeck(a)aon.at> wrote:
some of the most important things you want to know about facets.
please dont forget to enclose these jewels in
https://docs.jboss.org/author/display/FORGE/Enable+modular+functionality+...
:)
Am 21.04.2012 00:14, schrieb Lincoln Baxter, III:
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
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
1:05 a.m.
New subject: GitPlugin Facet (Lincoln Baxter, III)
Thanks, Rodney! Can't wait until we can turn off the wiki.
~Lincoln
On Mon, Apr 23, 2012 at 6:49 PM, Rodney Russ <rruss(a)redhat.com> wrote:
Or better yet (and easier ;) here:
https://github.com/forge/website/blob/master/docs/plugin_development/face...
----- "Thomas Frühbeck" <fruehbeck(a)aon.at> wrote:
> some of the most important things you want to know about facets.
> please dont forget to enclose these jewels in
>
https://docs.jboss.org/author/display/FORGE/Enable+modular+functionality+...
> :)
>
> Am 21.04.2012 00:14, schrieb Lincoln Baxter, III:
>
> 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
>
>
> _______________________________________________
> 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
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
8:26 a.m.
New subject: GitPlugin Facet (Lincoln Baxter, III)
Honestly, I do not want to insist, but .. :)
the older I get (indeed I feel I do) I tend to look for the "management
summary" - why should I read this, and even more - why should I read it
carefully.
Those few lines as quick primer, telling me "hey, that's for projects,
highly reusable, versatile tool kit, do have a look at it before
starting your next homegrown framework" could set the stage for the real
content.
No rants intended, I highly appreciate your work because I know how hard
it is to write a consistent, clear, comprehensible and readable text.
Thomas
Am 24.04.2012 00:49, schrieb Rodney Russ:
Or better yet (and easier ;) here:
https://github.com/forge/website/blob/master/docs/plugin_development/face...
3:48 p.m.
New subject: GitPlugin Facet (Lincoln Baxter, III)
Rant neither required nor inferred.
Would you like to prepare an introductory primer that meets those goals and
push it up (pull request) to the site? ;) Feel free to re-use any material
you see fit.
https://github.com/forge/website/blob/master/docs/plugin_development/face...
Thanks!
Lincoln
On Tue, Apr 24, 2012 at 2:26 AM, Thomas Frühbeck <fruehbeck(a)aon.at> wrote:
Honestly, I do not want to insist, but .. :)
the older I get (indeed I feel I do) I tend to look for the "management
summary" - why should I read this, and even more - why should I read it
carefully.
Those few lines as quick primer, telling me "hey, that's for projects,
highly reusable, versatile tool kit, do have a look at it before
starting your next homegrown framework" could set the stage for the real
content.
No rants intended, I highly appreciate your work because I know how hard
it is to write a consistent, clear, comprehensible and readable text.
Thomas
Am 24.04.2012 00:49, schrieb Rodney Russ:
> Or better yet (and easier ;) here:
>
>
https://github.com/forge/website/blob/master/docs/plugin_development/face...
>
>
_______________________________________________
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."
4386
days inactive
4390
days old
8 comments
4 participants
participants (4)
-
Jevgeni Zelenkov -
Lincoln Baxter, III -
Rodney Russ -
Thomas Frühbeck