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
<https://download.eclipse.org/releases/2019-12/201910181000/buildInfo/reporeports/reports/versionChecks.html>).
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 <http://www.kichwacoders.com>
_______________________________________________
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://www.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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
