Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] dependencies, build and P2

I have suggested this before, but since this seems to be in the same domain, I'll suggest it again.

Instead of having each project that participates in the train define their own set of inputs, why doesn't Eclipse.org set up a repository infrastructure that reflect the requirements and publications of the +0 to +n in the train? The flow would be something like this:

A base repository is consumed by all +0 builds. This base is essentially the Orbit repository (an agreed version or composite) since no other input exists. The +0 builds will then produce a +0 repository which essentially is a composite of the base repository and all output from all +0 builds.

The +0 repository is consumed by all +1 builds. The product is a +1 repository which consists of the +0 repository and all output from the +1 builds.

The +1 repository is consumed by all +2 builds, etc.

- thomas

On 2010-12-18 09:04, Eike Stepper wrote:
+1

Am 17.12.2010 21:17, schrieb Miles Parker:
On Dec 17, 2010, at 12:30 AM, Nicolas Bros wrote:
Actually, I think the problem is not with the dependency in the Manifest.MF. It is with the p2 update site. I have noticed that when p2 builds an update site, it restricts the dependencies to the versions of the bundles that were used for the build that produced this update site.
Yes, I think this is precisely the problem that I was having with BIRT! I didn't have any dependency incompatibilities, so my project built locally and in other configurations just fine, and the problem doesn't actually occur until you try to put it into repository, and that depends on what combination of P2 sites you're using. My feature said it didn't care about what version of BIRT I was using, yet when deployed it mattered very much. Does this seem wrong to anyone else? Why should users be prevented from doing an install when they have completely appropriate features and plugins as defined by the actual artifacts? It's as though the build/provisioning process is taking over and overriding the intent of the design.

I'm sounding like a broken record, but this is more support for what I've been saying about Buckminster rmap and P2 aggregation being orthogonal. Just because it builds in Buckminster does *not* mean that it will work appropriately in the overall ecosystem. And this ends up meaning that we all need to know way more about each other's dependencies than we ever should have to.

I'm not criticizing the current setup per se -- I can see why all of the design choices were made individually, but when you put it all together the whole system seems more brittle and inflexible than it has to be. I don't know to what extent this is due to technology and to what extent process, and I will happily concede that the best argument for the current approach is that you can't argue with success, but it sure seems to require a lot of work to get these things sorted.

cheers,

Miles

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



Back to the top