> I think there is also another thing to consider. IMHO projects should stop > hard-pinning specific 3rd party versions in the feature.xml - at least in > the feature they submit into the common repo. This triggers p2 to install > multiple versions into packages.
Speaking from the perspective of one of the projects that currently do this, I'm all in favor of changing that. I think what would be needed would be a clear best practice for making sure that 1. a version that my project can work with is contributed to the simrel repo (and to my project's repo as well) 2. the bundles don't show up in "Install New Software..." Before I added the orbit bundle to my feature, I tried around quite a bit, and - widening the version in the feature via p2.inf will result in the bundle no longer included in my repository by default - including the bundle in the repository explicitly via the category.xml results in it being visible in the UI - not including the bundle in a category in category.xml will put it into a synthetic "Default" category So looking around at others with this problem, just including the bundle in the feature.xml seemed the way to go at the time. FWIW, in Oxygen, MPC will remove the Orbit HttpClient bundles from its feature, include them in the repository explicitly, and use some XML processing to hide them. However, that seemed overly complicated to achieve something I expect to be a common case... > We also have projects that update > dependencies at different paces. This is concerning from a security > perspective. Should we consider something more drastic like target > platform filtering when building the packages? Well, you'd have to filter (or test) the repository aggregation build actually. In this case, the offending bundles didn't make it into any of the packages as far as I can see. But as far as checks against the finished packages go, how about an integration test suite that simrel projects can contribute their own test bundles to and that runs against the finished packages? Relying solely on manual labor in the form of the great work of our package maintainers (and hopefully testers in all the participating projects) seems a bit anachronistic. I would expect a rather simple test to be that all bundles in all packages can actually start (maybe with an exception list for a few special cases). And projects could add smoke tests to check that their basic functionality works, thus detecting cross-project integration issues with otherwise unrelated release train projects automatically. Best, Carsten _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
