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 <mailto:e...@willink.me.uk>
*Sent: *Thursday, February 4, 2016 11:11 PM
*To: *cross-project-issues-dev@eclipse.org
<mailto: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> <mailto:nys...@itemis.de>
To: Cross project issues <cross-project-issues-dev@eclipse.org>
<mailto: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
<mailto: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 <_...@willink.me.uk
<mailto: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> <mailto:e...@willink.me.uk>
To: cross-project-issues-dev@eclipse.org
<mailto: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
<mailto: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-...@eclipse.org
<mailto: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
<mailto: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-...@eclipse.org
<mailto: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 <http://www.itemis.de/>_
_alexander.nys...@itemis.de <mailto: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
<mailto: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
<mailto: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
