Re: [egit-dev] How to build [EJ]Git?

[Jason van Zyl <jason@xxxxxxxxx>]

On 2010-01-07, at 11:17 AM, Thomas Hallgren wrote:

> Hi Jason,
> I think the essence of our agreed disagreement is well captured in this paragraph.
> 
> On 2010-01-07 16:27, Jason van Zyl wrote:
>> 
>> Again, we will have to disagree because that just riles any serious build automation engineer. I believe that type of coupling is categorically wrong. I believe fidelity is required, I believe that the core logic should be shared, but it has to have started outside the IDE and then embedded in the IDE to provide the same characteristics. Going from what exists in the IDE that has grown out organically is a problem. This is why so many people have problems with automated builds in Eclipse because much of it is so coupled to Eclipse internals. I personally do not believe running a headless Eclipse instance is a sane thing to do for CI for example which I see a lot.
>> 
>>   
> 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. Ever tried it on a Unix machine without X installed? Every tried it with a build and release engineer who's never used an IDE? It doesn't just work. Nothing just works. Maven and Ant included and requiring an installation of Eclipse doesn't make this easier.

> Keep in mind that the Eclipse build infrastructure is inherently headless. You only need a limited set of bundles in order to run a fully automated workspace build. The headless/UI separation extends to management of the target platform and also to the team providers. This means that the TP can be provisioned using Eclipse .target definitions and source check-outs can reuse existing team repository providers.

See, you've already conflated Eclipse target platforms in there because your systems aren't meant to cope with non PDE/OSGi projects. To me it happened backward and the IDE came first and the automated builds second. The reason I give priority to the automated builds is that in most organizations product are release by build and release engineers, the legal compliance happens with the products of builds from release engineers not developers. Using the IDE itself to build is just not a good practice because it drags the developers world into the automated build environments where it doesn't belong.

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.

> 
> 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. IDEs or accompanying products. They should be fundamentally embeddable. We have successfully embedded Maven inside Eclipse, Nexus, and Hudson. Not out of process integration, but core integration. We have one single library that works independently of all these integrations but works with them as well. I would argue that regardless of the environment the inputs have parametric equivalence and the outputs should be equal. I think here we agree, but I do not this requires pulling along the entire baggage along of Eclipse to do this. You are constructing software, this can happen inside or outside of an IDE. Inside or outside of a CI system. 

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.

> The reason being that you should support Netbeans or IDEA users. And OK, if that support is very important, then I agree that Maven/Tycho has a good position. If it's semi-important, then I would argue that if what's needed is a build system that builds separately from the IDE, why not use the 'headless Eclipse instance' to do that? It's there anyway.

We're doing what users and customers are asking us to do. Just because it's there doesn't mean it's right or the best solution and ultimately over time people are going to decide. I think Tycho is the proper hybrid, and you think otherwise. The build mechanism can be nothing more then a library, there needs to be a fidelity of results between automation and what the developer produces. The fidelity should be the result of using the same core library not using the developers environment in a place where it doesn't belong.

> 
> - thomas
> 
> _______________________________________________
> egit-dev mailing list
> egit-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/egit-dev

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------