Re: [egit-dev] jgit and eclipse meta-data.

[Jason van Zyl <jason@xxxxxxxxx>]

On 2010-01-09, at 2:50 PM, Thomas Hallgren wrote:

> Jason van Zyl wrote:
>> 
>> It is all eclipse tooling. If you're saying that it has to consist of only tools that exist at eclipse.org then I'm going to tell you you're being provincial.
>> 
>>  
> 
> I don't want to shut out Maven/Tycho. But I don't want Maven/Tycho to shut out other ways of building either.

A given project generally doesn't have multiple ways to build. That just doesn't happen in practice. It's just too hard for the developers.

> I'm trying to find a middle ground that would work for all without enforcing use of Maven/Tycho. That's hardly provincial. Making the project "maven only" could be perceived that way though.

How many projects do you know that have the developers maintaining multiple ways of building the project? It just doesn't work. I have been in many organizations where there were multiple build tools -- which is always going to be the case -- and they interoperated at the repository level. Every project can't build with multiple tools. That's just highly impractical. But I imagine that we can interoperate at the P2 repository level.

So if I walk into a project that uses Buckminster to build are you going to maintain a Maven build? Do you want to maintain the tools to generate a Maven POM and all the development tools to make sure it's a good experience everyone who wants to develop with Maven? I highly doubt that. It simply wouldn't be practical.

There are thousands of open source projects that are Maven only, PDE Build only, Ant only. Having a single project work at the development level for multiple systems just isn't a workable situation.

> 
> 
>> What I would be willing to do is figure out what the actual requirements are for integrating into the production stream for the standard distributions. From what I can tell this doesn't require Buckminster but a P2 repository that can be integrated.
>> 
>>  
> Several projects base their CI on Buckminster. Most others are based either on Athena or something proprietary. None of them introduce workflows that blocks other builders. I'm convinced that the best path forward is to make the build systems interact, hence and my interest in improved Maven integration for Buckminster.

Well, that's just not the way I've ever seen this done in a production environment. That simply would not work in a large organization and I doubt that would work here or be necessary. If another build tool surfaces you are then going to posit that it should interoperate with every other build tool here? I can build Eclipse distributions with Tycho with a P2 repository regardless of the source. If you're saying that Buckminster can't put together the standard Eclipse distributions using normal P2 repositories then maybe we can show you some example with Tycho that do not require N-way integration between build tools. Maybe this long term is a more practical solution.

> 
> 
>> 
>> The manifest is not the source of dependency information in the case of the JGit project. The result bundle that is produced is just a JAR, yes. And the manifest is present there when the build is done, but it's not what's used during development of JGit.  That is being mediated by M2Eclipse during development.
>> 
>> It's probably not a horrible thing to check in the manifest but will probably lead to spurious results and I think it's better not to let that happen. The manifest information is abstracted in OSGi itself so we're going to exploit that fact and we have another source. We will, in short order make this work nicely with PDE. If PDE understands it then development should be smooth.
>> 
>>  
> I think the 'generated dependency' argument is a poor excuse for forcefully generating the manifest. Package import/export statements control visibility for the bundle and should be a concern of the compiler and the runtime, not the build system. Bundle start levels, activator, etc. are also integral parts of the bundle. If Eclipse is targeted, then dependencies are better captured higher up (in features). If not, then I guess the POM is a good way to declare them. But that does not mean that you must generate the manifest since the manifest typically won't list the actual jars that it depends on.

I think you need to go look at BND as the maven-bundle-plugin is only a thin wrapper around that. It can control anything that you might put in a manifest. Some people use a BND file and generate the manifest from that where it's just a convenience format. And others use instructions in the POM to generate the manifest, but there is additional configuration in the plugin to control the OSGi-ness of the project. Peter Krien's wrote BND so I doubt any tool is going to be any more OSGi friendly then what he makes.

> 
> If all files are checked in (.project, .classpath, manifest, build.properties, pom, etc.) then I'm fairly certain that it would not block any development, nor usage of the jgit bundle. The current situation however, is indeed blocking every other usage then Tycho/Maven.

Not my call. I'll leave it to the folks working on the project to decide. But saying Tycho/Maven is blocking development is like saying every Buckminster build is blocking every non-Buckminster development effort. I think that's a fairly unreasonable assertion. You may find using M2Eclipse or Tycho loathsome but it doesn't seem like it bothers the developers on the project.

> 
> Regards,
> Thomas Hallgren
> 
> _______________________________________________
> 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
----------------------------------------------------------