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 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 > To:Cross project issues > 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
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
[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&uid=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] 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 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 2004-03-08 20:13:40 >>> Committer: 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/ujh
Re: [cross-project-issues-dev] Automatic Bugzilla updates (Gerrit and Commit references) from Gerrit
Is this pattern case-sensitive?
Bug xx (without the colon) is also what you'd use to refer to
other bugs in Bugzilla. This pattern is also turned into a hyperlink
by the Gerrit web UI. Wouldn't it make sense to adopt this pattern
instead of having two different patterns around ("bug xx" for
x-references in Bugzilla, and "bug: xx" for references from Gerrit
to Bugzilla)?
Moreover, would it be a nice addition to be able to close bugs by a
statement like "Fix bug xx" just like you can do it on Github?
Cheers,
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 6:15 PM, Paul Webster
wrote:
> In Platform and Orion, we use what you get from copying the bugzilla header
> (the least effort approach :-)
>
> Bug 434811 - Gerrit plug-in to update the Bugzilla entry
>
> It works consistently with cGit, Gerrit, and (of course) bugzilla.
>
>
> On Mon, Feb 9, 2015 at 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 2004-03-08 20:13:40
>>> Committer: 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
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 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 wrote: > Works fine so far from Zurich this morning. > > Dani > > > From:Tom Schindl > 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 re-staging repository is complete
> If that was the RAP/Gyrex issue mentioned before, then it turns out you got > your wish "for free" ... thanks to the magical > (not-completely-deterministic) behavior of p2, I guess. > (But, I'd be sure to test well :) Yes, that was exactly the issue. I'm happy that it fixed itself :) I've double checked that all the RAP bundles and features are there with the correct versions. And we've tested with the staging repository again and found everything in perfect shape. Thank you, 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] 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
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] 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é 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] 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] Calendar for Kepler
I knew there was someone ;-) Thank you! On Tue, Jul 17, 2012 at 10:34 PM, David M Williams wrote: > Yes, I know who could add them. And that would be me! :) > > I like to wait till the Planning council formally approves them (which, I'd > expect at the August 1 meeting) but I could add the first milestone or two > if that'd help (since ... I'm pretty sure no one would object). > > Thanks for letting us know you find them helpful. I'll do this week. > > > > > > > From:Ralf Sternberg > To:Cross project issues , > Date:07/17/2012 11:15 AM > Subject:[cross-project-issues-dev] Calendar for Kepler > Sent by:cross-project-issues-dev-boun...@eclipse.org > > > > > Hi, > > I used to look up the exact +n build dates in the Planning Council > calendar [1]. Kepler M1 is already approaching (August 24), but the > dates [2] are not yet added to this calendar. Does someone on this > list know someone who could add them? > > Thanks, > Ralf > > > [1] > https://www.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9t...@group.calendar.google.com&ctz=Europe/Berlin&gsessionid=0awhaN8yJPjWKy-Tvt8jVA > [2] http://wiki.eclipse.org/Kepler/Simultaneous_Release_Plan#Schedule > > ___ > 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] Calendar for Kepler
Hi, I used to look up the exact +n build dates in the Planning Council calendar [1]. Kepler M1 is already approaching (August 24), but the dates [2] are not yet added to this calendar. Does someone on this list know someone who could add them? Thanks, Ralf [1] https://www.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9t...@group.calendar.google.com&ctz=Europe/Berlin&gsessionid=0awhaN8yJPjWKy-Tvt8jVA [2] http://wiki.eclipse.org/Kepler/Simultaneous_Release_Plan#Schedule ___ 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!
The old org.eclipse.rap bundles come from RTP. Holger will update the RTP contribution in about an hour. Regards, Ralf On Wed, Jun 13, 2012 at 4:30 PM, Dennis Hübner wrote: > > Am 13.06.2012 um 16:13 schrieb Ralf Sternberg: > > 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? > > We include any rap bundles or features, therefore we have any prefect match > dependencies to rap. > Just filter the latest rap version and look which project fails to validate > (b3 editor). Or grep for > Provided Capabilities org.eclipse.rap* in b3aggr files. > > Regards, > Dennis. > > > 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 > 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 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 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
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 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 > Sender: cross-project-issues-dev-boun...@eclipse.org > Date: Wed, 13 Jun 2012 07:43:43 > To: Cross project issues > Reply-To: Cross project issues > 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 Golubev 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] 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 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 Golubev 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] 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) 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
[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] Notice that the Eclipse Project 4.2 milestone repo (M6) was broken from noon to midnight, 3/19
Well, it was me who broke it and I'd like to apologize for all the trouble and extra work this has caused! I think I owe you at least an explanation how this could happen. For every milestone, I create a repository that contains a subset of the platform repository as input for the rap-runtime tycho build. I do so to work around bug 348045 [1]. These repositories are created in /shared/rt/rap/base-platforms/. To copy the artifacts from the platform, I used to create a symlink to the platform's download area, in this case /home/data/httpd/download.eclipse.org/eclipse/updates/4.2milestones/S-4.2M6-201203151300. Since some bundles are missing from the 4.2 repository (bug 355430 [2]) I have to copy them from 3.8 (icu.base.source, some servletbridge bundles). Then I create p2 metadata using a shell script. During this work, I must have mixed up the symlink to the platform and the target directory at some point and so messed up the platform repository :( I usually think twice before issuing a shell command, this time the copying seemed to had become a routine which is always dangerous. Actually, I was also not aware that my permissions are sufficient to mess up the platform. However, it was my fault, I was lacking the necessary concentration and diligence. I'm very sorry to have caused extra work for the platform guys who are currently very busy anyway. I hope that we (the RAP project) can soon get rid of all those manual steps on the build server. Tycho 0.14 provides a workaround for bug 348045, but we can't currently use it because of another problem with tycho (bug 371552). I will use EclipseCon to figure out how to fix this problem, and with bug 355430 fixed, there should be no need for these subset repositories anymore. Regards, Ralf [1] 348045: Problem with packages exported from servletbridge https://bugs.eclipse.org/bugs/show_bug.cgi?id=348045 [2] 355430: change primary builder to 4.2 https://bugs.eclipse.org/bugs/show_bug.cgi?id=355430 On Tue, Mar 20, 2012 at 05:06, David M Williams wrote: > > > I won't say who ... except to say it was not me! (this time :) ... had a > little script mishap, combined with incorrect permissions on the file > system, and the Eclipse project's 4.2 milestone repo was "broken" today > around noon. See bug 374707 [1] for details if you enjoy (or need) that > kind of stuff. > > I'm giving this "notice" here to cross-project list since, chances are, if > you used it during this time period, and it worked for you at all, then you > probably got what you were expecting, but there is a tiny chance that is > might have appeared to work fine, but be some slight difference in content > or metadata that could lead to some hard-to-track down bugs. So ... in > general, I'd say rest easy, no cause for alarm, but if you notice anything > weird, you might try rebuilding/reinstalling with the now corrected version > of Eclipse Project's M6 (and this only applies if you installed/built with > the contents between noon and midnight today, 3/19). > > Oh, and I deliberately left the timestamps to "now" to make sure it gets > re-mirrored (for the third time) since some of the "bad" versions would > have been mirrored, as well -- apologies to the mirroring system. > > Do let us know if this did impact you (or, comment in the bug [1]) so we > can better understand the implications. > > So, except for that ... Juno M6 +1 day seems to be ending with few > problems ... I'm glad everyone's "getting in" the aggregation smoothly. > > Please remember to check the "repository reports" [2] occasionally ... lots > of problems in there ... though, a few areas of improvements, too! Thanks! > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=374707 > > [2] http://build.eclipse.org/juno/simrel/reporeports/ > > > ___ > 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
Re: [cross-project-issues-dev] Indigo SR2 is Available!
> > http://download.eclipse.org/releases/indigo/ > "SR2 is planned for February 2012" - it seems that the index.html in the repository needs to be updated. Regards, 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] yesterday's server outages
Hi, I agree that it would be helpful to be informed of such infrastructure problems earlier. When you know that there are problems and they're going to be fixed, you can just rearrange your work items instead of searching for the cause of problems. Yesterday, I found out somewhere on Twitter that others are having problems too. The mail on committer's list came when the issue was already fixed. I understand that the committer mailing list does not work in case of a total outage, maybe a dedicated twitter account would make sense? Ralf On Thu, Feb 16, 2012 at 12:53, Denis Roy wrote: > On 02/16/2012 05:47 AM, Markus Knauer wrote: >> >> Up to now I don't really know what happened (I've seen some random >> snippets of information on Twitter, here a bug from some committers, there a >> message on the mailing list from other committers), but what I do know is >> that a lot of us committers wasted time on tracking down problems in *their* >> projects, problems that were in fact related to infrastructure problems. > > > Markus, I posted up on the committers mailing list, since this was a total > outage, and that list reaches many more people. > > http://dev.eclipse.org/mhonarc/lists/eclipse.org-committers/msg00879.html > > I'll post another update as soon as I have more information. > ___ > 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] IPs blacklisted?
Hi, I cannot ssh to build.eclipse.org or synchronize with the CVS from my home dsl connection (88.64.181.56) since yesterday around 3pm GMT. I first thought it was related to the server crash, but later I noticed that I can access the server from other networks. So it seems that my IP has been blacklisted. Since a co-worker had the same problem since yesterday I wonder if it's possible that some IPs have been accidently blocked related to the server crash yesterday? Anyone else having those problems? Thanks, 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] 3.8 bundles in Juno
Thanks for clarifying this. So my understanding of the versions in Juno was obviously wrong. Of course it makes sense to include only one version in the repository. Will there be an alternative aggregation repository for the 3.8 release to install compatible software from? This probably also means that we won't get Jetty 8 in Eclipse 3.8, since new features only go into the 4.x stream, right? I guess the solution will be to base RAP on 4.2 already. I'm not sure about the implications yet but we'll figure out until M4. BTW, the reason why RAP is tightly coupled to the platform is simply that we provide alternative implementations for platform APIs that run with our web widget toolkit. Regards, Ralf On Tue, Nov 8, 2011 at 18:39, David M Williams wrote: > Technically speaking, I do not think it is accurate to say "3.8 is still > part of Juno". Yes, there will be a 3.8 released at the same time as Juno, > but don't believe anyone has planned for it to be part of the common repo. > That might be technically possible ... but, might also take more work to > make sure there are not unusual interactions and problems introduced. > > That said, your desire to have a single stream that handles both is > understandable so, not sure that the solution is. I do think you (RAP) have > a special case since for reasons I've never understood (but am sure they > are valid) have a very tight coupling with the Platform versions. Given > that tight coupling, you might have to have two streams to support both > versions of the platform? > > Hopefully others will have more constructive advice ... I just wanted to > clarify that part about "3.8 being part of Juno". > > [Just read Christian's response after writing, but before hitting send ... > so, "yes, Christian's right" :) ] > > > > [image: Inactive hide details for Ralf Sternberg ---11/08/2011 11:37:38 > AM---Hi, the RAP M3 contribution causes a conflict with the Jun]Ralf > Sternberg ---11/08/2011 11:37:38 AM---Hi, the RAP M3 contribution causes a > conflict with the Juno aggregator > > From: Ralf Sternberg > To: Cross project issues , > Date: 11/08/2011 11:37 AM > Subject: [cross-project-issues-dev] 3.8 bundles in Juno > Sent by: cross-project-issues-dev-boun...@eclipse.org > -- > > > > Hi, > > the RAP M3 contribution causes a conflict with the Juno aggregator > build, which I'm not quite sure how to tackle. The problem is that we > have a feature that contains the requirements for a basic RAP target. > These bundles are taken from 3.8M3 (since RAP is still based on 3.x). > We provide this feature to make it easy for beginners to setup a > complete RAP target. This went well so far, but now 4.2 seems to > diverge from 3.8 and our 3.8 bundles clash with the 4.2 ones. I didn't > expect those problems as 3.8 is still part of Juno. > > So here are my questions: > Is it true that the aggregator build is now based on 4.2 and that 3.8 > is not part of it anymore? > If so, does this mean that we just can't include any bundles from 3.8 > in the Juno repository anymore? > > As a quick fix, I disabled the problematic feature for now. This way, > RAP itself is still part of M3, but a target must be assembled > manually. > > Regards, Ralf > > > On Tue, Nov 8, 2011 at 14:55, David Williams > <*david_willi...@us.ibm.com*> > wrote: > > The following errors occured when building Juno: > > > > Software being installed: validationSet_main 1.0.0 > > > > Only one of the following can be installed at once: > [org.eclipse.equinox.http.registry 1.1.100.v20111010-1614, > org.eclipse.equinox.http.registry 1.1.100.v20110502] > > > > Cannot satisfy dependency: > mappedRepo_download.eclipse.org_eclipse_updates_4.2milestones_S-4.2M3-201110281100 > 1.0.0 depends on: org.eclipse.sdk.feature.group > 4.1.0.v20110612-1800-7T7jA7F8Yx_b_g7iQ1Lsy1jM8NC4BSMUny-agK5mAGqK0 > > > > Cannot satisfy dependency: > mappedRepo_home_data_httpd_download.eclipse.org_rt_rap_1.5_runtime_M3-2008-1014 > 1.0.0 depends on: org.eclipse.rap.runtime.requirements.feature.group > [1.5.0,1.6.0) > > > > Cannot satisfy dependency: org.eclipse.help.feature.group > 1.3.0.v20110809-0800-7i7uFLyFFt6Zqoimz0Bbd48R depends on: > org.eclipse.equinox.http.registry [1.1.100.v20111010-1614] > > > > Cannot satisfy dependency: > org.eclipse.rap.runtime.requirements.feature.group 1.5.0.2008-1028 > depends on: org.eclipse.equinox.http.registry [1.1.100.v20110502] > > > > Cannot satisfy dependency: org.eclipse.sdk.feature.group > 4.1.0.v20110612-1800-7T7jA7F8Yx_b_g7iQ1Lsy1jM8NC4BSMUny-agK5mAGqK0 depends > on: o
[cross-project-issues-dev] 3.8 bundles in Juno
Hi, the RAP M3 contribution causes a conflict with the Juno aggregator build, which I'm not quite sure how to tackle. The problem is that we have a feature that contains the requirements for a basic RAP target. These bundles are taken from 3.8M3 (since RAP is still based on 3.x). We provide this feature to make it easy for beginners to setup a complete RAP target. This went well so far, but now 4.2 seems to diverge from 3.8 and our 3.8 bundles clash with the 4.2 ones. I didn't expect those problems as 3.8 is still part of Juno. So here are my questions: Is it true that the aggregator build is now based on 4.2 and that 3.8 is not part of it anymore? If so, does this mean that we just can't include any bundles from 3.8 in the Juno repository anymore? As a quick fix, I disabled the problematic feature for now. This way, RAP itself is still part of M3, but a target must be assembled manually. Regards, Ralf On Tue, Nov 8, 2011 at 14:55, David Williams wrote: > The following errors occured when building Juno: > > Software being installed: validationSet_main 1.0.0 > > Only one of the following can be installed at once: [org.eclipse.equinox.http.registry 1.1.100.v20111010-1614, org.eclipse.equinox.http.registry 1.1.100.v20110502] > > Cannot satisfy dependency: mappedRepo_download.eclipse.org_eclipse_updates_4.2milestones_S-4.2M3-201110281100 1.0.0 depends on: org.eclipse.sdk.feature.group 4.1.0.v20110612-1800-7T7jA7F8Yx_b_g7iQ1Lsy1jM8NC4BSMUny-agK5mAGqK0 > > Cannot satisfy dependency: mappedRepo_home_data_httpd_download.eclipse.org_rt_rap_1.5_runtime_M3-2008-1014 1.0.0 depends on: org.eclipse.rap.runtime.requirements.feature.group [1.5.0,1.6.0) > > Cannot satisfy dependency: org.eclipse.help.feature.group 1.3.0.v20110809-0800-7i7uFLyFFt6Zqoimz0Bbd48R depends on: org.eclipse.equinox.http.registry [1.1.100.v20111010-1614] > > Cannot satisfy dependency: org.eclipse.rap.runtime.requirements.feature.group 1.5.0.2008-1028 depends on: org.eclipse.equinox.http.registry [1.1.100.v20110502] > > Cannot satisfy dependency: org.eclipse.sdk.feature.group 4.1.0.v20110612-1800-7T7jA7F8Yx_b_g7iQ1Lsy1jM8NC4BSMUny-agK5mAGqK0 depends on: org.eclipse.help.feature.group [1.3.0.v20110809-0800-7i7uFLyFFt6Zqoimz0Bbd48R] > > Cannot satisfy dependency: validationSet_main 1.0.0 depends on: mappedRepo_download.eclipse.org_eclipse_updates_4.2milestones_S-4.2M3-201110281100 [1.0.0] > > Cannot satisfy dependency: validationSet_main 1.0.0 depends on: mappedRepo_home_data_httpd_download.eclipse.org_rt_rap_1.5_runtime_M3-2008-1014 [1.0.0] > > Check the log file for more information: https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/juno.runAggregator/124/console > > ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
