[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [egit-dev] How to build [EJ]Git?
|
On Jan 6, 2010, at 15:42, Jason van Zyl wrote:
On 2010-01-06, at 10:23 AM, Alex Blewitt wrote:
So, we've got EGit which builds manifest-first, and JGit which
builds pom-first? That sounds like a recipe for disaster. Surely it
would be better to do them both in the same way, so that you don't
have to have two sets of instructions, one for each?
I think this is the way it should be done actually. Go read Shawn's
diatribe on the review commits. I think he's right in most cases.
The JGit artifact needs to be a good Maven artifact and a lot of
people looking at just JGit don't care about Eclipse or anything
OSGi related.
That's fine, I have no objections to the Maven artefact being
something that is consumable outside of OSGi. But then again, all OGSi
JARs are consumable outside OSGi as normal JARs anyway. The only
difference between the two is whether there's any code dependencies on
OSGi, and I don't see anyone ever having suggested that that was the
case.
The other point to note is that consumers != developers. A maven
build, even if it's Manifest first, is still something that's
buildable by the commandline outside of Eclipse. So people who want to
integrate/use JGit are entitled to do so outside of an Eclipse/OGSi
environment with no problems.
It will likely just turn folks off having to deal with the extra
complication. The approach we would like to take here is make the
maven-bundle-plugin more efficient and integrate it with PDE. Stuart
works at Sonatype so this is fully within our realm to complete.
The extra complication, of having two project styles, is already here.
Having one way of building them makes sense. It makes absolutely no
sense to remove Eclipse metadata from an SCM just because some people
might not use Eclipse. There's no reason to not have it, and just
ignore it if it doesn't make sense to you. I've edited files by hand
with Vi before when doing updates to an Eclipse project without even
caring where it was come from. I've also multi-sourced projects to
include Eclipse and NetBeans and IntelliJ data in the same project to
allow developers to use whatever tool they're comfortable with. Yes,
it means that if you need to make a dependency change, there's
multiple places that it needs to be done - but JGit is almost
obsessive about not introducing more dependencies than is absolutely
necessary.
I suspect in the Eclipse world, it's only EGit that will consume
JGit. 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.
I don't think that's true.
Really? Hands up anyone who develops JGit outside of Eclipse right
now ...
So, what was the purpose behind being a 'normal' Maven build?
Proper POM that's easily maintainable, and having a build that
doesn't expose any OSGi for other integrators. JGit will be
integrated into IDEA and Netbeans I'm sure.
Manifest-first doesn't expose OSGi for other integrators. It's just a
different format. Again, this doesn't prevent integration into IDEA
and NetBeans, either from a consumer perspective or from a developer
perspective.
As a maven-bundle-plugin project the manifest is generated. Though
I think creating a BND file which represents the final manifest
would be better ...
If we're doing that, we might as well use Manifest-first
development. After all, the only difference is syntax - you still
have a file you must manage/maintain in SCM.
Seriously go read the review commit log from Shawn about having to
deal with the manifest-first mode for JGit. I don't think it can be
at this point.
Based on what assertion? There seems no technical reason why we need
to do this in order to develop JGit. All there are are
misunderstandings which can be rectified.
We'll make it work, and it's another important bridge between POM-
first and manifest-first builds. We don't mind getting that work.
Cases like this are going to be pretty normal for a few years.
Why don't we just have something that works now? We seem to have
bazooka'd ourselves in the foot at this point to make it more
difficult to develop. I'm all for Maven and Tycho, but this seems to
be absolutely the worst way to convince Eclipse(.org) that building
OSGi artefacts with Maven is a sensible way of doing things.
I believe the right way it is:
JGit = POM-first
EGit = Manifest-first
I believe this prevents people working on JGit, and by extension,
EGit. Whether it's correct from a purists perspective or not is a
different matter.
And we'll just have to make it work in the workspace.
This seems to be a big distraction in terms of time and effort purely
to satisfy a philosophical argument that detracts from being able to
do work on E/JGit. Even before both moved to Eclipse, it was still
possible to build these as Eclipse projects. Now we don't even have
that.
Sure it's wrong, but integrating POM-first and Manifest-first in
Eclipse is new territory and we're happy to do the work. But
ultimately this is your project, we're just trying to help so choose
the tool that works best for you.
I appreciate the help, and I look forward to this working. But this
still doesn't answer the observation that doing JGit one way and EGit
the other way is wrong. That, I believe , is the decision that needs
to be unmade in order to move forwards, rather than wasting time
solving meta-problems.
Alex
PS The JGit list is separate; however, when one was created, it didn't
seem to copy over the membership. This sounds like the kind of
decision that should cc both mailing lists for respective input.
