Re: [JGIT] Request for help

Re: [JGIT] Request for help

[Mark Struberg]

Hi Douglas!

http://github.com/sonatype/JGit

The branch will be called mavenizing or so.

Will post this after I got the tests running.

LieGrue,
strub

--- On Fri, 9/4/09, Douglas Campos <douglas@theros.info> wrote:

> From: Douglas Campos <douglas@theros.info>
> Subject: Re: [JGIT] Request for help
> To: "Mark Struberg" <struberg@yahoo.de>
> Cc: "Jonas Fonseca" <jonas.fonseca@gmail.com>, git@vger.kernel.org, "Gabe McArthur" <gabriel.mcarthur@gmail.com>
> Date: Friday, September 4, 2009, 4:44 PM
> On Fri, Sep 4, 2009
> at 9:47 AM, Mark Struberg <struberg@yahoo.de>
> wrote:
> 
> 
> as an old saying tells us: how to climb a mountain? step
> after step! ;)
> 
> 
> 
> I suggest we create a fresh branch based on the Shawns
> current version and add all the features incrementally.
> 
> 
> 
> please point out where this branch will happen, I want to
> give some help too.
> 
> 


      

Re: [JGIT] Request for help

[Mark Struberg]

Hi!

Work has been done at 

http://github.com/sonatype/JGit/tree/mavenize

Please feel free to pull/fork and share your changes! I'd be happy to pull it in.

@Gabe: your patch seems to got filtered by the list, I think sharing such big things is easier by using github. Would be cool if you could help us!

LieGrue,
strub

--- On Fri, 9/4/09, Mark Struberg <struberg@yahoo.de> wrote:

> From: Mark Struberg <struberg@yahoo.de>
> Subject: Re: [JGIT] Request for help
> To: "Douglas Campos" <douglas@theros.info>
> Cc: "Jonas Fonseca" <jonas.fonseca@gmail.com>, git@vger.kernel.org, "Gabe McArthur" <gabriel.mcarthur@gmail.com>
> Date: Friday, September 4, 2009, 4:49 PM
> Hi Douglas!
> 
> http://github.com/sonatype/JGit
> 
> The branch will be called mavenizing or so.
> 
> Will post this after I got the tests running.
> 
> LieGrue,
> strub
> 
> --- On Fri, 9/4/09, Douglas Campos <douglas@theros.info>
> wrote:
> 
> > From: Douglas Campos <douglas@theros.info>
> > Subject: Re: [JGIT] Request for help
> > To: "Mark Struberg" <struberg@yahoo.de>
> > Cc: "Jonas Fonseca" <jonas.fonseca@gmail.com>,
> git@vger.kernel.org,
> "Gabe McArthur" <gabriel.mcarthur@gmail.com>
> > Date: Friday, September 4, 2009, 4:44 PM
> > On Fri, Sep 4, 2009
> > at 9:47 AM, Mark Struberg <struberg@yahoo.de>
> > wrote:
> > 
> > 
> > as an old saying tells us: how to climb a mountain?
> step
> > after step! ;)
> > 
> > 
> > 
> > I suggest we create a fresh branch based on the
> Shawns
> > current version and add all the features
> incrementally.
> > 
> > 
> > 
> > please point out where this branch will happen, I want
> to
> > give some help too.
> > 
> > 
> 
> 
>       
> --
> To unsubscribe from this list: send the line "unsubscribe
> git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


      

Re: [JGIT] Request for help

[Jonas Fonseca]

On Fri, Sep 4, 2009 at 13:28, Mark Struberg<struberg@yahoo.de> wrote:
> Hi!
>
> Work has been done at
>
> http://github.com/sonatype/JGit/tree/mavenize
>
> Please feel free to pull/fork and share your changes! I'd be happy to pull it in.

IMO, there are a lot of things that can be squashed together and
cleaned up. I know that you advocated for incremental introduction,
but it seems wrong to for example add a file and then completely
reformat it a few commits later. The same thing with the .gitignore
fixes in step 5.

Some comments ... Some of them I initially entered in github's
codereview, but I ended up writing it all here.

Commit: "mavenizing step 1: moved over the initial poms from Jasons branch"

 * Please always add an empty line between the subject and the body
   of the commit message. Like this:

  mavenizing step 1: moved over the initial poms from Jasons branch

  Signed-off-by: Mark Struberg >struberg@yahoo.de>

 * The .gitignore pattern could be further limited to "target/" ...
but you seem to change this to /target later.

In org.spearce.jgit/pom.xml:

    * The use of maven-surefire-plugin should be removed. This module
does not have any tests.

    * Shouldn't we retain the original ${groupId}:${artifactId} naming
convention, being org.spearce:jgit?

In org.spearce.jgit.test/pom.xml:

    * Dependency on jsch is unecessary since it is derived from
org.spearce.jgit.

    * Maybe name as org.spearce:jgit-test?

In org.spearce.jgit.pgm/pom.xml:

    * Maybe name as org.spearce:jgit-pgm?

Commit: "mavenizing step 2: move the core libs from src to src/main/java"

 * Please also add an empty line to this commit message.

 * You might as well squash the whitespace fixes into the first commit.

Commit: "mavenizing step 3: moving all core tests into the core module"

 * The commit message wrongly states:
    org.spearce.jgit.test/tst/ -> org.spearce.jgit/src/test/java/tst/
   Should be:
    org.spearce.jgit.test/tst/ -> org.spearce.jgit/src/test/java/

Commit: "mavenizing step 4: moving some license files and META-INF"

 * Shouldn't the commit message rather say "remove JSch"?
   Then the moving of META-INF can be put in its own commit.

 * The new NOTICE file has a few typos and the info could fit into the README

Then I got a bit lost in a huge reformatting.

-- 
Jonas Fonseca

Re: [JGIT] Request for help

[Mark Struberg]

doing a rebase -i with new stuff atm... ;)

LieGrue,
strub

--- On Fri, 9/4/09, Jonas Fonseca <jonas.fonseca@gmail.com> wrote:

> From: Jonas Fonseca <jonas.fonseca@gmail.com>
> Subject: Re: [JGIT] Request for help
> To: "Mark Struberg" <struberg@yahoo.de>
> Cc: "Douglas Campos" <douglas@theros.info>, git@vger.kernel.org, "Gabe McArthur" <gabriel.mcarthur@gmail.com>
> Date: Friday, September 4, 2009, 8:50 PM
> On Fri, Sep 4, 2009 at 13:28, Mark
> Struberg<struberg@yahoo.de>
> wrote:
> > Hi!
> >
> > Work has been done at
> >
> > http://github.com/sonatype/JGit/tree/mavenize
> >
> > Please feel free to pull/fork and share your changes!
> I'd be happy to pull it in.
> 
> IMO, there are a lot of things that can be squashed
> together and
> cleaned up. I know that you advocated for incremental
> introduction,
> but it seems wrong to for example add a file and then
> completely
> reformat it a few commits later. The same thing with the
> .gitignore
> fixes in step 5.
> 
> Some comments ... Some of them I initially entered in
> github's
> codereview, but I ended up writing it all here.
> 
> Commit: "mavenizing step 1: moved over the initial poms
> from Jasons branch"
> 
>  * Please always add an empty line between the subject and
> the body
>    of the commit message. Like this:
> 
>   mavenizing step 1: moved over the initial poms from
> Jasons branch
> 
>   Signed-off-by: Mark Struberg >struberg@yahoo.de>
> 
>  * The .gitignore pattern could be further limited to
> "target/" ...
> but you seem to change this to /target later.
> 
> In org.spearce.jgit/pom.xml:
> 
>     * The use of maven-surefire-plugin should be
> removed. This module
> does not have any tests.
> 
>     * Shouldn't we retain the original
> ${groupId}:${artifactId} naming
> convention, being org.spearce:jgit?
> 
> In org.spearce.jgit.test/pom.xml:
> 
>     * Dependency on jsch is unecessary since it
> is derived from
> org.spearce.jgit.
> 
>     * Maybe name as org.spearce:jgit-test?
> 
> In org.spearce.jgit.pgm/pom.xml:
> 
>     * Maybe name as org.spearce:jgit-pgm?
> 
> Commit: "mavenizing step 2: move the core libs from src to
> src/main/java"
> 
>  * Please also add an empty line to this commit message.
> 
>  * You might as well squash the whitespace fixes into the
> first commit.
> 
> Commit: "mavenizing step 3: moving all core tests into the
> core module"
> 
>  * The commit message wrongly states:
>     org.spearce.jgit.test/tst/ ->
> org.spearce.jgit/src/test/java/tst/
>    Should be:
>     org.spearce.jgit.test/tst/ ->
> org.spearce.jgit/src/test/java/
> 
> Commit: "mavenizing step 4: moving some license files and
> META-INF"
> 
>  * Shouldn't the commit message rather say "remove JSch"?
>    Then the moving of META-INF can be put in
> its own commit.
> 
>  * The new NOTICE file has a few typos and the info could
> fit into the README
> 
> Then I got a bit lost in a huge reformatting.
> 
> -- 
> Jonas Fonseca
> 


      

Re: [JGIT] Request for help

[Mark Struberg]

Thanks Jonas!

I now squashed a lot of commits together where possible and republished the rebased branch. 

Next steps:

* mavenizing org.spearce.jgit.pgm

LieGrue,
strub

--- On Fri, 9/4/09, Jonas Fonseca <jonas.fonseca@gmail.com> wrote:

> From: Jonas Fonseca <jonas.fonseca@gmail.com>
> Subject: Re: [JGIT] Request for help
> To: "Mark Struberg" <struberg@yahoo.de>
> Cc: "Douglas Campos" <douglas@theros.info>, git@vger.kernel.org, "Gabe McArthur" <gabriel.mcarthur@gmail.com>
> Date: Friday, September 4, 2009, 8:50 PM
> On Fri, Sep 4, 2009 at 13:28, Mark
> Struberg<struberg@yahoo.de>
> wrote:
> > Hi!
> >
> > Work has been done at
> >
> > http://github.com/sonatype/JGit/tree/mavenize
> >
> > Please feel free to pull/fork and share your changes!
> I'd be happy to pull it in.
> 
> IMO, there are a lot of things that can be squashed
> together and
> cleaned up. I know that you advocated for incremental
> introduction,
> but it seems wrong to for example add a file and then
> completely
> reformat it a few commits later. The same thing with the
> .gitignore
> fixes in step 5.
> 
> Some comments ... Some of them I initially entered in
> github's
> codereview, but I ended up writing it all here.
> 
> Commit: "mavenizing step 1: moved over the initial poms
> from Jasons branch"
> 
>  * Please always add an empty line between the subject and
> the body
>    of the commit message. Like this:
> 
>   mavenizing step 1: moved over the initial poms from
> Jasons branch
> 
>   Signed-off-by: Mark Struberg >struberg@yahoo.de>
> 
>  * The .gitignore pattern could be further limited to
> "target/" ...
> but you seem to change this to /target later.
> 
> In org.spearce.jgit/pom.xml:
> 
>     * The use of maven-surefire-plugin should be
> removed. This module
> does not have any tests.
> 
>     * Shouldn't we retain the original
> ${groupId}:${artifactId} naming
> convention, being org.spearce:jgit?
> 
> In org.spearce.jgit.test/pom.xml:
> 
>     * Dependency on jsch is unecessary since it
> is derived from
> org.spearce.jgit.
> 
>     * Maybe name as org.spearce:jgit-test?
> 
> In org.spearce.jgit.pgm/pom.xml:
> 
>     * Maybe name as org.spearce:jgit-pgm?
> 
> Commit: "mavenizing step 2: move the core libs from src to
> src/main/java"
> 
>  * Please also add an empty line to this commit message.
> 
>  * You might as well squash the whitespace fixes into the
> first commit.
> 
> Commit: "mavenizing step 3: moving all core tests into the
> core module"
> 
>  * The commit message wrongly states:
>     org.spearce.jgit.test/tst/ ->
> org.spearce.jgit/src/test/java/tst/
>    Should be:
>     org.spearce.jgit.test/tst/ ->
> org.spearce.jgit/src/test/java/
> 
> Commit: "mavenizing step 4: moving some license files and
> META-INF"
> 
>  * Shouldn't the commit message rather say "remove JSch"?
>    Then the moving of META-INF can be put in
> its own commit.
> 
>  * The new NOTICE file has a few typos and the info could
> fit into the README
> 
> Then I got a bit lost in a huge reformatting.
> 
> -- 
> Jonas Fonseca
> --
> To unsubscribe from this list: send the line "unsubscribe
> git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


      

Re: [JGIT] Request for help

[Gabe]

On Fri, Sep 4, 2009 at 10:28 AM, Mark Struberg<struberg@yahoo.de> wrote:
> Hi!
>
> Work has been done at
>
> http://github.com/sonatype/JGit/tree/mavenize
>
> Please feel free to pull/fork and share your changes! I'd be happy to pull it in.
>
> @Gabe: your patch seems to got filtered by the list, I think sharing such big things is easier by using github. Would be cool if you could help us!

Ok, I'll fork and send a patch request shortly.  I was thinking about
it earlier, and I may add a couple of features that all OS projects
should follow (e.g. License in the jar, etc.).

As to a few questions that have been raised:
1) I pick the 'sources' folder because it's good metadata management.
Everything in the root folder should be about or related to managing
the project.  No direct source folders, as it clutters the layout.
Best to be perfectly clear where all the action is happening.  It's a
simple convention I wished more projects followed.
2) I haven't worked with the find-bugs plugin.  I looked it up, but it
seems to only generate documents in the 'site'/reporting profile.
Thus it wouldn't necessarily affect the building of the software.  It
would really only be useful if you had something like a Hudson CI
infrastructure or site generation going on to build a website and show
the reports.  I could certainly add that, though, if you like.
3) The LICENSE file can be at the top level.  Not really an issue for
me one way or another.  Just a personal preference on how I have
structured all of my previous Maven projects.

-Gabe




>
> LieGrue,
> strub
>
> --- On Fri, 9/4/09, Mark Struberg <struberg@yahoo.de> wrote:
>
>> From: Mark Struberg <struberg@yahoo.de>
>> Subject: Re: [JGIT] Request for help
>> To: "Douglas Campos" <douglas@theros.info>
>> Cc: "Jonas Fonseca" <jonas.fonseca@gmail.com>, git@vger.kernel.org, "Gabe McArthur" <gabriel.mcarthur@gmail.com>
>> Date: Friday, September 4, 2009, 4:49 PM
>> Hi Douglas!
>>
>> http://github.com/sonatype/JGit
>>
>> The branch will be called mavenizing or so.
>>
>> Will post this after I got the tests running.
>>
>> LieGrue,
>> strub
>>
>> --- On Fri, 9/4/09, Douglas Campos <douglas@theros.info>
>> wrote:
>>
>> > From: Douglas Campos <douglas@theros.info>
>> > Subject: Re: [JGIT] Request for help
>> > To: "Mark Struberg" <struberg@yahoo.de>
>> > Cc: "Jonas Fonseca" <jonas.fonseca@gmail.com>,
>> git@vger.kernel.org,
>> "Gabe McArthur" <gabriel.mcarthur@gmail.com>
>> > Date: Friday, September 4, 2009, 4:44 PM
>> > On Fri, Sep 4, 2009
>> > at 9:47 AM, Mark Struberg <struberg@yahoo.de>
>> > wrote:
>> >
>> >
>> > as an old saying tells us: how to climb a mountain?
>> step
>> > after step! ;)
>> >
>> >
>> >
>> > I suggest we create a fresh branch based on the
>> Shawns
>> > current version and add all the features
>> incrementally.
>> >
>> >
>> >
>> > please point out where this branch will happen, I want
>> to
>> > give some help too.
>> >
>> >
>>
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
>
>
>

Re: [JGIT] Request for help

[Douglas Campos]

> Ok, I'll fork and send a patch request shortly.  I was thinking about
> it earlier, and I may add a couple of features that all OS projects
> should follow (e.g. License in the jar, etc.).

Gabe, is there some task that you want to share with me? I have a
short timeframe of 4hours to invest on mavenization.

Cheers
Douglas Campos (qmx)

Re: [JGIT] Request for help

[Gabe McArthur]

I'll post the pull request to github within  3-4 hours. Is that what  
you mean by invest?  My patch will contain everything I submitted  
before plus a bit more.  That patch set should contain everything  
necessary to build, plus any refinements to whatever is already in the  
'mavenize' branch.
-Gabe


On Sep 4, 2009, at 5:06 PM, Douglas Campos <douglas@theros.info> wrote:

>> Ok, I'll fork and send a patch request shortly.  I was thinking about
>> it earlier, and I may add a couple of features that all OS projects
>> should follow (e.g. License in the jar, etc.).
>
> Gabe, is there some task that you want to share with me? I have a
> short timeframe of 4hours to invest on mavenization.
>
> Cheers
> Douglas Campos (qmx)

Re: [JGIT] Request for help

[Robin Rosenberg]

fredag 04 september 2009 19:28:39 skrev Mark Struberg <struberg@yahoo.de>:
> Hi!
> 
> Work has been done at 
> 
> http://github.com/sonatype/JGit/tree/mavenize
> 
> Please feel free to pull/fork and share your changes! I'd be happy to pull it in.
> 

Why does this new mvn test only execute 1024 tests here, while the old maven setup
does 1108 ones? It seems the classes that don't match *Test.java are omitted.

In both cases I invoke with "mvn clean test"

-- robin

Re: [JGIT] Request for help

[Mark Struberg]

Haven't counted it, but I will check it.

Please note that for running the tests previously in 'exttest' you have to activate the tck profile:

$> mvn test -Ptck

And yes, we currently only run *Test.java. Any other patterns/files to include?

txs and LieGrue,
strub

--- On Sat, 9/5/09, Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:

> From: Robin Rosenberg <robin.rosenberg.lists@dewire.com>
> Subject: Re: [JGIT] Request for help
> To: "Mark Struberg" <struberg@yahoo.de>
> Cc: "Douglas Campos" <douglas@theros.info>, "Jonas Fonseca" <jonas.fonseca@gmail.com>, git@vger.kernel.org, "Gabe McArthur" <gabriel.mcarthur@gmail.com>
> Date: Saturday, September 5, 2009, 6:25 PM
> fredag 04 september 2009 19:28:39
> skrev Mark Struberg <struberg@yahoo.de>:
> > Hi!
> > 
> > Work has been done at 
> > 
> > http://github.com/sonatype/JGit/tree/mavenize
> > 
> > Please feel free to pull/fork and share your changes!
> I'd be happy to pull it in.
> > 
> 
> Why does this new mvn test only execute 1024 tests here,
> while the old maven setup
> does 1108 ones? It seems the classes that don't match
> *Test.java are omitted.
> 
> In both cases I invoke with "mvn clean test"
> 
> -- robin
> 


      

Re: [JGIT] Request for help

[Mark Struberg]

Hi!

Since I work on the sonatype repo and also being a maven guy, I'd be happy to help!

There are a few patches from the work we've done to come the next weeks anyway, starting with IgnoreRules and stuff. I think we still have to improve the code quality of SimpleRepository but I'd be happy to hear your opinion on this too, so I maybe send a RFC.

If you like to go with maven for JGIT, we have 2 options:

1.) Use the current directory structure and use the configuration you can see in the sonatype poms Jason did. E.g all paths have to be set in pom.sml


2.) Do a complete rework and move over to the standard maven layout [1] . This may include moving org.spearce.jgit.test/ to org.spearce.jgit/src/test/java resp org.spearce.jgit/src/test/resources. 
In the meantime Eclipse is really fine with handling separate target folders for production code and test classes (target/classes vs target/test-classes) so this is not a showstopper any more.


LieGrue,
strub

[1] http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html


--- On Thu, 9/3/09, Shawn O. Pearce <spearce@spearce.org> wrote:

> From: Shawn O. Pearce <spearce@spearce.org>
> Subject: Re: [JGIT] Request for help
> To: "Jonas Fonseca" <jonas.fonseca@gmail.com>
> Cc: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>, "Nasser Grainawi" <nasser@codeaurora.org>, "Git Mailing List" <git@vger.kernel.org>
> Date: Thursday, September 3, 2009, 5:52 PM
> Jonas Fonseca <jonas.fonseca@gmail.com>
> wrote:
> > On Thu, Sep 3, 2009 at 10:42, Shawn O. Pearce<spearce@spearce.org>
> wrote:
> > > Actually, now that we have forked out of the
> egit.git repository,
> > > I want to refactor the layout of the JGit project
> to be more maven
> > > like, and have a proper top-level pom to build
> things.
> > 
> > What kind of module structure do you have in mind? Do
> you want to move
> > some of the modules/subdirectories?
> > Some refactoring of the maven setup for JGit back was
> done back in
> > April in sonatype's (a maven company) JGit clone. It
> is not
> > signed-off, but can serve as a reference.
> 
> Yea, I was hoping they would contribute this back as
> patches,
> but thus far they haven't.
>  
> > The Maven layout in the sonatype clone simply uses the
> Eclipse project layout.
> > 
> > pom.xml: JGit :: Parent
> >  |- org.spearce.jgit/pom.xml: JGit :: Core
> >  |- org.spearce.jgit.pgm/pom.xml: JGit ::
> Programs
> >  `- org.spearce.jgit.test/pom.xml: JGit :: Test
> > 
> > However, having tests in a separate module can be both
> good/bad. For
> > example, they will not automatically get run when you
> only build the
> > Core module.
> 
> Yea, I know.  This is one area where Maven is just
> whack, by putting
> the tests in the same project the Maven plugin for Eclipse
> puts
> them into the same classpath, which means you can see test
> code
> from project code.  Wrong.  They should be
> different projects so
> the test classpath is isolated.
> 
> However.  This is a bug in the Eclipse plugin I think,
> not
> necessarily with Maven's approach of trying to keep tests
> alongside
> the code they test.  Thus we probably want:
> 
>   pom.xml: JGit :: Parent
>    |- jgit-lib/pom.xml: JGit
>    | 
>    src/main/java  <-- from
> org.spearce.jgit/src
>    | 
>    src/test/java  <-- from
> org.spearce.jgit.test/src
>    |
>    `- jgit-pgm/pom.xml: JGit pgm
>          src/main/java 
> <-- from org.spearce.jgit.pgm/src
> 
> IIRC there is Maven support to create proper MANIFEST.MF
> files for
> OSGI bundles, which is what we need for the Eclipse plugin
> support.
> That should be able to replace the META-INF/MANIFEST.MF in
> the top
> of each of the current directories.
> 
> > Anyway, I would like to help.
> 
> Please post patches; formatted with -M.  I do want to
> do this, I just
> don't have the patience and Maven-fu to write the new poms
> myself.
> 
> -- 
> Shawn.
> --
> To unsubscribe from this list: send the line "unsubscribe
> git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>




      

[JGIT] Request for help

[Nasser Grainawi]

Hello all,

I'm looking to add 'git patch-id' to JGit and I could use a few 
pointers. I'm not very familiar with the JGit code base or Java, so 
please excuse any blatant oversights or unintelligent questions.

First off, is there a "hacking JGit" document anywhere? One of those 
would be great right now.

So far I'm just trying to define the inputs and outputs. On Shawn's 
suggestion I'm planning on making it part of the org.spearce.jgit.patch 
package. C Git patch-id very generically has an input of a 'patch', so 
I'm thinking this implementation should use the Patch object. Looking at 
that class it seems that has everything patch-id should need, so perhaps 
that's the only input.

As far as output, C Git patch-id has the special feature to output the 
commit-id along with the patch-id when it gets input in the format of 
git-diff-tree. Should JGit do the same or just return the patch-id? I 
don't know that this question even makes sense in the context of JGit 
(since the commit-id is almost certainly available elsewhere and someone 
calling 'getPatchId()' is likely only interested in the patch-id).

Should PatchId be a class on its own, or just a method within the Patch 
class?

Thanks,
Nasser

Re: [JGIT] Request for help

[Johannes Schindelin]

Hi,

On Wed, 2 Sep 2009, Nasser Grainawi wrote:

> I'm looking to add 'git patch-id' to JGit and I could use a few 
> pointers. I'm not very familiar with the JGit code base or Java, so 
> please excuse any blatant oversights or unintelligent questions.
> 
> First off, is there a "hacking JGit" document anywhere? One of those 
> would be great right now.

There have been some mails with details about JGit from Shawn (IIRC) to 
this very list.

> So far I'm just trying to define the inputs and outputs. On Shawn's 
> suggestion I'm planning on making it part of the org.spearce.jgit.patch 
> package. C Git patch-id very generically has an input of a 'patch', so 
> I'm thinking this implementation should use the Patch object.

C Git patch-id takes a valid patch as input; I do not think that you want 
to use the Patch object.

FWIW a patch-id is nothing else than the SHA-1 of a diff where the "diff", 
"index", "@@" lines and all the whitespace was removed.

This is not really difficult in Java, however, it relies on a working diff 
implementation (and IIRC my implementation has not yet been integrated 
into JGit).

Ciao,
Dscho

Re: [JGIT] Request for help

[Shawn O. Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 2 Sep 2009, Nasser Grainawi wrote:
> 
> > I'm looking to add 'git patch-id' to JGit and I could use a few 
> > pointers. I'm not very familiar with the JGit code base or Java, so 
> > please excuse any blatant oversights or unintelligent questions.
> > 
> > First off, is there a "hacking JGit" document anywhere? One of those 
> > would be great right now.
> 
> There have been some mails with details about JGit from Shawn (IIRC) to 
> this very list.

Yea, for the most part I think we use Eclipse, and you just have
to import JGit's top level directory into Eclipse as it comes with
Eclipse project files.  But I know some folks only use our Maven
build (under jgit-maven/jgit) or use NetBeans.  I have no idea how
to import the project into the latter or configure its unit tests
to run.
 
> > So far I'm just trying to define the inputs and outputs. On Shawn's 
> > suggestion I'm planning on making it part of the org.spearce.jgit.patch 
> > package. C Git patch-id very generically has an input of a 'patch', so 
> > I'm thinking this implementation should use the Patch object.
> 
> C Git patch-id takes a valid patch as input; I do not think that you want 
> to use the Patch object.

I think we do want to use the Patch object.  The Patch entity in
JGit is a parsed representation of the git diff or unified diff
structure.  Its relatively easy to walk over, and all of the mess
about determining line type has already been done.

We'd probably want to do something that is a lot like the object
Patch as the output of our diff routine.  A tool (e.g. Gerrit Code
Review) might only want the EditList for a given file, and not
really care about the actual formatted patch text, as it reformats
everything itself.  I think patch-id computation is along those
same lines.

If we were to compute a patch-id off an InputStream we would probably
just send it through the Patch object first.

> This is not really difficult in Java, however, it relies on a working diff 
> implementation (and IIRC my implementation has not yet been integrated 
> into JGit).

Speaking of... where does that stand?

-- 
Shawn.

Re: [JGIT] Request for help

[Jonas Fonseca]

On Wed, Sep 2, 2009 at 21:22, Shawn O. Pearce<spearce@spearce.org> wrote:
> Yea, for the most part I think we use Eclipse, and you just have
> to import JGit's top level directory into Eclipse as it comes with
> Eclipse project files.  But I know some folks only use our Maven
> build (under jgit-maven/jgit) or use NetBeans.  I have no idea how
> to import the project into the latter or configure its unit tests
> to run.

NetBeans comes with very good support for Maven projects. Importing
JGit into NetBeans is just a matter of using the "Open Project" wizard
and locating jgit-maven/jgit. This will also configure the unit tests
to run.

BTW, what is your opinion of making it a bit easier to import and use
the Maven configuration by putting a pom.xml in the top-level
directory? The actual pom.xml file responsible for building the jgit
library can still live on in jgit-maven/ if that is preferable.

I am also thinking about "mavenizing" the .pgm subproject to make it
easier to browse and search the code from within NetBeans.

-- 
Jonas Fonseca

Re: [JGIT] Request for help

[Shawn O. Pearce]

Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
> BTW, what is your opinion of making it a bit easier to import and use
> the Maven configuration by putting a pom.xml in the top-level
> directory? The actual pom.xml file responsible for building the jgit
> library can still live on in jgit-maven/ if that is preferable.
> 
> I am also thinking about "mavenizing" the .pgm subproject to make it
> easier to browse and search the code from within NetBeans.

Actually, now that we have forked out of the egit.git repository,
I want to refactor the layout of the JGit project to be more maven
like, and have a proper top-level pom to build things.

Unfortunately it seems that nobody can program a proper Maven pom
for a multi-project project unless they are one of the authors
of Maven itself.  I watched the Apache MINA team struggle with it
until the Maven guys wanted to use their code, and fixed their build.

So, this refactoring is waiting for a Maven guru to contribute
an improvement.  Unfortunately they are all busy...

So, to answer your original question, yes, we should make this
better, and patches are welcome.  My own Maven-fu is just not up
to the task.

-- 
Shawn.

Re: [JGIT] Request for help

[Jonas Fonseca]

On Thu, Sep 3, 2009 at 10:42, Shawn O. Pearce<spearce@spearce.org> wrote:
> Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
>> BTW, what is your opinion of making it a bit easier to import and use
>> the Maven configuration by putting a pom.xml in the top-level
>> directory? The actual pom.xml file responsible for building the jgit
>> library can still live on in jgit-maven/ if that is preferable.
>>
>> I am also thinking about "mavenizing" the .pgm subproject to make it
>> easier to browse and search the code from within NetBeans.
>
> Actually, now that we have forked out of the egit.git repository,
> I want to refactor the layout of the JGit project to be more maven
> like, and have a proper top-level pom to build things.

What kind of module structure do you have in mind? Do you want to move
some of the modules/subdirectories?
Some refactoring of the maven setup for JGit back was done back in
April in sonatype's (a maven company) JGit clone. It is not
signed-off, but can serve as a reference.

 - http://github.com/sonatype/JGit/commit/641ae523c496f381a7673f4acfa0acdff9d3913e

The Maven layout in the sonatype clone simply uses the Eclipse project layout.

pom.xml: JGit :: Parent
 |- org.spearce.jgit/pom.xml: JGit :: Core
 |- org.spearce.jgit.pgm/pom.xml: JGit :: Programs
 `- org.spearce.jgit.test/pom.xml: JGit :: Test

However, having tests in a separate module can be both good/bad. For
example, they will not automatically get run when you only build the
Core module.

Anyway, I would like to help.

-- 
Jonas Fonseca

Re: [JGIT] Request for help

[Shawn O. Pearce]

Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
> On Thu, Sep 3, 2009 at 10:42, Shawn O. Pearce<spearce@spearce.org> wrote:
> > Actually, now that we have forked out of the egit.git repository,
> > I want to refactor the layout of the JGit project to be more maven
> > like, and have a proper top-level pom to build things.
> 
> What kind of module structure do you have in mind? Do you want to move
> some of the modules/subdirectories?
> Some refactoring of the maven setup for JGit back was done back in
> April in sonatype's (a maven company) JGit clone. It is not
> signed-off, but can serve as a reference.

Yea, I was hoping they would contribute this back as patches,
but thus far they haven't.
 
> The Maven layout in the sonatype clone simply uses the Eclipse project layout.
> 
> pom.xml: JGit :: Parent
>  |- org.spearce.jgit/pom.xml: JGit :: Core
>  |- org.spearce.jgit.pgm/pom.xml: JGit :: Programs
>  `- org.spearce.jgit.test/pom.xml: JGit :: Test
> 
> However, having tests in a separate module can be both good/bad. For
> example, they will not automatically get run when you only build the
> Core module.

Yea, I know.  This is one area where Maven is just whack, by putting
the tests in the same project the Maven plugin for Eclipse puts
them into the same classpath, which means you can see test code
from project code.  Wrong.  They should be different projects so
the test classpath is isolated.

However.  This is a bug in the Eclipse plugin I think, not
necessarily with Maven's approach of trying to keep tests alongside
the code they test.  Thus we probably want:

  pom.xml: JGit :: Parent
   |- jgit-lib/pom.xml: JGit
   |     src/main/java  <-- from org.spearce.jgit/src
   |     src/test/java  <-- from org.spearce.jgit.test/src
   |
   `- jgit-pgm/pom.xml: JGit pgm
         src/main/java  <-- from org.spearce.jgit.pgm/src

IIRC there is Maven support to create proper MANIFEST.MF files for
OSGI bundles, which is what we need for the Eclipse plugin support.
That should be able to replace the META-INF/MANIFEST.MF in the top
of each of the current directories.

> Anyway, I would like to help.

Please post patches; formatted with -M.  I do want to do this, I just
don't have the patience and Maven-fu to write the new poms myself.

-- 
Shawn.

Re: [JGIT] Request for help

[Gabe McArthur]

 
Shawn O. Pearce <spearce <at> spearce.org> writes:

> 
> Please post patches; formatted with -M.  I do want to do this, I just
> don't have the patience and Maven-fu to write the new poms myself.
> 


Hey,
I'm a build engineer with a considerable amount of "Maven-fu" :).  I've actually 
generated a patch that does everything you want (and a bit more).  I'm not that 
familiar with git's command line yet, so it's a bit tricky to get the patch 
thing right.  However, here's a rough overview of what I did:

ROOT
====
README
/bin
  bash.env   -- A script that you can source from Bash that
                will add the 'jgit' executable and the other
                scripts in this 'bin' directory to your PATH
  build.sh   -- A general build script, that hides some
                Maven complexities for initiates.
  tag.sh     -- Ok, this is the only thing that will have to 
                be re-written.  It's too tied in with git commands for
                me to fully extract what it's supposed to do.
/docs
  LICENSE
  SUBMITTING_PATCHES
  TODO
pom.xml      -- A considerable amount of build logic has been
                centralized here.  It references 3 sub-module
                projects, listed below.
/sources
  /jgit-lib
    pom.xml
    /src/main/java....
    /src/test
      /java....
      /resources 
      /exttst   -- Don't know exactly where this goes, as it
                   doesn't seem to be doing much/being run 
                   currently.
  /jgit-pgm
    pom.xml     -- Does the work to do a 'jar-with-dependencies' 
                   so that org.spearce.jgit.pgm.build can be removed.
    /src/main/java....
  /jgit-exec
    pom.xml     -- Actually generates the 'jgit' executable and
                   installs it in ROOT/target/bin, so that it will
                   be on your path after sourcing 'bin/bash.env'
    /src/main/scripts/jgit

I'll try to submit a full patch later, using your conventions.

My appreciation to Shawn for pointing out this thread....
-Gabe
                

Re: [JGIT] Request for help

[Mark Struberg]

Seems this speeds up lately ;)

Gabe, please allow me a few questions:

.) why do we need the /sources directory layer? I think /jgit and /jgit-pgm would be enough.

.) imho the docs should stay in / at least the LICENSE file

.) we don't need a tag.sh any more if we work with maven. Maven now has the maven-scm-provider-gitexe activated by default (since early 2008), so 
mvn release:prepare
mvn release:perform
should work if we set the proper <scm> section. Any feedback or bugreporting on the maven-git integration is highly welcome btw ;)


LieGrue,
strub


--- On Fri, 9/4/09, Gabe McArthur <gabriel.mcarthur@gmail.com> wrote:

> From: Gabe McArthur <gabriel.mcarthur@gmail.com>
> Subject: Re: [JGIT] Request for help
> To: git@vger.kernel.org
> Date: Friday, September 4, 2009, 7:00 AM
>  
> Shawn O. Pearce <spearce <at> spearce.org>
> writes:
> 
> > 
> > Please post patches; formatted with -M.  I do
> want to do this, I just
> > don't have the patience and Maven-fu to write the new
> poms myself.
> > 
> 
> 
> Hey,
> I'm a build engineer with a considerable amount of
> "Maven-fu" :).  I've actually 
> generated a patch that does everything you want (and a bit
> more).  I'm not that 
> familiar with git's command line yet, so it's a bit tricky
> to get the patch 
> thing right.  However, here's a rough overview of what
> I did:
> 
> ROOT
> ====
> README
> /bin
>   bash.env   -- A script that you can
> source from Bash that
>                
> will add the 'jgit' executable and the other
>                
> scripts in this 'bin' directory to your PATH
>   build.sh   -- A general build script,
> that hides some
>                
> Maven complexities for initiates.
>   tag.sh     -- Ok, this is the
> only thing that will have to 
>                 be
> re-written.  It's too tied in with git commands for
>                 me
> to fully extract what it's supposed to do.
> /docs
>   LICENSE
>   SUBMITTING_PATCHES
>   TODO
> pom.xml      -- A considerable amount of
> build logic has been
>                
> centralized here.  It references 3 sub-module
>                
> projects, listed below.
> /sources
>   /jgit-lib
>     pom.xml
>     /src/main/java....
>     /src/test
>       /java....
>       /resources 
>       /exttst   -- Don't know
> exactly where this goes, as it
>                
>    doesn't seem to be doing much/being run 
>                
>    currently.
>   /jgit-pgm
>     pom.xml     -- Does the
> work to do a 'jar-with-dependencies' 
>                
>    so that org.spearce.jgit.pgm.build can be
> removed.
>     /src/main/java....
>   /jgit-exec
>     pom.xml     -- Actually
> generates the 'jgit' executable and
>                
>    installs it in ROOT/target/bin, so that it
> will
>                
>    be on your path after sourcing
> 'bin/bash.env'
>     /src/main/scripts/jgit
> 
> I'll try to submit a full patch later, using your
> conventions.
> 
> My appreciation to Shawn for pointing out this thread....
> -Gabe
>                 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe
> git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


      

Re: [JGIT] Request for help

[Jonas Fonseca]

On Fri, Sep 4, 2009 at 03:33, Mark Struberg<struberg@yahoo.de> wrote:
> .) we don't need a tag.sh any more if we work with maven. Maven now has the maven-scm-provider-gitexe activated by default (since early 2008), so
> mvn release:prepare
> mvn release:perform
> should work if we set the proper <scm> section. Any feedback or bugreporting on the maven-git integration is highly welcome btw ;)

If tag_jgit.sh goes away, it could be nice to add a document showing
how releasing/tagging it's done the maven way.

-- 
Jonas Fonseca

Re: [JGIT] Request for help

[Mark Struberg]

Hi Jonas!

See the following documentation:

http://maven.apache.org/plugins/maven-release-plugin/index.html
http://maven.apache.org/plugins/maven-release-plugin/examples/prepare-release.html
http://maven.apache.org/plugins/maven-release-plugin/examples/perform-release.html

There is also a freely available book from sonatype [1] which contains all the documemtation you need - plus fn lot more :)

LieGrue,
strub

[1] http://www.sonatype.com/book/


--- On Fri, 9/4/09, Jonas Fonseca <jonas.fonseca@gmail.com> wrote:

> From: Jonas Fonseca <jonas.fonseca@gmail.com>
> Subject: Re: [JGIT] Request for help
> To: "Mark Struberg" <struberg@yahoo.de>
> Cc: git@vger.kernel.org, "Gabe McArthur" <gabriel.mcarthur@gmail.com>
> Date: Friday, September 4, 2009, 2:22 PM
> On Fri, Sep 4, 2009 at 03:33, Mark
> Struberg<struberg@yahoo.de>
> wrote:
> > .) we don't need a tag.sh any more if we work with
> maven. Maven now has the maven-scm-provider-gitexe activated
> by default (since early 2008), so
> > mvn release:prepare
> > mvn release:perform
> > should work if we set the proper <scm> section.
> Any feedback or bugreporting on the maven-git integration is
> highly welcome btw ;)
> 
> If tag_jgit.sh goes away, it could be nice to add a
> document showing
> how releasing/tagging it's done the maven way.
> 
> -- 
> Jonas Fonseca
> 


      

Re: [JGIT] Request for help

[Jonas Fonseca]

On Fri, Sep 4, 2009 at 03:33, Mark Struberg<struberg@yahoo.de> wrote:
>> From: Gabe McArthur <gabriel.mcarthur@gmail.com>
> >
>> I'll try to submit a full patch later, using your
>> conventions.

I have a question as well:

Support for using find bug is part of the Eclipse configuration (see
org.spearce.jgit/findBugs/), and I know that there's a find bug plugin
for Maven. From looking at sonatype's JGit repositories it is not
integrated. Have you managed to include it?

-- 
Jonas Fonseca

Re: [JGIT] Request for help

[Mark Struberg]

as an old saying tells us: how to climb a mountain? step after step! ;)

I suggest we create a fresh branch based on the Shawns current version and add all the features incrementally.

1.) move the directory structure over to mavens std layout
2.) create the scm section and try releases
3.) improve site generation and documentation
tbc


LieGrue,
strub


--- On Fri, 9/4/09, Jonas Fonseca <jonas.fonseca@gmail.com> wrote:

> From: Jonas Fonseca <jonas.fonseca@gmail.com>
> Subject: Re: [JGIT] Request for help
> To: "Mark Struberg" <struberg@yahoo.de>
> Cc: git@vger.kernel.org, "Gabe McArthur" <gabriel.mcarthur@gmail.com>
> Date: Friday, September 4, 2009, 2:41 PM
> On Fri, Sep 4, 2009 at 03:33, Mark
> Struberg<struberg@yahoo.de>
> wrote:
> >> From: Gabe McArthur <gabriel.mcarthur@gmail.com>
> > >
> >> I'll try to submit a full patch later, using your
> >> conventions.
> 
> I have a question as well:
> 
> Support for using find bug is part of the Eclipse
> configuration (see
> org.spearce.jgit/findBugs/), and I know that there's a find
> bug plugin
> for Maven. From looking at sonatype's JGit repositories it
> is not
> integrated. Have you managed to include it?
> 
> -- 
> Jonas Fonseca
> 


      

Re: [JGIT] Request for help

[Shawn O. Pearce]

Nasser Grainawi <nasser@codeaurora.org> wrote:
> Should PatchId be a class on its own, or just a method within the Patch  
> class?

Hmm, maybe a method on Patch is reasonable.

-- 
Shawn.

Re: [JGIT] Request for help

[Nasser Grainawi]

Shawn O. Pearce wrote:
> Nasser Grainawi <nasser@codeaurora.org> wrote:
>> Should PatchId be a class on its own, or just a method within the Patch  
>> class?
> 
> Hmm, maybe a method on Patch is reasonable.
> 

Going down this route, I'd add a few things to Patch.
patchId would be a private field (of type ObjectId?)
getPatchId would be a public method that returns patchId
and then likely a private method (computePatchId?) that actually 
generates the patchId

This way any method in Patch that would potentially change a Patch 
object's patch-id would call computePatchId before it returns.

Thoughts?

Re: [JGIT] Request for help

[Shawn O. Pearce]

Nasser Grainawi <nasser@codeaurora.org> wrote:
> Shawn O. Pearce wrote:
>> Hmm, maybe a method on Patch is reasonable.
>
> Going down this route, I'd add a few things to Patch.
> patchId would be a private field (of type ObjectId?)
> getPatchId would be a public method that returns patchId
> and then likely a private method (computePatchId?) that actually  
> generates the patchId

Sure, but getPatchId can compute it on demand on the first call,
and anyone who modifies the Patch would just need to clear out
the cached patchId value so the next call (if it ever comes) to
getPatchId would force it to recompute.

Most users of Patch won't want the patchId, so there is no reason
to compute it.

-- 
Shawn.

Re: [JGIT] Request for help

[Nasser Grainawi]

Shawn O. Pearce wrote:
> Nasser Grainawi <nasser@codeaurora.org> wrote:
>> Shawn O. Pearce wrote:
>>> Hmm, maybe a method on Patch is reasonable.
>> Going down this route, I'd add a few things to Patch.
>> patchId would be a private field (of type ObjectId?)
>> getPatchId would be a public method that returns patchId
>> and then likely a private method (computePatchId?) that actually  
>> generates the patchId
> 
> Sure, but getPatchId can compute it on demand on the first call,
> and anyone who modifies the Patch would just need to clear out
> the cached patchId value so the next call (if it ever comes) to
> getPatchId would force it to recompute.
> 
> Most users of Patch won't want the patchId, so there is no reason
> to compute it.
> 
Works for me, that's even easier. I'll get to work on implementing this,
but between (re-)learning Java and our legal dept, don't know when I'll
have a finished product to share...

I'll continue to post questions as I get them.
Thanks everyone for their help thus far :)