Re: [cross-project-issues-dev] On the issue of building with thelatest Orbit repository

[Alexander Nyßen]

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 :
> 
> 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  
>> To:Cross project issues  
>> ,
>> Date:02/04/2016 04:20 PM
>> Subject:Re: [cross-project-issues-dev] On the issue of building with 
>> thelatest Orbit repository
>> Sent by: 
>> cross-project-issues-dev-boun...@eclipse.org
>>  

Re: [cross-project-issues-dev] On the issue of building with thelatest Orbit repository

[Konstantin Komissarchik]

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 
To:        Cross project issues , 
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 :

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