Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [egit-dev] jgit and eclipse meta-data.

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. 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.


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.



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.

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.

Regards,
Thomas Hallgren



Back to the top