Re: [cross-project-issues-dev] core.jobs dependency on Java 8
Just for your information, in today's RAP meeting we agreed to - keep RAP 3.1 in the Neon simultaneous release despite the core.databinding dependencies on Java 8 - keep the RAP 3.1 bundles Java 7 compatible - provide an alternative target platform based on Eclipse Mars for Java 7 users. With this policy, the core.jobs BREE would not be an issue for RAP anymore. Thanks to all for your feedback and cooperation. Regards, Ralf On Tue, Dec 8, 2015 at 5:23 PM, Daniel Megert <daniel_meg...@ch.ibm.com> wrote: > In our PMC call today [1] we decided to move 'org.eclipse.core.jobs' back to > JavaSE-1.7. > > [1] https://wiki.eclipse.org/Eclipse/PMC#Meeting_Minutes > > Dani > > > > From:Ralf Sternberg <rsternb...@eclipsesource.com> > To:Cross project issues <cross-project-issues-dev@eclipse.org> > Date:08.12.2015 00:21 > Subject:Re: [cross-project-issues-dev] core.jobs dependency on Java > 8 > Sent by:cross-project-issues-dev-boun...@eclipse.org > > > > > Hi John, > > thanks for your support. > >> One question for you Ralf, is whether this is the only bundle RAP requires >> that is blocking you in this way? I thought there were a number of other >> platform bundles already requiring Java 8 as well. > > Unfortunately, as Ivan reported already, there are three more > eclipse.core.databinding bundles now requiring Java 8 that I was not > aware of. All other dependencies of RAP (equinox, eclipse.core, > javax.servlet, javax.xml, icu) are still on <= 1.7. > > As Lars pointed out in bug 483803, the planned support for the new > Date and Time API would require Java 8, so the core.databinding > bundles should remain on Java 8. I'd think that the databinding > bundles are less critical for us as databinding is an optional feature > and the bundles could probably easily be replaced by their Mars > versions in a Java 7 deployment. > > Also thanks to Thomas and Konstantin for the pointers to Application > Servers and Java 8. We'll discuss again if moving to Java 8 could > already be an option for RAP 3.1. > > Regards, > Ralf > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.orTherefore g > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.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://dev.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://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] core.jobs dependency on Java 8
Hi, while we all want to use the new features in Java 8, some users of the RAP project still can't switch to Java 8 because they have to deploy on application servers that run on a (bundled) non-Java-8 VM. For example, looking at the IBM WebSphere JDK support list [1], it seems that for the server side, it's still a bit too early to require Java 8. Since one of the bundles RAP depends on (core.jobs) has recently been updated to Java 8, we find ourselves faced with the choice of either locking out those users or shipping RAP 3.1 with an older version of the platform. The latter would probably mean to abstain from the Neon simultaneous release. I wonder if there is a general consensus that the Eclipse platform (not the IDE) does not support Java 7 anymore. If this is the case, we have to live with it, however, I'd appreciate to keep at least the core Java-7-compatible for one more year. Looking at the respective change in core.jobs [2], it looks like a refactoring, not an API change that would require Java 8. Also on the Neon release plan [3], it's still marked as 1.7. Is there a chance to revert this change or are more of those going to come? Regards, Ralf [1] http://www-01.ibm.com/support/docview.wss?rs=180=swg27005002 [2] http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/bundles/org.eclipse.core.jobs?id=e0c1dc5111c5200d39f4611082b34110d735ac29 [3] https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_6.xml#appendix -- Ralf Sternberg Project Lead, Remote Application Platform (RAP) EclipseSource Tel: +49 721 66 47 33-0 Innoopract Informationssysteme GmbH Lammstraße 21, 76133 Karlsruhe, Germany General Manager: Jochen Krause Registered Office: Karlsruhe, Commercial Register Mannheim HRB 107883 ___ 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://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] core.jobs dependency on Java 8
Hi John, thanks for your support. > One question for you Ralf, is whether this is the only bundle RAP requires > that is blocking you in this way? I thought there were a number of other > platform bundles already requiring Java 8 as well. Unfortunately, as Ivan reported already, there are three more eclipse.core.databinding bundles now requiring Java 8 that I was not aware of. All other dependencies of RAP (equinox, eclipse.core, javax.servlet, javax.xml, icu) are still on <= 1.7. As Lars pointed out in bug 483803, the planned support for the new Date and Time API would require Java 8, so the core.databinding bundles should remain on Java 8. I'd think that the databinding bundles are less critical for us as databinding is an optional feature and the bundles could probably easily be replaced by their Mars versions in a Java 7 deployment. Also thanks to Thomas and Konstantin for the pointers to Application Servers and Java 8. We'll discuss again if moving to Java 8 could already be an option for RAP 3.1. Regards, Ralf ___ 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://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Automatic Bugzilla updates (Gerrit and Commit references) from Gerrit
I somehow expected this answer but I thought it was worth a try ;-) Nevermind. Ralf -- Ralf Sternberg Project Lead, Remote Application Platform (RAP) EclipseSource Tel: +49 721 66 47 33-0 Innoopract Informationssysteme GmbH Lammstraße 21, 76133 Karlsruhe, Germany General Manager: Jochen Krause Registered Office: Karlsruhe, Commercial Register Mannheim HRB 107883 On Mon, Feb 9, 2015 at 7:09 PM, Denis Roy denis@eclipse.org wrote: Clearly, my next area of focus is to write a tool that will create Bugzillas from cross-project email, extract me too replies and cc them all =) On 02/09/2015 12:09 PM, Eike Stepper wrote: Am 09.02.2015 um 17:25 schrieb Ed Willink: Hi We have a standard. EMF, which many of us seek to emulate, has been using [x] since March 2004. commit 04fe0d2e8262351927bdb3cc6b1cad88ffcdd033 Author: emerks emerks 2004-03-08 20:13:40 Committer: emerks emerks 2004-03-08 20:13:40 [54077] Changes to handle the new look CTabFolder We use the same [nnn] format in CDO and Oomph, too. Plus some additional tools such as release note generators that expect that format. I could change those tools, too, but it would be nice to be able to keep that format. Cheers /Eike http://www.esc-net.de http://thegordian.blogspot.com http://twitter.com/eikestepper Regards Ed Willink On 09/02/2015 16:08, Denis Roy wrote: The question that comes to my mind is: why not simply adopt Bug: XX as the standard? 458123 could be a bug number, a reference to a Gerrit change number, a mailing list post or anything. At some point we have to choose a format. In any case, if you feel strongly about supporting other formats, please file a bug and gather community support for it. We need to make sure additional formats are supported in Gerrit, in the Gerrit plugin and in the cGit code browser. Denis On 02/09/2015 10:52 AM, LETAVERNIER Camille wrote: Hi all, Same comments for me: it is really useful, and additional formats would be even more useful! Especially, the default format when copy/pasting from the Mylyn/Bugzilla task list looks like this: 459454: [CSS] Support position size with CSS https://bugs.eclipse.org/bugs/show_bug.cgi?id=459454 It doesn't contain the 'Bug' prefix, and is not recognized by the synchronization tool Thank you for this tool, it really helps! :) Camille -Message d'origine- De : cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] De la part de Ujhelyi Zoltán Envoyé : lundi 9 février 2015 16:33 À : Cross project issues Objet : Re: [cross-project-issues-dev] Automatic Bugzilla updates (Gerrit and Commit references) from Gerrit Hi all, first of all, thanks for this feature, it seems really useful. However, is it possible to support other reference types in addition to Bug: XX? For example all projects (GEF, EMF) I am actively following uses a different reference scheme: the bugzilla bug number is written at the start of the commit comment inside square brackets, like [xx]. We at the EMF-IncQuery and VIATRA project use this scheme as well, but we would be interested in having this feature working for us. Is it possible to either configure the scheme somewhere, or support it generally? Thank you, Zoltán -- Zoltán Ujhelyi https://www.inf.mit.bme.hu/en/members/ujhelyiz Fault Tolerant Systems Research Group Budapest University of Technology and Economics On 2015. febr. 9., at 15:36, Denis Roy denis@eclipse.org wrote: On 02/08/2015 07:17 AM, Lars Vogel wrote: AFAIK the plug-in is active by default for everybody... That is correct. If a Gerrit change contains Bug: XX it will be linked to Bugzilla automatically. Denis Best regards, Lars On Sun, Feb 8, 2015 at 11:41 AM, Eike Stepper step...@esc-net.de mailto:step...@esc-net.de wrote: Hi Lars, Thanks for the hint. The bug has so many comments - is there a short description on how to opt-in (if needed at all)? Cheers /Eike http://www.esc-net.de http://thegordian.blogspot.com http://twitter.com/eikestepper Am 08.02.2015 tel:08.02.2015 um 11:29 schrieb Lars Vogel: FYI - https://bugs.eclipse.org/bugs/__show_bug.cgi?id=434811 https://bugs.eclipse.org/bugs/show_bug.cgi?id=434811 got fixed by Denis. Gerrit now updates automatically Bugzilla with relevant changes in Gerrit. Please see the bug for details. A big thanks for Denis for this great piece of work to make the committer life easier. Best regards, Lars -- Eclipse Platform UI Co-Lead Geschäftsführer vogella GmbH Haindaalwisch 17a, 22395 Hamburg Amtsgericht Hamburg: HRB 127058 Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel USt-IdNr.: DE284122352 Fax (032) 221739404 tel:%28032%29%20221739404
Re: [cross-project-issues-dev] Gerrit down?
No, it works fine from my site. Regards, Ralf Ralf Sternberg Project Lead, Remote Application Platform (RAP) EclipseSource Tel: +49 721 66 47 33-0 Innoopract Informationssysteme GmbH Lammstraße 21, 76133 Karlsruhe, Germany General Manager: Jochen Krause Registered Office: Karlsruhe, Commercial Register Mannheim HRB 107883 On Tue, Sep 9, 2014 at 10:15 AM, Lars Vogel lars.vo...@gmail.com wrote: If I go to https://git.eclipse.org/r/ I get Gerrit loading but it never finishes. Is this the same for everyone? Best regards, Lars ___ 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://dev.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://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Luna SR schedule
Are the SR dates for Luna already settled? It seems that the wiki page [1] simply copied the dates from Kepler, and still needs to be adjusted. Ralf [1] http://wiki.eclipse.org/Luna/Simultaneous_Release_Plan#Service_Releases ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Bugzilla hanging?
I can't connect to bugzilla - connection timeout. Ralf On Tue, Jul 30, 2013 at 10:14 AM, Daniel Megert daniel_meg...@ch.ibm.comwrote: Works fine so far from Zurich this morning. Dani From:Tom Schindl tom.schi...@bestsolution.at To:cross-project-issues-dev@eclipse.org Date:30.07.2013 10:03 Subject:Re: [cross-project-issues-dev] Bugzilla hanging? Sent by:cross-project-issues-dev-boun...@eclipse.org -- for bugzilla is hanging as well. Tom On 30.07.13 09:08, Eike Stepper wrote: I didn't have any problems with Bugzilla today. Cheers /Eike http://www.esc-net.de http://thegordian.blogspot.com http://twitter.com/eikestepper Am 30.07.2013 08:47, schrieb Henrik: Bugzilla seems to be unresponsive for a while this morning (Git and Hudson seem to work). Is anybody else experiencing this? -Henrik ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Kepler's final staging repository is complete
I'm hesitating to bring it up, but ... in case a respin is done, it would be good if this build could eliminate the outdated rap.rwt bundle that was accidentally contributed by Gyrex [1]. This version of the rap.rwt bundle contains a critical bug [2] that is fixed in RAP's final RC4 contribution. This bug causes IE browsers to fire requests permanently for certain RAP applications and put the server under extreme load. Even though RAP is not affected by this duplicate (AFAIK), I would feel better if this bundle was not in the Kepler repository. I'm sorry that this bug made it even into RC3, this problem is almost invisible at development time and could not be discovered by any of our unit tests, browser tests or integration tests. Regards, Ralf [1] Bug 409457: Contributing old RAP 2.1 bundles to Kepler https://bugs.eclipse.org/bugs/show_bug.cgi?id=409457 [2] Bug 410157: [ServerPush] ServerPush requests always return immediately in IE https://bugs.eclipse.org/bugs/show_bug.cgi?id=410157 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Missing release information for some Kepler projects
I don't know about the SRs but I remember that EGit updated from 1.3 to 2.0 in Juno RC2 or RC3. For me this feels like a pretty risky change for an RC. I don't mean to point the finger at EGit, I just think we should agree that RC1 should really be a release candidate, i.e. almost the thing that is going to be released except for some minor fixes. The code should cool down after that point. At least major versions should not change anymore. Ralf ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] simrel.kepler.runaggregator is failling
The build started to fail after the RAP contribution. But I can't locate the problem as well. I've successfully validated the aggregation locally before I pushed the change. Any ideas? Regards, Ralf On Tue, May 28, 2013 at 2:57 PM, Grégoire Dupé gd...@mia-software.com wrote: Hello, I can see the following error message: Build failed! Exception was org.eclipse.core.runtime.CoreException: Not all artifacts could be mirrored, see log for details But I do not found the line explaining which update site is causing the failure. Does any body can explain me where or what to search ? Regards, Grégoire ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] simrel.kepler.runaggregator is failling
Searching the (raw) log [1] for error I found: Message content: The following errors occured when building Kepler: [exec] [exec] Artifact org.eclipse.b3.p2.impl.ArtifactKeyImpl@96044202 (classifier: osgi.bundle, id: org.eclipse.egf.application, version: 1.0.0.v20130520-1044) could not be found in the artifact repository (file:///home/data/httpd/download.eclipse.org/egf/updates/kepler/official) [exec] So it seems to be related to the EGF project. Regards, Ralf [1] https://hudson.eclipse.org/hudson/job/simrel.kepler.runaggregator/494/consoleText ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Request for comment: Provide standard update site locations
Great idea! Not only are p2 repositories not search-engine friendly, the fact that links to p2 repositories often lead to a 404 due to a missing index.html lets some users assume that there is nothing. While it's possible to create index files manually, some kind of a uniform appearance would help users to recognize a p2 repository immediately. Ideally, I think an index.html should be generated together with the metadata files that is both search-engine and human readable. Ralf ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Is hudson-slave1 down?
Same here, all our builds fail immediately with: Building remotely on Fastlane hudson.util.IOException2: remote file operation failed: /opt/users/hudsonbuild/workspace/rap-2.0-tools at hudson.remoting.Channel@237c8a9c:Fastlane at hudson.FilePath.act(FilePath.java:754) at hudson.FilePath.act(FilePath.java:740) at hudson.FilePath.mkdirs(FilePath.java:806) at hudson.model.AbstractProject.checkout(AbstractProject.java:1227) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:507) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:424) at hudson.model.Run.run(Run.java:1367) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:145) Caused by: ch.ethz.ssh2.channel.ChannelClosedException: SSH channel is closed. (Close requested by remote) at ch.ethz.ssh2.channel.ChannelManager.sendData(ChannelManager.java:405) at ch.ethz.ssh2.channel.ChannelOutputStream.write(ChannelOutputStream.java:71) at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1838) at java.io.ObjectOutputStream$BlockDataOutputStream.writeByte(ObjectOutputStream.java:1876) at java.io.ObjectOutputStream.writeFatalException(ObjectOutputStream.java:1537) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:329) at hudson.remoting.Channel.send(Channel.java:490) at hudson.remoting.Request.call(Request.java:111) at hudson.remoting.Channel.call(Channel.java:650) at hudson.FilePath.act(FilePath.java:747) ... 9 more Ralf On Wed, Jun 13, 2012 at 8:43 AM, Ed Willink e...@willink.me.uk wrote: Hi slave1 seems ok but fastlane has gone uncommunicative (https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-branch-tests/194/) Regards Ed Willink On 13/06/2012 02:46, Denis Roy wrote: I have restarted the slave agent on slave1. Let me know if this does not solve the issue. Sent from mobile device Michael Golubevgolu...@montages.com wrote: Hello, Last half a hour I am getting seemingly endless stream of builds, all failing like the one at [1] with: hudson.util.IOException2: remote file operation failed: /opt/users/hudsonbuild/workspace/tycho-gmp.gmf.tooling at hudson.remoting.Channel@18931e52:hudson-slave1 Is it just me or some known problem? [1] https://hudson.eclipse.org/hudson/job/tycho-gmp.gmf.tooling/265/console Regards -- *Michael Borlander Golubev *Eclipse Committer (GMF, UML2Tools) at Montages Think Tank, Prague, Czech Republic 1165/1 Dvorecka, 14700, Prague-4 Podoli tek: +420 602 483 463 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev - No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.2180 / Virus Database: 2433/5064 - Release Date: 06/12/12 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Is hudson-slave1 down?
Yes, it works again now. Thanks! On Wed, Jun 13, 2012 at 1:53 PM, Mike Milinkovich mike.milinkov...@eclipse.org wrote: I believe Denis got this restarted. Please let us know if you're still having problems. Mike Milinkovich mike.milinkov...@eclipse.org +1.613.220.3223 -Original Message- From: Ed Willink e...@willink.me.uk Sender: cross-project-issues-dev-boun...@eclipse.org Date: Wed, 13 Jun 2012 07:43:43 To: Cross project issuescross-project-issues-dev@eclipse.org Reply-To: Cross project issues cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Is hudson-slave1 down? Hi slave1 seems ok but fastlane has gone uncommunicative (https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-branch-tests/194/) Regards Ed Willink On 13/06/2012 02:46, Denis Roy wrote: I have restarted the slave agent on slave1. Let me know if this does not solve the issue. Sent from mobile device Michael Golubevgolu...@montages.com wrote: Hello, Last half a hour I am getting seemingly endless stream of builds, all failing like the one at [1] with: hudson.util.IOException2: remote file operation failed: /opt/users/hudsonbuild/workspace/tycho-gmp.gmf.tooling at hudson.remoting.Channel@18931e52:hudson-slave1 Is it just me or some known problem? [1] https://hudson.eclipse.org/hudson/job/tycho-gmp.gmf.tooling/265/console Regards -- *Michael Borlander Golubev *Eclipse Committer (GMF, UML2Tools) at Montages Think Tank, Prague, Czech Republic 1165/1 Dvorecka, 14700, Prague-4 Podoli tek: +420 602 483 463 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev - No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.2180 / Virus Database: 2433/5064 - Release Date: 06/12/12 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Status and Outlook for Juno!
For the duplicate org.eclipse.rap.* bundles, 1.5.0.20120612-1458 our RC4 contribution, 20120605-1606 is RC3. I guess someone depending on the rap runtime has not picked up the RC4 yet, could that be EMF? The duplicate org.eclipse.jetty.xml bundles come from the rap tools. For some reason, they contain the RC3 version of these bundles. I will re-build the rap tools and contribute them to the aggregator. But since no one depends on them, this should not affect any other project. Thanks for pointing out these problems! Ralf On Wed, Jun 13, 2012 at 3:45 PM, John Arthorne john_artho...@ca.ibm.com wrote: David Williams wrote on 06/12/2012 05:15:26 PM: I appreciate everyone keeping the build green and making progress on the sim rel reports [1], though there are a few serious issues left there. [1] http://build.eclipse.org/juno/simrel/reporeports/ I looked through these, and at this point I think most of them are not blocking the release. Just to save people some time digging through them, these are the remaining issues that I believe are important for Juno (see above report for details): 1) 10 bundles with missing about.html. Six bundles from emf.query2, four from Gemini. 2) 10 features with no license (in particular their license is the string %license). 1 from Virgo, 9 from Gemini. The most common cause of this is missing key in feature.properties file, or the feature.properties file itself is not included in the bin.includes list in the feature's build.properties file. 3) Multiple copies of bundles from eclipse.org projects. These might not be a problem if they are known or understood, but it might mean another project is including old, unreleased versions of another project's bundles. The core.commands dependency seems to be coming from Sapphire, and the remaining dependencies look like they come from RAP. org.eclipse.jetty.xml 8.1.3.v20120522 8.1.3.v20120416 org.eclipse.core.commands 3.6.1.v20120521-2332 3.6.1.v20120521-2329 org.eclipse.rap.jface 1.5.0.20120612-1458 1.5.0.20120605-1606 org.eclipse.jetty.webapp 8.1.3.v20120522 8.1.3.v20120416 org.eclipse.rap.rwt.osgi 1.5.0.20120612-1458 1.5.0.20120605-1606 org.eclipse.rap.rwt 1.5.0.20120612-1458 1.5.0.20120605-1606 John ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Recent Hudson problem accessing /tmp
Hi, Since yesterday night a number of unit tests in the the rap runtime jobs [1] fail when trying to delete files from /tmp. I've never seen such failures before and there hasn't been any change in the code, so I assume that some change in the environment may have triggered it? It's always the method File#delete() that returns false, so I can't tell whether it's because of permissions or because of the file to delete has vanished. Has any one else seen similar problems or has some idea what could have caused this? Thanks, Ralf [1] Examples: https://hudson.eclipse.org/hudson/job/rap-1.5-runtime/655/ https://hudson.eclipse.org/hudson/job/rap-2.0-runtime/4/ ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Recent Hudson problem accessing /tmp
It turned out that the problem was on our side [1], sorry for suspecting the server! We had two similar builds scheduled at the same time and both were accessing the same temp dir, one deleting the other's files - how stupid :-/ Thank you anyway, Ralf [1] 380420: Build failures on Eclipse Hudson with delete files from /tmp https://bugs.eclipse.org/bugs/show_bug.cgi?id=380420 On Wed, May 23, 2012 at 3:40 PM, Webmaster(Matt Ward) webmas...@eclipse.org wrote: The only recent change to Hudson that I am aware of is the addition of 2 extra build slots on Slave1 to help relieve the build load. -Matt. -- Eclipse WebMaster - webmas...@eclipse.org Questions? Consult the WebMaster FAQ at http://wiki.eclipse.org/index.php/Webmaster_FAQ View my status at http://wiki.eclipse.org/index.php/WebMaster ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Disk usage report for Hudson/Build
Hi, 1.1G rap-runtime I keep getting the very same result here even though I already reduced the number of builds to keep some time ago. A `du -hs /shared/jobs/rap-runtime/` gives me 682M. Can anyone explain this difference? Regards, Ralf ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
