Re: [cross-project-issues-dev] Can we please stop using composite repos?

[Ed Merks <ed.merks@xxxxxxxxx>]

Jonah,

Comments below.

On 09.12.2019 21:14, Jonah Graham wrote:

Hi folks,

At the moment, the https://download.eclipse.org/releases/2019-12/ is a composite repo with multiple children, one for each of the M and RC releases. Up until M3 the composite included M1, M2 and M3, with the RC1, the composite added RC1 and dropped M1.

I have building against https://download.eclipse.org/releases/2019-12/ to make sure everything is ready, and today against RC1 my build failed.

Might https://download.eclipse.org/staging/2019-12/ be a better option?  This way you would find problems that will happen soon as opposed to problems that have happened.

That being said, finding problems early, using a project-specific repository is generally better.

However it should (would) have failed from M2 onwards if the composite did not include multiple versions.

It would have failed sooner if you used http://download.eclipse.org/eclipse/updates/4.14-I-builds but that repository too is a composite that includes the 4 most recent IBuilds:

<?xml version='1.0' encoding='UTF-8'?>
<?compositeMetadataRepository version='1.0.0'?>
<repository name='The Eclipse Project repository' type='org.eclipse.equinox.internal.p2.metadata.repository.CompositeMetadataRepository' version='1.0.0'>
  <properties size='3'>
    <property name='p2.timestamp' value='1575579772232'/>
    <property name='p2.compressed' value='true'/>
    <property name='p2.atomic.composite.loading' value='true'/>
  </properties>
  <children size='5'>
    <child location='categories'/>
    <child location='I20191203-0600'/>
    <child location='I20191203-1800'/>
    <child location='I20191204-0600'/>
    <child location='I20191204-1800'/>
  </children>
</repository>

I've suggested in the past that I would prefer to see a "latest" repository that contains only a single child (or two to include the categories), i.e., http://download.eclipse.org/eclipse/updates/4.14-I-builds/latest because I really don't need or want my builds and my target platforms to load metadata for 4 children when generally I expect and want everything to resolve to the most recent child.

I suppose we could similarly have https://download.eclipse.org/releases/2019-12/latest but your question/point is a good one.  What actually is the value of including multiple children?

Can the composite only include the current/latest version, or can someone educate me as to the value of having multiple versions?

It's a really good question.  It just seems to be a "habit" to compose multiple children, usually with some restriction on the number of children, e.g., the most recent n children.  But personally, just to make everything faster for the client and less overhead for the download.eclipse.org server, I would prefer to use a repo with a single child with the most recent version. 

So what prompted everyone to have this habit?  For EMF I'm doing that too, but there is a "latest" for each of the build types:

https://download.eclipse.org/modeling/emf/emf/builds/index.html

So I would really wonder, who would use https://download.eclipse.org/modeling/emf/emf/builds/release/ instead of http://download.eclipse.org/modeling/emf/emf/builds/release/latest and why would they do that?

FWIW: The specific problem is the removal of org.eclipse.equinox.util bundle. Platform 4.14M1 does not have this bundle, but 2019-12 M1 does have it. Indeed someone else must have sneaked that in there, because the version in M1 went backwards (as listed in the report). 2019-M2 does not have it, but because of the composite it appeared to still be there :-( I don't need this bundle, I have a reference to it that I can probably remove. I would just like to be making this change earlier if possible.

I'm not sure exactly how well things would work with just a single child because currently it looks like this:

<?xml version='1.0' encoding='UTF-8'?>
<?compositeMetadataRepository version='1.0.0'?>
<repository name='Eclipse Repository' type='org.eclipse.equinox.internal.p2.artifact.repository.CompositeMetadataRepository' version='1.0.0'>
  <properties size='3'>
    <property name='p2.timestamp' value='1313779613118'/>
    <property name='p2.compressed' value='true'/>
    <property name='p2.atomic.composite.loading' value='true'/>
  </properties>
  <children size='4'>
    <child location='../../technology/epp/packages/2019-12/'/>
    <child location='201912061000' />
    <child location='201911291000' />
    <child location='201911081000' />
  </children>
</repository>

I.e., it also references the EPP repo (and must continue to do so) and that repo too is a composite (up until the release, at which point it becomes a simple repository).  But I'm not sure the EPP composite has a child to corresponding to the latest  M*/RC* that's been added to the train composite until two days later...  My suspicion is that this would be a problem when trying to install an EPP product during this two day period...

Thanks

Jonah

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com

_______________________________________________
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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev