Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [egit-dev] How to build [EJ]Git?

Alex Blewitt <alex.blewitt@xxxxxxxxx> wrote:
> So, we've got EGit which builds manifest-first, and JGit which builds  
> pom-first?

Yes.  And as Jason said, it makes more sense than any other
configuration we could come up with right now.

> On Jan 6, 2010, at 14:48, Jason van Zyl wrote:
>> ...which probably makes the most sense because JGit as an artifact is 
>> consumed by other projects.

Yup, exactly.

> I suspect in the Eclipse world, it's only EGit that will consume JGit.  

Sure, in Eclipse based projects which load into the Eclipse
workbench, that's probably true right now.

But its not true in the larger sense of the world.  JGit is a very
critical component of Gerrit Code Review, the latter doesn't exist
without the former.  Gerrit's build system is pom-first Maven 2.
It can't consume a manifest-first Maven 3 based build artifact.

NetBeans Git plugin consumes JGit.  Its unreasonable right now to
ask them to upgrade to the alpha version of Maven 3 just so they
can use a manifest-first based build artifact.

JIRA Git plugin consumes JGit.  JIRA plugins are typically built
using Maven 2.  We can't ask them to upgrade to Maven 3 just to
include JGit.

Hudson CI plugin consumes JGit.  Hudson CI plugins are typically
built using Maven 2.  We can't ask them to upgrade to Maven 3 just
to include JGit.

JGit _easily_ has 4 consumers that matter, and only 1 of them wants
the #@!*@ MANIFEST.MF files present in the build artifact.  The other
3 are all compiled with Maven and _want_ us to be in Maven central
and building with Maven 2, so its easier for them to consume us.

pom-first/Maven 2.x is the right approach for JGit in 2010.  Ask me
again about manifest-first in 2011 when Maven 3 has a few stable
releases out the door, is widely deployed, and most developers are
compiling their code with it.

> That doesn't prevent other IDEs from consuming JGit, but I don't think  
> that is relevant - development of JGit is mostly done in Eclipse. And  
> having the ability to work on both EGit and JGit in the same workspace  
> is necessray.

Development of JGit happens primarily in Eclipse because primary
development of JGit is done by me... and I use Eclipse.

Development of JGit doesn't happen *only* under an EGit parent
however.  Sometimes I'm hacking on/debugging JGit as part of my
Gerrit Code Review workspace, and its larger daemon environment.
Sometimes I'm hacking on JGit as part of my EGit workspace.

To be perfectly blunt, right now my $DAY_JOB pays me to focus more
on Gerrit Code Review than it pays me to focus on EGit.  A lot
of my JGit development happens to support Gerrit Code Review.
The fact that this trickles down into EGit is a nice side-effect,
but not a primary motivator for myself or my $DAY_JOB masters.

We do have some development in JGit from Jonas Fonseca.  E.g.
commit a0a0ce8e5d8231a98b00b9b431049034dcf59d2e came from him.
He develops in NetBeans... *not* Eclipse.

Eclipse based development isn't the only environment we care about
for JGit.

> So, what was the purpose behind being a 'normal' Maven build?

See above, I think I've explained myself well enough.

-- 
Shawn.


Back to the top