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
