> 1) Ensure that none of the features contributed to simrel include any Orbit > bundles, > but only refer to them via dependencies (and ensure that proper version > constraints > are used in addition).
+1 to not using feature includes on Orbit bundles from project’s features. The actual presence of Orbit bundles in project’s repository is not particularly harmful as long as the dependencies on these bundles are expressed using version ranges. > 2) Use specific all-in-one features that include the required Orbit bundles > (and the > features deployed to simrel), but only use them to produce self-contained > local drop > files (zip). That’s one implementation approach of achieving #1. There are other options that I have outlined in another response. > 3) Do not publish all-in-one features on your local update sites either, but > rather > have your local update-sites refer to the simrel update-site via an > associate-site entry > (so Orbit dependencies get pulled in from there). It’s not a good idea to mix project release repositories and simrel update stream. The project’s release should be a fixed point in time, so it’s entirely appropriate for the repository to contain the necessary dependendencies at versions used during the release process. Using an associate-site in the manner you are proposing would mix release artifacts and a certain particular update policy in a way that would make it difficult for other update policies to exist. The problems with this are discussed in more details in other threads on this mailing list. In short, to maintain the flexibility of supporting multiple update policies, project’s release repositories should never use associate sites (referenced repositories). Only an update stream repository (such as simrel or one maintained by the project) should do this. Thanks, - Konstantin From: Alexander Nyßen Sent: Saturday, February 6, 2016 6:14 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] On the issue of building withthelatest Orbit repository What about the following policy? 1) Ensure that none of the features contributed to simrel include any Orbit bundles, but only refer to them via dependencies (and ensure that proper version constraints are used in addition). 2) Use specific all-in-one features that include the required Orbit bundles (and the features deployed to simrel), but only use them to produce self-contained local drop files (zip). 3) Do not publish all-in-one features on your local update sites either, but rather have your local update-sites refer to the simrel update-site via an associate-site entry (so Orbit dependencies get pulled in from there). With 1) we would have a single authority that controls which Orbit bundles are actually provided in a release, namely the simrel aggregator. 2) would cover your use case, Ed. 3) would ensure that newer Orbit bundles (added in a maintenance release) would also get picked up when installing from a local update-site. Cheers Alexander Am 05.02.2016 um 20:22 schrieb Ed Willink <e...@willink.me.uk>: Hi Konstantin I have no idea how a download ZIP can easily mirror something. But I presume what you really mean is that we should produce two ZIPs/categories. - A contribution ZIP/category that replicates the features contributed to SimRel. - An All-in-One ZIP/category that additionally bundles Orbit facilities avoiding the need for users to learn how to include Orbit in the available sites. Regards Ed Willink On 05/02/2016 17:33, Konstantin Komissarchik wrote: I would advise strongly against using the feature includes directive for Orbit bundles. While doing so provides a cheap way to mirror the Orbit bundle into the produced project repository, it also locks you down to using that one version of the bundle and we end up with multiple versions of various bundles in the install, often for no good reason. It’s easy enough to mirror the required Orbit bundles using a separate step at the end of the project build and be free to require the bundle via whatever version range is most appropriate. If everyone did this and simrel aggregation included the latest Orbit repository, the result of aggregation would contain fewer duplicate Orbit bundles without requiring projects to issue a new release just to move to a newer version of an Orbit bundle. Thanks, - Konstantin From: Ed Willink Sent: Thursday, February 4, 2016 11:11 PM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] On the issue of building with thelatest Orbit repository Hi David Interesting if you're right. I thought projects needed to bundle what wasn't bundled upstream. Thus OCL bundles LPG since no one else does. OCL includes ASM, Guava that someone else bundles. You suggest that OCL could stop bundling LPG since LPG would appear in the SimRel repo automatically. However OCL still needs to bundle LPG in order for the install from ZIPs to work offline. AFAIK there is no SimRel ZIP distribution. If there was, it would probably be so big that few would use it. However if there was a used-in-SimRel-Orbit ZIP distribution that could be useful and could help you enforce limited usage. Regards Ed Willink On 04/02/2016 21:35, David M Williams wrote: Off the top of my head, I think features are suppose to 'include' them, since that is the only way to have a reproducible build or install. If it was left up to "requires" then who knows what you would get. Granted, there should not be anything breaking, if you simply took a what ever was there, within some specified range, but especially with third party bundles, you never know. Some are real good at following good versioning practices, some are not. Plus, keep in mind, the "aggregated repository" is supposed to be a simple grouping of a subset of what ever is in the project repositories. We do not want a situation where if someone installs directly from "your" repository, they get one set of things, and if they install from the Sim. Release repository they get another set of things. Maintenance would be very difficult, then. To repeat, that's off the top of my head. Maybe you meant something else. From: Alexander Nyßen <nys...@itemis.de> To: Cross project issues <cross-project-issues-dev@eclipse.org>, Date: 02/04/2016 04:20 PM Subject: Re: [cross-project-issues-dev] On the issue of building with the latest Orbit repository Sent by: cross-project-issues-dev-boun...@eclipse.org Hi David, could you please clarify why exactly updates would be needed from projects because of changes to Orbit bundles? Does it result from the fact that Orbit bundles are actually re-bundled by project features? Or from the fact that requirements on them are specified too restrictive within project bundles or features? I’m not sure if this is already covered by some simrel reports, but IMHO we would be pretty safe if we ensured that 1) no Orbit bundles were actually re-bundled in project features, but only required by them, and that 2) dependencies on Orbit bundles or packages would be specified in line with the respective Orbit main releases (based on proper version ranges), because the aggregation could then pretty much control which Orbit bundles get pulled in. If we would in addition impose the same restrictions on Orbit releases as on project releases (namely that updates including breaking changes are not allowed in maintenance releases), I would assume no project should actually have to update its contribution for a maintenance release. Cheers Alexander Am 04.02.2016 um 21:43 schrieb Ed Willink <e...@willink.me.uk>: HI "commons.collections" doesn't seem that well used. No version of it is my workspaces, so QVTd, (Xtext, EGIT, UML, QVTo, OCL) cannot have a dependency on it. No re-contribution needed. Regards Ed Willink On 04/02/2016 20:19, David M Williams wrote: Ed, Thanks for bringing this "no maintenance, no new Orbit" issue to my attention. While the Planning Council does not like to "make" people do extra work they would not normally do, I believe it was the intent of one of our requirements [1] that the latest Orbit be consumed every update release -- if there has been a new Orbit "released". Most often there is not a new Orbit release, since we in Orbit do that only for significant issues. This time, it was only for the 'commons.collections' security bug, and a bad bug in Ant 1.9.4 that drove us to provide Ant 1.9.6. [2]. While I will not say you *have* to update and provide a new build, I would encourage you to, as well as anyone else who uses "commons.collections" since we don't want to "spread around" a package that has known security flaw in it. As far as I know, in most cases of installing and updating people will get the correct, fixed version of that bundle, but am not positive that is always true so I hate for it to be the available from any of our "most recent repositories" (Simultaneous Release or not) -- after all, the b3 aggegator is including it for some reason -- so someone must say they require it? But I am also not the "security policeman" that will say that bundle must be expunged from all current downloads. (If I recall, the security issue only applied to specialized cases ... but, if you were running in that case, it was a bad security bug possibly leading to a malicious person "executing arbitrary commands". I have opened bug 487285 to investigate or discuss this issue further. [3] And, I will put this on future Planning Council agendas to see if we can word that requirement [1] better so that all projects know better what is expected of them. Thanks again, [1] https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Re-use_and_share_common_third_party_code_.28partially_tested.29 [2] https://dev.eclipse.org/mhonarc/lists/orbit-dev/msg04419.html [3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=487285 From: Ed Willink <e...@willink.me.uk> To: cross-project-issues-dev@eclipse.org, Date: 02/04/2016 01:12 AM Subject: Re: [cross-project-issues-dev] Ready for Mars.2 ? Sent by: cross-project-issues-dev-boun...@eclipse.org Hi David On 03/02/2016 22:29, David M Williams wrote: - Every contribution file has changed since Mars.1. Also good. (i.e. no projects are just sleeping and forgot to update :) You might want to review your query. qvtd.b3aggrcon was last changed by me on 26 June, and by you on 14 July. We are certainly not sleeping, and did not forget to update. Just working very hard to support the functionality required for graduation to 1.0.0. And ... worst of all, IMHO, some "old" third party jars are still being used, which implies to me someone is not using the latest version of Orbit (R20151221205849). But if a project has no maintenance to contribute, I thought no rebuild/contribution was required and so of course an old Orbit would be in use. (I don't think that QVTd imposes tight bounds on Orbit contributions.) Regards Ed Willink_______________________________________________ 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 _______________________________________________ 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 _______________________________________________ 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 -- Dr. Alexander Nyßen Dipl.-Inform. Principal Engineer Telefon: +49 (0) 231 / 98 60-202 Telefax: +49 (0) 231 / 98 60-211 Mobil: +49 (0) 151 / 17396743 http://www.itemis.de alexander.nys...@itemis.de itemis AG Am Brambusch 15-24 44536 Lünen Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino [attachment "signature.asc" deleted by David M Williams/Raleigh/IBM] _______________________________________________ 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 _______________________________________________ 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 _______________________________________________ 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 -- Dr. Alexander Nyßen Dipl.-Inform. Principal Engineer Telefon: +49 (0) 231 / 98 60-202 Telefax: +49 (0) 231 / 98 60-211 Mobil: +49 (0) 151 / 17396743 http://www.itemis.de alexander.nys...@itemis.de itemis AG Am Brambusch 15-24 44536 Lünen Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino
_______________________________________________ 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
