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
<nyssen@xxxxxxxxx>
To:
Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>,
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-bounces@xxxxxxxxxxx
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 <ed@xxxxxxxxxxxxx>:
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 <ed@xxxxxxxxxxxxx>
To: cross-project-issues-dev@xxxxxxxxxxx,
Date: 02/04/2016
01:12 AM
Subject: Re:
[cross-project-issues-dev] Ready for Mars.2 ?
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
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.nyssen@xxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|