[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [egit-dev] How to build [EJ]Git?
|
On 2010-01-07 19:12, Jason van Zyl wrote:
The 'headless Eclipse instance' that you rule out is an plug-in framework with some bundles. How is that different from Maven?
One important difference is of course that this framework is built on OSGi and can utilize the exact same build environment as you normally do in the IDE. There is no separate installer. No redundant meta-data, no additional plug-in framework. It just works.
If you're talking about a headless Eclipse install, it does not just work.
Try installing running our minimal packaging of the p2 director
application. You'll find it here:
http://www.eclipse.org/buckminster/downloads.html
With that as a starting point, you can configure a purely headless build
system that includes only the bundles needed to for the task at hand.
Ever tried it on a Unix machine without X installed?
There is absolutely no UI code present (no launcher executable, no SWT,
no libcairo, etc.), so I would be very surprised if it didn't run
without X installed. It works very well using automated Hudson builds.
Every tried it with a build and release engineer who's never used an IDE? It doesn't just work. Nothing just works.
This is a command line tool. It doesn't require any knowledge about the
IDE. And I can assure you, it works very well.
I sense that there is some misconception that in order to run a build
using Eclipse, you need the full shebang. I.e. the IDE. That is not the
case.
The build that counts that is going to be the basis of complete QA and a shipping product is the automated build and that cannot be conflated with the developers world.
I've never understood why separate build systems are needed for
different use-cases. A good build system should be able to build the
software regardless.
You advocate that the sane thing to do is to duplicate all of that into another build system and then maintain it separately.
That's not what I'm saying at all.
I'm saying the core system used to construct the software should be a core that stands on its own which can then be layered into any other tooling.
What's wrong with building the core system on top of the Eclipse OSGi
framework then? And leverage everything that's already there? There's
nothing stopping you from layer such a build system into any other tooling.
We have successfully embedded Maven inside Eclipse, Nexus, and Hudson.
Your embedding doesn't leverage the Eclipse build system. You duplicate
most parts in order to build 'the maven way'. So I'm sorry, but I'll
persist in claiming that you advocate that the sane thing to do is to
duplicate an already existing build system.
You are constructing software, this can happen inside or outside of an IDE. Inside or outside of a CI system.
Exactly. And what could be better then using the exact same build system
at all times?
I think you actually completely agree with me or you wouldn't be attempting to make B3 which is essentially exactly what I'm talking about. A general build mechanism that requires the IDE is just not something that flies in very many release engineering departments.
Buckminster is already good proof that a general build mechanism, built
on Eclipse, does not require the IDE.
Our objective with b3 is to make the build model more central and to
integrate even closer with the Eclipse IDE. For instance, we want to
enable problem markers for potential build problems and add source code
debugging of the build. We also want to continue on the path where the
build that executes will be the same, no matter where or how it is executed.
Integration with other IDE's is not one of the b3 objectives at this
point although we do believe that the model centric approach will make
that task easier.
Regards,
Thomas Hallgren
