Yes, I happen to know Dali includes specific bundles via their build packaging, but believe they do simple "require" the version range they need in their bundles' manifest. And, that EclipseLink is not intended to be included in the IDE, but instead as a runtime target. So I felt fairly comfortable all would be ok. Of course, I don't have perfect knowledge of how everyone uses it which is why I asked if there were known problems, or if it was just a matter of having multiple versions in the repo. By the release, we definitely want one version (unless there's a reason to have different ones). From one of our reports in http://build.eclipse.org/simrel/kepler/reporeports/ namely http://build.eclipse.org/simrel/kepler/reporeports/reports/nonUniqueVersions.txt You can see its not just EclipseLink and Dali that need to do a better job of this :)
> @David: maybe we should set up a rule to verify that as part of > Simultaneous Release, since these "locking because of inclusions" is > a common reason why some installations/updates fail. I'm probably missing your point, but we actually ask the opposite of features. We want those to specify exact bundles they require, because that's the only way people can have perfectly reproducible product installs (and builds that depend on features). Of course, we also recommend people minimize use of "including other features" and instead depend on bundle's prereq ranges getting something that satisfies the range. If by "set up a rule to verify ... " you mean there's some tests you could contribute to improve the quality of the repo, I'm all for it! Hope I'm close to interpreting you correctly. Thanks for the suggestions, From: Mickael Istria <mist...@redhat.com> To: cross-project-issues-dev@eclipse.org, Date: 12/21/2012 03:01 AM Subject: Re: [cross-project-issues-dev] Status and outlook for Kepler M4 +3 Sent by: cross-project-issues-dev-boun...@eclipse.org On 12/20/2012 09:53 PM, David M Williams wrote: Normally "having two versions" wouldn't hurt anything, unless you know there's some API change or something that makes them incompatible Requiring 2 different versions of a feature which contain some "singleton" bundles (ie that define some extensions or extension points) makes that the 2 projects requiring the feature don't work together. Ie if site includes Dali (which includes EclipseLink x.y.z) and EclipseLink x.y.z+1 and if EclipseLink contains a singleton bundle, it will be most likely impossible to install Dali and EclipseLink x.y.z+1 in the same Eclipse. The inclusion in feature is a really strong coupling. Version is statically chosen at build-time. This is a bad idea if you are project X to "include" a feature from project Y since you lock yourself and your users' application to the version of Y you decided to include. It's generally a workaround for not requiring users to add multiple sites. Instead, you should: * use "require" which allows some version range for feature you want to depend on, and * you could ship a copy of the feature of Y you depend on along with features for X in the repository you produce for X. With this, you remove some constraints and one can update version of your dependencies. The fact that the dependency features are provided on the site makes that installation won't require additional sites. @David: maybe we should set up a rule to verify that as part of Simultaneous Release, since these "locking because of inclusions" is a common reason why some installations/updates fail. -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
