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.
cross-project-issues-dev mailing list