[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [egit-dev] jgit and eclipse meta-data.
|
On 2010-01-09, at 4:57 PM, Alex Blewitt wrote:
> I've used the Maven build combo and PDE (or just JDT) in production systems where I work in the past with no problem.
You maintained two sources of dependencies? I have honestly never found that to work.
> It's not a big chore to sort them out. I also think that the debate is not helping the development of JGit in any valuable way, and that these are potentially dissuading others from joining in.
>
I think that's speculative at this point. I have no problem if others want to maintain another build. I've just never found this to be a maintainable solution.
> Many projects have IDE specific files checked in to allow people to check out and go. In this case, the Manifest is an example of a PDE/IDE specific file - it doesn't have to be the final one in the build. And even generated files can get checked in - EMF projects do this all the time, for example. When you need to change a dependency, you can just check it in.
>
> Arguing that there must be only one way (whichever way that is) will cause problems for the other. We can either take the middle road (and use both) or leave JGit as a maven-only solution that is built and developed outside of PDE. If that's the case, we might as well check in a JAR into Orbit and treat JGit like any other third party dependency and be done with it.
>
Don't conflate what can be done with what I think should be done. You guys do what suits the project best. My professional opinion is one build system, interoperate at the repository level. Anyone who is truly interested in working on the code is going to figure it out. PDE Build, Ant, or Make being present has never stopped me from hacking on something. If someone actually said I'm not going to hack on your project because you only use X, then I would deem that puerile. Someone who wants to participate is not going to be blocked by one technology or another. You'll find a way to help.
> Alex
>
> Sent from my (new) iPhone
>
> On 9 Jan 2010, at 21:29, Jason van Zyl <jason@xxxxxxxxx> wrote:
>
>>
>> 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
>> ----------------------------------------------------------
>>
>> _______________________________________________
>> egit-dev mailing list
>> egit-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/egit-dev
> _______________________________________________
> 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
----------------------------------------------------------
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
