[
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
