Re: [Gitclipse-devel] NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha

[Andrew C. <ac...@co...>]

Shawn, See my comments below.
Javagit, You should include Maven on your requirements.  See some 
license/design comments below.
Gitlcipse, See some license/design comments below.


> I'm glad to see the effort but forth, even if it isn't the direction
> I would have (or already have) taken.

Thanks.  I'm sure regardless this will stur up some interest in either 
of our projects.  We considered working on a full implementation as well, 
but we decided it would be much easier to do a wrapper for now and if we 
wanted to build in a native interface later we could.  I think as long as 
someone has the time to write/support an entire native implementation, 
then this definitely has its advantages.

> >> There are many reasons we decided to go our own route some of these
>> reasons are as follows:
>>
>> 1) We found egit extremely difficult to deal with compile, install,
>> utilization wise.
>> 2) We had problems getting egit to work perperly although at the start of
>> our project this may have just been unfamiliarity with eclipse.
>
> Well, we don't have an update site yet, because we don't think its
> really something a mortal can make use of yet.  This is a problem
> because we also don't attract a lot of developer effort, because
> they just want to use the plugin, not make it better.
> Its actually fairly easy to build.  Clone, import.  Then run a
> debug workbench, or export the feature to a directory, and install
> new plugins from that directory.  But that's besides the point.

It might not be that bad for someone that is rather familiar with how to 
do it and is pretty comfortable using eclipse, but for a common user, 
that's way too much to ask.  But as you said, you didn't think it was to 
that point yet anyway.  Which in return means little interest.  It's kind 
of the chicken and the egg thing.  It's hard to get developers without a 
complete project, it's hard to get a complete project without developers. 
We're trying to have a simple install but not very complete project as of 
yet in hopes of attracting some developers.

> I had a harder time trying to install javagit and gitclipse today,
> as I didn't have Maven available to build javagit and I didn't want
> to have to download it just to build a small Jar.

Gitclipse doesn't actually require you install javagit, which means you 
just install using the standard plug-in install method.  Javagit's build 
is a bit more complicated because of maven it's true (I don't see this 
listed on their requirements page... I'll post to their user list about 
it, thanks for the mention).

>> 3) The javagit people found jgit lacking documentation and felt it would
>> be easier to write their own going in a different direction than to try
>> and jump into your project and starte mangling your code.
>
> Interesting.  We've written a lot of Javadoc.  There's very little of the
> public API that isn't documented already.  I would have loved to have at
> least read their comments so we could take it for future improvements.

I'm not sure there was any comments about specific situations.  I it was 
having a hard time following the code in general.  It's something that 
tinkering with it for a month or so probably would have solved, but there 
was a greater desire on their part to just get started and write our own.

>> 4) There was egit/jgit code available, but we didn't see much talk about
>> it on the mailing lists except people asking if it was dead or not (with
>> no replies).
>
> It varies from week to week.  Some folks on the Git list have asked
> us to always include [JGIT PATCH] in our patch subject lines so
> they can filter the patches to /dev/null, because at times the
> volume is too much for them.

Yeah, we seperated our javagit and gitclipse lists long ago because the 
flow was way too much and really there isn't too much cross talk between 
the two.  I definitely have seen an upshot of activity in jgit/egit since 
the SoC started which is great, but we started our project before SoC so 
this activity build up was too late for us to notice.

>> 5) License confusion/incompatibilities.  Some of your documentation says
>> some source is GPL, some LGPL, and some EPL, while others say BSD and EPL
>> only.  It seems you've switch on a couple occasions and it seemed even
>> unsure of itself.
>
> This is true, we floundered around for a while on the license issue.
> We finished a relicensing effort back near mid-May.  The licenses
> are now as follows:
>
>  jgit:  100% 3-clause BSD
>  egit:  100% EPL
>
> The jgit code is purely under org.spearce.jgit.* and the egit code
> is under org.spearce.egit.*.  The licenses will become even more
> clear when we split the repository.
>
> An interesting issue/aspect of jgit's license is just that.  It is
> the much more permissible 3-clause BSD, while git.git is GPLv2.  As
> we do roughly the same functions, but different implementations, the
> code in JGit is a path for someone to bypass the GPL of git.git and
> still have a high-quality Git implementation.  This also slows us
> down as we cannot directly port code from git.git.

Yeah, we discussed a lot of license issues and settled on LGPL for javagit 
and simply require that git already be provided by the user so we don't 
have any distributing issues.  And again, we probably would have based our 
plug-in on egit had it been seperated out from jgit and if it hadn't been 
under the EPL since at the time we wanted ours GPL.  About halfway through 
we decided to switch to EPL, but by then it was too late to just switch to 
your plug-in.


>> Established is a relative term.  I'm not belittling your accomplishments,
>> but as said you have been working on it for 2.5 years and you still don't
>> have a plugin installer?  People posting on message boards about it are
>> often seen asking if the project is dead.  5 months between releases
>> seems a bit like a project strugling to survive.  I realize this is a lot
>> of work for a small number of people contributing, but from a public
>> perspective this didn't appear to be progressing very fast.
>
> True.  git-gui by the same token is dead.  So is gitk.  Yet the
> latter two are each 1 man projects that are still core to the Git
> user experience.

I agree those projects aren't dead, but I don't think they're in the same 
boat.  I didn't say egit/jgit was dead either though, I just said it 
looked like it may have been strugling.  Also, those other applications 
have standard build and install setups as far as I know and are included 
in a number of major distros.  So they're pretty well established in that 
regard.  Jgit/Egit, not so much (unfortunately since I think it's a good 
project and everyone would benefit from a good Git Eclipse plug-in).

> Our next release will likely feature an update site and something
> an end-user can actually _use_.  It also has to be this fall, for
> other reasons beyond me just saying that.  It would be nice if we
> could pick up a few more contributors as a result of that release.
> One can hope.

I'm glad to hear it!  I'm sure if you do have any easy install then it 
will gain contributors.

>> In your own README you have paragraphs bashing Java and jgit's
>> performance (although most of your arguments are even admittedly
>> outdated).  Saying your choice is for performance seems a bit
>> wishy-washy.  Maybe it's improved and your documentation is out of date?
>
> This is very outdated.  Once the JIT comes online and has a chance
> to actually optimize jgit's bytecode jgit performances _very_ well.
>
> In our early days we took a _horrible_ misstep with our code and made
> some poor design decisions in the object model.  Ok, _I_ made those
> mistakes and the rest of the group followed on top of that lead.
> We have had to rewrite that code and back out of that misstep to
> get the performance into acceptable levels.
>
> Thanks for pointing this out; I must have forgotten to patch the
> README after we started this internal transition.

You may want to clean up the licensing issues while you're at it (maybe 
you already have, I'm not sure I have the latest clone).

>> We originally didn't want to use your plugin because we originally were
>> going to be a GPL'd plug-in.  We have since migrated over to an EPL
>> license so we could benefit from the work of others.
>
> We originally wanted to be GPL too, but we actually want the Eclipse
> plugin to fold into the standard Eclipse IDE releases, like the CVS
> team provider.  To do that we must be licensed under the EPL, and in
> extreme cases, we can link to a BSD library.  Hence we had to avoid
> the GPL and relicense everything under EPL+BSD.
>
> Yet another misstep we made early on.

We hadn't ever discussed actually trying to have eclipse ship with 
Gitclipse by default but at current that wasn't an option for us (since 
git is required).  That makes sense for your project though.

>>>> If this really was something that was holding back the adoption
>>>> of and contribution to jgit, we'd split it tomorrow, and suffer
>>>> the pain of needing to segment development branches.
>>
>> You seriously should consider doing this.  I don't think you are doing
>> yourselves any favor in staying coupled.
>
> Maybe we'll split it sooner rather than later.

Good luck, we've both got our work cut out for us.

--
Drew