Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Bad p2.timestamp in http://download.eclipse.org/releases/2019-03/compositeContent.jar

Fred,

Good to hear it's pretty much automated. :-)

I don't think "final released" repos should compose anything other than actual releases.  Yes, older repos contained multiple children because there were multiple releases per year for those but milestones and RCs shouldn't be in the final release repo... So yes, to me that's a bug (and it's not good for server performance).  Where should I report the Bug?

Regards,
Ed


On 20.03.2019 12:47, Frederic Gurr wrote:
Hi Ed,

Thanks for reporting that issue. The "nines" in the time stamp were
indeed a vi-editing mishap. It is fixed now.
In general, the compositeArtifact/compositeContent files are generated
automatically (by the promoteToReleases and makeVisible scripts). Due to
other issues, I had to resort to manual editing. :/

The RC2 (and GA) composite files contained more than one simrel repo for
a long time (I stopped checking beyond Luna). If you think this is a
bug, please open a Bugzilla issue for it.

Regards,

Fred

On 20.03.19 08:40, Ed Merks wrote:
Hi,

The file
http://download.eclipse.org/releases/2019-03/compositeContent.jar
currently contains a bad value for p2.timestamp, i.e.,
131377961311999999999 is not a long value:

<?xml version='1.0' encoding='UTF-8'?>
<?compositeMetadataRepository version='1.0.0'?>
<repository name='Eclipse Repository'
type='org.eclipse.equinox.internal.p2.metadata.repository.CompositeMetadataRepository'
version='1.0.0'>
   <properties size='3'>
     <property name='p2.timestamp' value='*131377961311999999999*'/>
     <property name='p2.compressed' value='true'/>
     <property name='p2.atomic.composite.loading' value='true'/>
   </properties>
   <children size='3'>
     <child
location='https://download.eclipse.org/technology/epp/packages/2019-03/'/>
     <child location='201903081000' />
     <child location='201903011000' />
   </children>
</repository>

This file was apparently edited yesterday.   Given previous typos in
these files, I'm a little concerned that the process for updating these
is manual and therefore error prone...

Note that the compositeArtifacts.jar has 1313779613119 as the value for
the p2.timestamp property:

<?xml version='1.0' encoding='UTF-8'?>
<?compositeArtifactRepository version='1.0.0'?>
<repository name='Eclipse Repository'
type='org.eclipse.equinox.internal.p2.artifact.repository.CompositeArtifactRepository'
version='1.0.0'>
   <properties size='3'>
     <property name='p2.timestamp' value='*1313779613119*'/>
     <property name='p2.compressed' value='true'/>
     <property name='p2.atomic.composite.loading' value='true'/>
   </properties>
   <children size='3'>
     <child
location='https://download.eclipse.org/technology/epp/packages/2019-03/'/>
     <child location='201903081000' />
     <child location='201903011000' />
   </children>
</repository>

Also note that for RC2 the corresponding file compositeContentRC2.jar
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.metadata.repository.CompositeMetadataRepository'
version='1.0.0'>
   <properties size='3'>
     <property name='p2.timestamp' value='1313779613120'/>
     <property name='p2.compressed' value='true'/>
     <property name='p2.atomic.composite.loading' value='true'/>
   </properties>
   <children size='4'>
     <child
location='https://download.eclipse.org/technology/epp/packages/2019-03/'/>
     <child location='201903201000' />
*    <child location='201903081000' />**
**    <child location='201903011000' />*
   </children>
</repository>

So hopefully the final result later today at release time only includes
*o**ne child for epp and a one child for 201903201000* and has correct
property values and isn't simply a copy of the RC2 jars.  This avoid
users updating or installer 2019-03 from needing to access child
repositories unnecessarily, making sure download.eclipse.org remains
responsive.

Regards,
Ed



_______________________________________________
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



Back to the top