Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 324870

Summary: GEF does not have an optimized p2 repository
Product: [Tools] GEF Reporter: David Williams <david_williams>
Component: RelEngAssignee: Alexander Nyßen <nyssen>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: ahunter.eclipse, irbull, nyssen, pwebster, webmaster
Version: unspecified   
Target Milestone: 3.8.0 (Juno)   
Hardware: PC   
OS: Windows 7   
Whiteboard:

Description David Williams CLA 2010-09-09 12:36:52 EDT 
This issue has come up in other bugs, such as bug 324419 and bug 322465. I'm opening this gef-specific one, in the hopes of discussing it ... and helping, if I can. To carry on the discussion from bug 324419 ... 

> As I said in Bug 322465 , our GEF build has not changed in a few years and I am
> not interested in changing for Helios SRx.


Ok, I checked and your "releases" site is a p2 repository. So you have a special step that converts the update site to a p2 repository? And you are saying you will not do that for milestones? (and that you never have?!) 

Seem's to me you'd want to, to make sure it works before you "release"? Also, I think this means you can not (and/or have not!) been providing an "optimized repository" as is required by Simultaneous release requirements. 
 
My intuition is something is broken, in that build you've been doing for years, and it is going unnoticed or unreported. Just guessing.
Comment 1 David Williams CLA 2010-09-09 12:42:17 EDT 
There is an "udpate site publisher" I suspect you've used in the past, see http://wiki.eclipse.org/Equinox/p2/Publisher

Is org.eclipse.equinox.p2.publisher.UpdateSitePublisher in any of your scripts or logs?
Comment 2 Anthony Hunter CLA 2010-09-09 13:20:28 EDT 
uggh, if releases does have a p2 repo and milestones does not, then agreed something is broken since the same tools create the two repos.
Comment 3 Anthony Hunter CLA 2010-09-09 13:26:55 EDT 
(In reply to comment #1)
> There is an "udpate site publisher" I suspect you've used in the past, see
> http://wiki.eclipse.org/Equinox/p2/Publisher
> 
> Is org.eclipse.equinox.p2.publisher.UpdateSitePublisher in any of your scripts
> or logs?

We use org.eclipse.equinox.p2.metadata.generator.EclipseGenerator 

And yes it is not working:

promo_log_gef_3.6.1.S201009081133_2010-09-08-12.44.22.txt:[  p2  ] [12:46:09] *!* Warning: metadata not created. *!*

looks like all the builds on modeling.eclipse.org have the same issue.

That would be:

emf compare
accelio
gef
gmf-notation
gmf-runtime
gmf-tolling
mdt-uml2
Comment 4 Anthony Hunter CLA 2010-09-09 13:29:00 EDT 
Should be an easy fix, will look:

./buildUpdateSiteMetadata.sh: line 97: /usr/bin/java: No such file or directory
Comment 5 David Williams CLA 2010-09-09 14:19:05 EDT 
Will you (and others) want to respin for RC3? I'm asking since might at least provide a way to get past bug 324419 ... even though I suspect there's other issues with that. 

I'd understand if not ... just asking.

But if so, perhaps a note to cross-project list would be in order? Sounds like it'd be pretty late in the day if everyone on your list had to rebuild?
Comment 6 David Williams CLA 2010-09-09 15:58:03 EDT 
(In reply to comment #4)
> Should be an easy fix, will look:
> 
> ./buildUpdateSiteMetadata.sh: line 97: /usr/bin/java: No such file or directory

BTW, did you recently move to "build2" official Hudson sever? If so, I think such references to Java or ant have to be made "symbolic" (such as ${JAVA_5_HOME} ... or something like that). [And I say "java 5" since that's what should be used for the "pack200" function ... if that's part of this script.]

HTH
Comment 7 Anthony Hunter CLA 2010-09-09 16:04:42 EDT 
(In reply to comment #5)
> Will you (and others) want to respin for RC3? I'm asking since might at least
> provide a way to get past bug 324419 ... even though I suspect there's other
> issues with that. 
> 
> I'd understand if not ... just asking.
> 
> But if so, perhaps a note to cross-project list would be in order? Sounds like
> it'd be pretty late in the day if everyone on your list had to rebuild?

I looked as far as I can and time is up, this will have to happen post RC3, I am not sure exactly how the scripts work, more debugging is needed.
Comment 8 Anthony Hunter CLA 2010-09-15 11:41:17 EDT 
Hi webmaster, I think the problem in our build scripts was caused a change to download1.eclipse.org.

There is no /usr/bin/java , we are supposed to set an environment variable for the location of the JVM.

Is there a possibility of having a /usr/bin/java again?
Comment 9 Denis Roy CLA 2010-09-15 11:50:20 EDT 
We don't have java installed on dev.eclipse.org nor on download.eclipse.org anymore.  Can this be run on build.eclipse.org now?  That's where we're running all the releng stuff.
Comment 10 Anthony Hunter CLA 2010-09-15 13:07:04 EDT 
(In reply to comment #9)
> We don't have java installed on dev.eclipse.org nor on download.eclipse.org
> anymore.  Can this be run on build.eclipse.org now?  That's where we're running
> all the releng stuff.

Yes, sounds good, we need to get moving on this activity.
Comment 11 Anthony Hunter CLA 2011-01-28 15:28:20 EST 
There are no indications that this issue is a problem in the Helios release. We can look at during Indigo.
Comment 12 Alexander Nyßen CLA 2012-01-24 17:00:17 EST 
As while putting the new build infrastructure live (see bug #363394) the old contents of the update sites has been cleaned (the releases site was re-created to be fully p2-compliant), and as promotion of update sites is now performed fully p2-compliant as well, I am resolving this one as fixed.