Community
Participate
Working Groups
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.
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?
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.
(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
Should be an easy fix, will look: ./buildUpdateSiteMetadata.sh: line 97: /usr/bin/java: No such file or directory
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?
(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
(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.
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?
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.
(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.
There are no indications that this issue is a problem in the Helios release. We can look at during Indigo.
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.
