Re: [cross-project-issues-dev] Kepler SR3 for Java 8?
+1 on not putting Java 8 patches in Kepler. I don’t have any reason to insert myself here except as a consumer, but my strong feeling is that we should take the advice of the team actually building the tool. Service Releases are just that. They are aimed at providing updates to existing features. Users rightly expect to have an increasingly stable and predictable platform from one SR to the next, not a change w/ very large scope and implications across many components. Even if it is everything that anyone has a right to expect as to release quality (as I’m sure it will be :))), it’s bound to be destabilizing. On Mar 20, 2014, at 10:31 AM, Markus Keller wrote: > I don't think the Kepler repository should get the JDT Java 8 patches. > > The Java 8 work was a huge effort, and this code has not yet received the > in-depth testing that people expect from an official service release. While > it adds an eagerly-awaited feature for some users, it also bears quite some > risk for all the others that don't need Java 8 support at this time. > > Luna is coming soon, so the waiting time is not that long. Until then, Java 8 > support should not be actively pushed into existing installs. But a common > patch for all affected Kepler projects would of course be nice. > > Markus Keller (Eclipse JDT UI) > > > > > From:"Konstantin Komissarchik" > To:"'Cross project issues'" , > "'EPP Developer Mailing List'" > Date:2014-03-20 18:13 > Subject:Re: [cross-project-issues-dev] Kepler SR3 for Java 8? > Sent by:cross-project-issues-dev-boun...@eclipse.org > > > > From the perspective of best user experience, we should update the Kepler > repository and all the packages. If we limit the changes to just Java 8 > support, the test load would not be great. > > - Konstantin > > > From: cross-project-issues-dev-boun...@eclipse.org > [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Markus > Knauer > Sent: Thursday, March 20, 2014 9:46 AM > To: Eclipse Cross Project Issues; EPP Developer Mailing List > Subject: Re: [cross-project-issues-dev] Kepler SR3 for Java 8? > > I had this thought, too, and it has been brought up in some discussions at > EclipseCon. It should be in our interest to make it as easy as possible for > our users to get the integration with Java 8. > > *If* we decide for a SR3, what would be the deliverables? An update of the > packages only? Or only some packages? An update of the common Simultaneous > Release repository? Or something else? > > Thanks, Markus > On 20 Mar 2014 09:29, "Mickael Istria" wrote: > It tend to agree with it. Java 8 is something big that we (as tool developers > in general) should encourage people to adopt. So it's IMO worth making an > exception to the release train and try to get a SR3 that supports it Java 8 > out-of-the-box. > -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat > My blog - My Tweets > > ___ > 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 M3
Hi guys, MFT will be declaring before M4, just waiting on an updated project plan that Yatta team will be working on next week. AMP is likely to drop as we haven’t made the transition to Tycho and our crazy build dependencies are too difficult to keep maintained w/ buckminster but I’ll update on that later this month if anything changes. cheers, Miles On Nov 7, 2013, at 10:12 AM, Wayne Beaton wrote: > Thanks David > > The following projects have declared that they're participating in Luna. >> actf.b3aggrcon - org.eclipse.simrel.build >> emft-egf.b3aggrcon - org.eclipse.simrel.build >> sphinx.b3aggrcon - org.eclipse.simrel.build >> stardust.b3aggrcon - org.eclipse.simrel.build > > I haven't heard from any of these projects (yet) >> amp.b3aggrcon - org.eclipse.simrel.build >> dltk.b3aggrcon - org.eclipse.simrel.build >> mft.b3aggrcon - org.eclipse.simrel.build >> pdt.b3aggrcon - org.eclipse.simrel.build >> riena.b3aggrcon - org.eclipse.simrel.build >> soa-sca.b3aggrcon - org.eclipse.simrel.build > > Project leads: If you are participating in Luna, read this [1]. > > Wayne > > [1] > http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#State_intent_early_.28M4.29 > -- > Wayne Beaton > Director of Open Source Projects, The Eclipse Foundation > Learn about Eclipse Projects > > ___ > 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] Freemarker
Personally I find that the hugely increased productivity of xtend pretty strongly outweighs the disadvantages that Ed mentions below. I don't find it that slow, but maybe that's my machine. Refactoring is pretty worthless, sorry. I think the xtend team has done a masterful job just making debugging actually work w/in JDT, with redirection to the xtend code from the built java code etc.. A common language IDE would be a major boon for all of these issues. I wouldn't try to 'migrate' my existing code to xtend. I find it very natural to use the two to their best advantages. I'm tending to use xtend for a lot of the complex kind of logic / inference that you need to do where the safe nulls, lambdas, etc.. make an enormous difference in productivity, and then leave the API implementations as shell implementations in Java. So I use it whenever I can get away w/ it -- which isn't as often as I like as in production API code we need to have a common java human readable java implementation. (So, if I was to add one thing to Ed's list it would be to make the Java output less opaque/verbose -- I have a bug on that one.) But back to Doug's initial query, the really lovely thing about Xtend vs. the earlier template engines like xpand and jet is that it is totally infrastructure free! Since you're just compiling to straight Java now, all you need is to add the xtend tooling for dev time, and include the xbase lib and guava for runtime and you're golden. And it's *really* fast. Honestly, I can't think of why anyone who is doing java templating on Eclipse platform would use anything else. On 2013-10-22, at 8:51 AM, Ed Willink wrote: > Hi Sebastian > > You asked... > > The decision to leverage JDT tooling was pragmatic but it's really slow. When > you type something you have to wait for the underlying Java to get created, > built, messages to appear and relayed. > > If anything goes wrong you have the problems that the net effect is a cascade > of JDT and Xtend idiosyncracies. > > Refactoring just doesn't work. > > Debugging is unpleasant because you get to see large numbers of synthetic > variables in the Variables View. > > Got to line can fail since some Java problems do not appear in the Xtend so > you cannot got to the relevant line to fix them. You have to manually open > the Java file, locate the context of the error and manually navigate back to > the corresponding point in Xtend. > > Personally I really dislike the syntax incompatibilities with Java although I > could live with, perhaps even like, the extra type inference. Migrating to > Xtend took much longer than I expected because of stupid things like changing > casts to "as". Subsequently I have had to reverse the same changes in order > to regain control. My current practice is to minimise my Xtend usage and > avoid as many non-Java syntaxes as possible. > > I find the flattening of getXX() as xx very dangerous since you get new > occlusion hazards with respect to function parameters. > > But ''' and guilemets are great. > > Regards > > Ed Willink > > On 22/10/2013 15:35, Sebastian Zarnekow wrote: >> Hi Ed, >> >> Just because I'm curious: >> >> >> However you may choose to follow my example of keeping all non-text >> >> functionality in Java base classes so that you only use Xtend as a >> >> template language and plain Java for all other things. >> >> Why do you find that helpful? >> >> Regards, >> Sebastian >> >> On 22.10.2013, at 16:23, Ed Willink wrote: >> >>> Hi Doug >>> >>> Xtend is many things, and so it is easy to get misled by today's hype. >>> >>> Xtend is not a Java language extension; it has many similarities but >>> significant differences too; beauty is in the eye of the beholder. >>> >>> One of Xtend's really useful features is its triple quote operator that >>> allows you to embed a text template within Java-ish code. Within the >>> templates you can use guilemets to have inner control, so overall Xtend >>> supports control within text within control; very powerful, and the >>> whitespace tooling in the editor is good too. >>> >>> For text-intensive code I can strongly recommend Xtend. However you may >>> choose to follow my example of keeping all non-text functionality in Java >>> base classes so that you only use Xtend as a template language and plain >>> Java for all other things. >>> >>> Regards >>> >>> Ed Willink >>> >>> On 22/10/2013 14:50, Doug Schaefer wrote: Xtend is a Java language extension, no? I'm talking about a template engine that we use in the new project wizard to instantiate code templates based on various user selectable options. I was originally thinking of Jet, but I can't seem to find it anymore. Whatever happened to it? Doug. From: Henrik Rentz-Reichert Reply-To: Cross project issues Date: Tuesday, 22 October, 2013 2:43 AM To: Cross project issues >>
Re: [cross-project-issues-dev] Freemarker
Um, _Eclipse_ xtend? ;D http://www.eclipse.org/xtend/documentation.html#templates On 2013-10-21, at 12:47 PM, Doug Schaefer wrote: > Has anyone tried to get Freemarker into Orbit? Or is there a better template > engine that people are using. CDT has it's own but I'd like to use something > more standard (and better). > > Thanks, > Doug. > > ___ > 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] Making your project more openŠhowto enable Gerrit
On 2013-10-07, at 7:03 AM, Thanh Ha wrote: > > I've been meaning to write something up about this but haven't had the time. > If you use the commandline there's a handy python script [1] that makes the > Gerrit experience a little easier. > > The gist of it is that it's a bunch of shortcuts to working with the Gerrit > workflow. For example "git review -d " will pull down a change and > create a local branch for it automatically. No more copy/pasting the long > commands that Gerrit provides. > > Maybe something similar can be integrated into Egit? Yeah, um, there is some tooling for that. It's called Mylyn Reviews. ;D 1. Open the Review editor for that change. 2. Scroll down to the last patch set. 3. Click "Fetch". Glad to see so much discussion around this! I think the most important point was made by a couple of people -- it doesn't really hurt to at least enable it. There is a really important network effect here for contributors that I'd like to point out. People talk about there being a lot to learn to get up to speed on Gerrit -- that's true to some extent, but it's a one time cost and the EGit and Reviews tooling helps. The point is that once you know how to make and accept contributions to one project, it's the exact same process for every other project. As more and more projects move to Gerrit, this will become the expected way to contribute. I personally would be *much* more likely to contribute to a project that had Gerrit enabled -- and that was actually the impetus for my post…wanting to contribute something to a project that hadn't yet been enabled. (And no, I won't name names.. ;)) > On Fri, Oct 4, 2013 at 12:00 PM, Ian Bull wrote: >> I really like the flow that Gerrit provides. Pushing commits is easier than >> creating patchs and uploading them. However, I find with Gerrit (or our use >> of Gerrit) is that the discussion is now spread across multiple mediums. >> Bugs / feature requests come in on bugzilla where some discussion happens. A >> change-set then appears are Gerrit where more discussion happens. Further >> requirements / ideas appear back on the bug and suddenly the change is >> updated. I find it difficult to follow the discussion. With bugzilla (or our >> use of it), all discussions (from conception, to requirements, to design, to >> implementation, to delivery) happen in one continuos thread. >> >> I'm not sure how the more experienced Gerrit users deal with this. > > Gerrit developers try to do most discussion on the change itself, and > avoid using the mailing list or the bug tracker to discuss something. > But we have a similar opinion that the fractured discussion is not > useful. Right. For me, it's really the worst aspect of Gerrit. I find myself struggling to remember whether a discussion happened on a bug or on a review. It makes it even more interesting, because there isn't a one-to-one mapping between reviews and bugs as many people assume. There may even be cross-cutting concerns, so while there is a primary bug, we really need to be able to support more complex references. In general we need much better traciblity between defects and reviews -- that's something we're really interested in as an active dev topic. > It might be interesting to think about having some sort of plugin in > Gerrit that can grab comments from the related bug and include them > interleaved by timestamp with Gerrit events, so the entire discussion > is visible in one place on the Gerrit web UI. > ___ Yes, this is something that would be really interesting to take a look at for Mylyn Reviews dashboard UI! (cc'ing Mylyn Reviews list for any follow-up on that, please exclude x-platform from any related follow-up.) Miles T. Parker | Tasktop Labs | Tasktop Technologies web: http://tasktop.com | blog: http://milesparker.blogspot.com Committer: Eclipse Mylyn Reviews, R4E, Virgo Lead: Eclipse Mylyn MFT, AMP Are you passionate about innovation and excellence and interested in joining our team? Tasktop, voted one of the Best Companies to Work for in British Columbia, is hiring! ___ 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] Making your project more open…howto enable Gerrit
Project leads: I just tweeted about my disappointment in how many projects have not yet enabled Gerrit. Chris A. pointed out that it wouldn't be a bad thing to send a reminder to x-platform . All joking aside[http://milesparker.blogspot.ca/2013/01/adopting-gerrit.html] it really isn't hard, just click here!! https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Gerrit&short_desc=Enable%20Gerrit%20for%20my%20project cheers, Miles Miles T. Parker | Tasktop Labs | Tasktop Technologies email: miles.par...@tasktop.com web: http://tasktop.com | blog: http://milesparker.blogspot.com Committer: Eclipse Mylyn Reviews, R4E, Virgo Lead: Eclipse Mylyn MFT, AMP Are you passionate about innovation and excellence and interested in joining our team? Tasktop, voted one of the Best Companies to Work for in British Columbia, is hiring! ___ 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] Gerrit CI triggers…?
This is interesting…the jobs *are* getting executed, it's just that the notification back to gerrit doesn't appear to be happening. https://bugs.eclipse.org/bugs/show_bug.cgi?id=415188 Gerrit jobs not notified of hudson build status On 2013-08-15, at 1:32 PM, Matthias Sohn wrote: > On Thu, Aug 15, 2013 at 7:54 PM, Miles Parker > wrote: > Is anyone else noticing Gerrit build triggers not getting invoked? Looking at > https://git.eclipse.org/r/#/q/age:1day,n,z it appears that there are many > recent changes missing builds.. > > sandbox Hudson says: > > Your Hudson data directory "/opt/users/hudsonbuild/.hudson" (AKA HUDSON_HOME) > is almost full. You should act on it before it gets completely full. > > so projects using sandbox Hudson should check if they can free some space. > Otherwise webmaster could allocate more diskspace to this system. > > -- > Matthias > ___ > 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] Gerrit CI triggers…?
Is anyone else noticing Gerrit build triggers not getting invoked? Looking at https://git.eclipse.org/r/#/q/age:1day,n,z it appears that there are many recent changes missing builds.. Miles T. Parker | Tasktop Labs | Tasktop Technologies email: miles.par...@tasktop.com web: http://tasktop.com | blog: http://milesparker.blogspot.com Committer: Eclipse Mylyn Reviews, R4E, Virgo Lead: Eclipse Mylyn MFT, AMP Are you passionate about innovation and excellence and interested in joining our team? Tasktop, voted one of the Best Companies to Work for in British Columbia, is hiring! ___ 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
Yeah, I was just thinking … "hmmm.. maybe we could squeeze a couple more Reviews fixes in there as well… bwahahahaha!" -Miles On 2013-06-13, at 11:35 AM, Fred Bricon wrote: > I know it's benign, that's why I didn't request a respin in the first place. > Now it doesn't hurt to ask :-) > > > 2013/6/13 Pascal Rapicault > And so started the respin where everything changed… > > > > Fred, this is far from being a blocker change, so even though this is a > benign change, I don’t know if we want to consume it. > > > > From: cross-project-issues-dev-boun...@eclipse.org > [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Fred Bricon > Sent: June-13-13 2:16 PM > To: Cross project issues > > > Subject: Re: [cross-project-issues-dev] Kepler's final staging repository is > complete > > > > +1 for a respin. That'd -hopefully- allow the build to pick up a now conform > (epl-v10.html/signed) mavenarchiver feature for m2e-wtp. > https://bugs.eclipse.org/bugs/show_bug.cgi?id=410670 > > > > Fred Bricon > > > > 2013/6/13 Eike Stepper > > Am 13.06.2013 20:01, schrieb Ed Willink: > > > > Hi > > CDO is too important a project to not fix this, so I vote for the (partial) > respin. > > > > Thanks! > > > > Maybe next year we can have a bit more reviewing, approving and testing. > > > > I invite you to work on CDO internals and become a committer, so that you can > review us next year :P > > > > Cheers > /Eike > > > http://www.esc-net.de > http://thegordian.blogspot.com > http://twitter.com/eikestepper > > > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > > > > > -- > "Have you tried turning it off and on again" - The IT Crowd > > > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > > > -- > "Have you tried turning it off and on again" - The IT Crowd > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev __ Miles T. Parker, M.Sc. Tasktop Labs http://tasktop.com Lead: Eclipse Mylyn MFT, AMP Committer: Eclipse Mylyn Reviews, R4E, Virgo http://milesparker.blogspot.com ___ 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 M2 staging repository complete
Cool. I just did exactly that. (84463c295407d49d079ad624cc8db7e96c3656ff) On 2012-10-03, at 3:30 PM, David M Williams wrote: > Ok, thanks. A convention we settled on (in the thousands of notes to this > list) is that you can still enable your _contribution_ element and then set > enabled=false on your repository or features. That way, it's clear you intend > to participate ... and (eventually) I can start sending notes about disabled > repositories and features :) > > Thanks again, > > > > > From:Miles Parker > To:Cross project issues , > Date:10/03/2012 06:14 PM > Subject:Re: [cross-project-issues-dev] Kepler M2 staging repository > complete > Sent by:cross-project-issues-dev-boun...@eclipse.org > > > > > David, there are some feature dependency issues for help support for AMP so > I'm having to leave it disabled until I can fix that. > > On 2012-10-03, at 2:13 PM, David M Williams wrote: > > > I've been so busy these past few days, I've not even had time to send any > > nag notes! > > > > But here we are, Kepler M2 +3 day at 5 PM. > > > > I have just now promoted what I am assuming is the final M2 staging repo > > (unless some speaks up in next hour or two). > > > > Thanks to those two additional projects for enabling their contributions -- > > we might even get some EPP packages this time! > > > > Only 7 to go (to enable, or drop out?) > > > > amp.b3aggrcon - org.eclipse.simrel.build > > emf-query2.b3aggrcon - org.eclipse.simrel.build > > gyrex.b3aggrcon - org.eclipse.simrel.build > > jwt.b3aggrcon - org.eclipse.simrel.build > > mylyn-docs-intent.b3aggrcon - org.eclipse.simrel.build > > soa-bpel.b3aggrcon - org.eclipse.simrel.build > > soa-sca.b3aggrcon - org.eclipse.simrel.build > > > > ___ > > 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 M2 staging repository complete
David, there are some feature dependency issues for help support for AMP so I'm having to leave it disabled until I can fix that. On 2012-10-03, at 2:13 PM, David M Williams wrote: > I've been so busy these past few days, I've not even had time to send any nag > notes! > > But here we are, Kepler M2 +3 day at 5 PM. > > I have just now promoted what I am assuming is the final M2 staging repo > (unless some speaks up in next hour or two). > > Thanks to those two additional projects for enabling their contributions -- > we might even get some EPP packages this time! > > Only 7 to go (to enable, or drop out?) > > amp.b3aggrcon - org.eclipse.simrel.build > emf-query2.b3aggrcon - org.eclipse.simrel.build > gyrex.b3aggrcon - org.eclipse.simrel.build > jwt.b3aggrcon - org.eclipse.simrel.build > mylyn-docs-intent.b3aggrcon - org.eclipse.simrel.build > soa-bpel.b3aggrcon - org.eclipse.simrel.build > soa-sca.b3aggrcon - org.eclipse.simrel.build > > ___ > 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] Managing Gerrit Reviews across Git Repos
[cross posting to Reviews and cross-project list] We've got an interesting issue with reviews that span git repositories. In this case we are likely to have many reviews such as this that involve very large refactorings that only make sense and work as a whole, and the last thing we want is a workflow that puts us into git/gerrit merge hell. Given the issues involved, it almost seems like it would be easier to merge the repos.. ;P I'm wondering if any other projects have run into this issue and whether people have ideas for a relatively manageable way to handle this? On 2012-09-18, at 6:38 PM, Steffen Pingel wrote: > In terms of automated validation of changes, I don't see a straight forward > way to make that work. We will need to rely on merging framework changes > first and then retrigger validation for R4E to consume those changes. Gerrit > does have a notion of topics for related changes but I am not sure that the > Eclipse.org Gerrit already has that support and how you could integrate it > with the Gerrit trigger job. > > Steffen > > > On Tue, Sep 18, 2012 at 5:54 PM, Miles Parker > wrote: > > An additional bit of real awkwardness I just discovered that hadn't occurred > to me until I just went to commit a proposed change to the Reviews model(s): > > Many of the refactorings will span both repos. In fact, all of the really > interesting one's probably will! How the heck will be manage that with > Gerrit, given that we will have to have two separate reviews for each change > and there isn't anyway to synchronize them?! ___ 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] Hudson Buckminster issues..
Has anyone been seeing buckminster issues recently? Has there been a big change that I've missed in buckminster support? :O I'm getting the following error with any of the buckminster installations I've tried: ERROR: java.lang.NoSuchMethodException: Unknown property 'buckminsters' on class 'class hudson.plugins.buckminster.install.BuckminsterInstallable$BuckminsterInstallableList' ___ 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] Buckminster Greediness .. Re: Bundles Re: Layout and licenses
Hmm… I assumed that Buckminster would not be greedy. This reply seems to imply that it *will* be, but perhaps wasn't. http://dev.eclipse.org/mhonarc/lists/buckminster-dev/msg01320.html Looking at the report, I have some that are there because they're defined via xtext settings, as well as the agf3d stuff that pulls in the gef3d. *But* that agf3d stuff shouldn't be in there in the first place. http://build.eclipse.org/juno/simrel/reporeports/reports/greedyReport.html So I'm going to switch from Buckminster 3.6 to 4.2 and see if that takes care of issue by itself. On 2012-06-06, at 10:11 AM, David M Williams wrote: > > My understanding was the the aggregator pulled the feature -- and only the > > feature -- dependencies it needed from the aggregated site(s). Is that not > > correct? > > That is pretty much the case ... but ... it can get complicated. Do you have > any optional dependencies on it and do you publish without "greedy=false" > attribute? If so, you are "getting what you ask for" :) > > If that's not the case (no optional dependencies and/or use greedy="false") > then ... not sure. Might be someone else has an optional (greedy) dependency > on it (and, yes, it can then still find it in your repo). > > > > > From:Miles Parker > To:Cross project issues , > Date:06/06/2012 12:55 PM > Subject:[cross-project-issues-dev] Bundles Re: Layout and licenses > Sent by:cross-project-issues-dev-boun...@eclipse.org > > > > > AMP must be the cause for GEF3D, but I'm not sure why that is happening. AMP > as a stand-alone project includes GEF3D, but we created a non-GEF3D feature > for Indigo/Juno specifically because GEF3D isn't on release train and because > GEF3Ds 3D lib dependencies all live in IP hell. The feature we point to is > the "GEF3Dless" feature. So while GEF3D is in our repos, it should *not* be > in Juno repos. My understanding was the the aggregator pulled the feature -- > and only the feature -- dependencies it needed from the aggregated site(s). > Is that not correct? > > > > On 2012-06-06, at 6:16 AM, Wayne Beaton wrote: > > Hey folks. I'm going through the layout and licenses reports today. > > I've already opened a couple of bugs regarding missing about files and am > just starting into the licenses. These issues need to be addressed before any > reviews can be declared successful. Note that these are very basic > requirements that are independent of participation in the simultaneous > release. If you need help, please ask. > > There a Gemini JPA bundle in the repository. I'm also seeing a GEF3D bundle. > Why? If these bundles are in the repository, shouldn't the owning projects be > Juno particpants? Or did I miss a memo? > > org.eclipse.gemini.jpa_1.0.99.v20120225-1927.jar > org.eclipse.gef3d_0.8.1.v20120528-0244.jar > > Who owns these bundles: > > org.eclipse.rephraserengine.core_8.0.0.201205300709.jar > org.eclipse.rephraserengine.ui_8.0.0.201205300709.jar > > (I'll guess tools.ptp.photran based on the version number). > > Wayne > -- > Wayne Beaton > The Eclipse Foundation > Twitter: @waynebeaton > Explore Eclipse Projects > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > __ > Miles T. Parker > Senior Solutions Architect > Tasktop > http://tasktop.com > Committer, Eclipse Mylyn and Virgo > Project Lead, Model Focussing Tools and AMP > http://milesparker.blogspot.com > > ___ > 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 __ Miles T. Parker Senior Solutions Architect Tasktop http://tasktop.com Committer, Eclipse Mylyn and Virgo Project Lead, Model Focussing Tools and AMP http://milesparker.blogspot.com skype: milestravisparker ___ 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] Bundles Re: Layout and licenses
AMP must be the cause for GEF3D, but I'm not sure why that is happening. AMP as a stand-alone project includes GEF3D, but we created a non-GEF3D feature for Indigo/Juno specifically because GEF3D isn't on release train and because GEF3Ds 3D lib dependencies all live in IP hell. The feature we point to is the "GEF3Dless" feature. So while GEF3D is in our repos, it should *not* be in Juno repos. My understanding was the the aggregator pulled the feature -- and only the feature -- dependencies it needed from the aggregated site(s). Is that not correct? On 2012-06-06, at 6:16 AM, Wayne Beaton wrote: > Hey folks. I'm going through the layout and licenses reports today. > > I've already opened a couple of bugs regarding missing about files and am > just starting into the licenses. These issues need to be addressed before any > reviews can be declared successful. Note that these are very basic > requirements that are independent of participation in the simultaneous > release. If you need help, please ask. > > There a Gemini JPA bundle in the repository. I'm also seeing a GEF3D bundle. > Why? If these bundles are in the repository, shouldn't the owning projects be > Juno particpants? Or did I miss a memo? > > org.eclipse.gemini.jpa_1.0.99.v20120225-1927.jar > org.eclipse.gef3d_0.8.1.v20120528-0244.jar > > Who owns these bundles: > > org.eclipse.rephraserengine.core_8.0.0.201205300709.jar > org.eclipse.rephraserengine.ui_8.0.0.201205300709.jar > > (I'll guess tools.ptp.photran based on the version number). > > Wayne > -- > Wayne Beaton > The Eclipse Foundation > Twitter: @waynebeaton > Explore Eclipse Projects > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev __ Miles T. Parker Senior Solutions Architect Tasktop http://tasktop.com Committer, Eclipse Mylyn and Virgo Project Lead, Model Focussing Tools and AMP http://milesparker.blogspot.com ___ 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] The PermGen problem
Ed, Perhaps it's time to revisit the default settings with a new enhancement request? Here's mine from a couple of years ago -- after much discussion the community arrived at the solution to up the Mac 64 bit settings but not other ones, don't know if this has changed subsequently.. https://bugs.eclipse.org/bugs/show_bug.cgi?id=265525 cheers, Miles On 2012-05-29, at 12:47 PM, Ed Willink wrote: > Hi > > RC2: Just suffered from launching a nested Eclipse with an inadequate PermGen > and the usual UI lockouts and need to kill Eclipse. > > Why are we still shipping a product that is increasingly unuseable out of the > box as applications get more demanding? > > It irritates me and I know what I'm doing. It's clear from newsgroups that > users have trouble too. It's just not user friendly. > > Regards > > Ed Willink > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev __ Miles T. Parker Senior Solutions Architect Tasktop http://tasktop.com Committer, Eclipse Mylyn and Virgo Project Lead, Model Focussing Tools and AMP http://milesparker.blogspot.com ___ 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] Target audience of Juno repo
+1, but probably way too late to be asking people to make these kind of changes now. Something that people should be thinking hard about for Kepler. There is a major need for a higher level of granularity on the features. Ideally it would be one per project but that isn't practical in many cases. On 2012-05-29, at 8:29 AM, Pascal Rapicault wrote: > Once in a while I go through the content of the Juno repo to see what's > there; and I try to see if I can make any sense of what is made available. > Unfortunately this year it reached a point where I just can't. There are way > too many entries that are subtle variations around the same project and whose > installation result in unexpected results or non functional additions to my > install. For example there is 11 entries for Sapphire, 5 entries for > windowBuilder, an infinity of Mylyn related entries...? > > I understand that we are all trying to promote our project and brand, but I > would argue that the plethora of entries has a reverse effect that let the > user confused as to what to install. > > So the main question is "what is the primary target audience of the Juno > repo?" > - an eclipse user - e.g. a JEE programmer > - an eclipse extender - e.g. someone using eclipse technologies to > build an app > > At this point, the content of the repo looks like what we are addressing both > audience which may be a convenience for us but a nuisance for the end users. > > IMO, the Juno repo should be "end user" focused and only include entries > whose installation will result in new functionalities to be added to the IDE. > Also each entry should have > - a descriptive name (which include removing adjectives such as > incubation, extender) > - a minimal number of entries returned when I search for the name > - be adequately categorized > > How do we go about exposing the rest of the content for extenders? > - Different repo URLs (e.g. > download.eclipse.org/releases/juno/developer) > - Addition of a developer focused category (with nested categories) > > wdyt? > > Pascal > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev __ Miles T. Parker Senior Solutions Architect Tasktop http://tasktop.com Committer, Eclipse Mylyn and Virgo Project Lead, Model Focussing Tools and AMP http://milesparker.blogspot.com skype: milestravisparker ___ 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] Juno RC1 staging repository is complete
OK David, I've got the signed build in place, have updated the b3 aggr and just kicked off a the aggregator build. Wish me luck! And yes, your note is perfectly constructive. In my new role at Tasktop my open source work is focussed on other projects such as MFT and Virgo and AMP has had to take a backseat... re: AMP, "Quiescent" is a fair description. Perhaps "esoteric" is a better description in that modelling of real-world systems hasn't had the lift-off that my colleagues and I have been hoping for over oh the last ten years or so. *I* think the work is important but it hasn't been paying the bills. At the same time it is quite mature, with no blocking bugs (really 1.0.0 quality) and after all the effort that I put into getting it ready for Indigo, it seemed a shame to just drop off for no other reason than a few failed dependencies. Unfortunately, AMP has dependencies on a very wide array of Eclipse technologies, so it gets broken easily. When I saw that BIRT and others had made some changes to the dependencies that broke, that enabled me to move forward (thanks guys) -- w.o those I *would* have dropped out. cheers, Miles On 2012-05-23, at 8:09 PM, David M Williams wrote: > > Still here, still sorting out dependency issues in my "spare" time. > > (This time w/ GEF3D.) AMP hasn't changed at all since Indigo, but > > everything else has. :) If I don't get them squashed by the end of > > this weekend I will formally withdraw it from Juno. > > Ok, so, to be explicit, (I checked after your quick response, which I > appreciate) I guess you were in the first three or four milestones before > aggregation broke and I disabled your file. You were not in M6, not in M7, > and now not in RC1. You haven't changed since Indigo, though obviously your > dependencies have. And, you, and your PMC, still feel confident you can get > all this worked out and well tested "in a few days"? Doesn't sound in the > spirit of the Simultaneous Release, to me ... but, admit I'm not that > familiar with Amp. But ... to miss such significant checkpoints sounds like > you may want to adopt the "release when you are ready model" and not worry > about expending the extra effort that is needed (by us all) to "stay > simultaneous". [And, as an aside, "no changes since Indigo", sounds like not > even bug fixes ... so you have either some incredibly solid and stable code > ... or ... well, "stagnate" is too strong a word, but maybe a quiescent > project?] > > Just a suggestion ... there's no shame in not being part of Simultaneous > Release if it doesn't fit your needs and resources ... but you are welcome to > be in Juno if you do feel confident you have the time to contribute to a high > quality Juno Release, or you can "rejoin" in Juno SR1, if that better fits > your schedule and business needs. > > I hope my note comes across as constructive as intended and not judgmental, > as I'm the first to admit there are all kinds of projects at Eclipse and in > the Simultaneous Release and its really up to the committers and adopters to > know what's needed and what they want. > > Thanks again for keeping us informed and contributing to Eclipse. Good luck, > > > > > Miles Parker ---05/23/2012 10:00:01 PM---Still here, still > sorting out dependency issues in my "spare" time. (This time w/ GEF3D.) AMP > hasn't > > From: Miles Parker > To: Cross project issues , > Date: 05/23/2012 10:00 PM > Subject: Re: [cross-project-issues-dev] Juno RC1 staging repository is > complete > Sent by: cross-project-issues-dev-boun...@eclipse.org > > > > > Still here, still sorting out dependency issues in my "spare" time. (This > time w/ GEF3D.) AMP hasn't changed at all since Indigo, but everything else > has. :) If I don't get them squashed by the end of this weekend I will > formally withdraw it from Juno. > > On 2012-05-23, at 6:51 PM, David M Williams wrote: > > Thanks to all the last minute fixes and getting a clean build. I've disabled > the aggregation build and assume we are ready for RC1, unless someone comes > up with a blocking problem that justifies a respin. > > My main concern is that there are still two projects still disabled: > > amp.b3aggrcon > riena.b3aggrcon > > Riena I'm not worried about, I know they sort of "come and go" as are > sensitive to exact platform version, so assuming this was an oversight or > busy week for the Riena team and they are basically ok and will be back in > for RC2. > > Amp, on the other hand, h
Re: [cross-project-issues-dev] Juno RC1 staging repository is complete
Still here, still sorting out dependency issues in my "spare" time. (This time w/ GEF3D.) AMP hasn't changed at all since Indigo, but everything else has. :) If I don't get them squashed by the end of this weekend I will formally withdraw it from Juno. On 2012-05-23, at 6:51 PM, David M Williams wrote: > Thanks to all the last minute fixes and getting a clean build. I've disabled > the aggregation build and assume we are ready for RC1, unless someone comes > up with a blocking problem that justifies a respin. > > My main concern is that there are still two projects still disabled: > > amp.b3aggrcon > riena.b3aggrcon > > Riena I'm not worried about, I know they sort of "come and go" as are > sensitive to exact platform version, so assuming this was an oversight or > busy week for the Riena team and they are basically ok and will be back in > for RC2. > > Amp, on the other hand, has been disabled for nearly all of Juno, and its > update site in the b3aggrcon file still points to a software repository named > "indigo_b3" which sounds old. > > I think maybe Amp has "dropped out" of Juno, and I have just missed that. The > contact listed in file is Mile Parker. If I don't here from him soon, here on > this list, or hear from the Modeling PMC, I'll assume they've withdrawn and > remove the contribution file before RC2. > > Thanks all, > > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev __ Miles T. Parker Senior Engineer and Product Manager, Tasktop http://tasktop.com Committer, Eclipse Mylyn and Virgo Project Lead, Model Focussing Tools and AMP http://milesparker.blogspot.com skype: milestravisparker ___ 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] M2M ATL Re: Status and outlook for M7
Hi William, It's working now on my end as well. Perhaps I just hit it as it was being updated or something. cheers, Miles On 2012-05-10, at 12:41 AM, William Piers wrote: > Hi Miles, > > I checked the ATL update site and all seems ok to me, both > http://download.eclipse.org/modeling/m2m/atl/updates/milestones/3.3/ and > http://download.eclipse.org/releases/staging/ shows ATL M7 build and its > installation works. > > William > > Le 10/05/2012 02:56, Miles Parker a écrit : >> >> >> Hi, >> >> FWIW, I couldn't get the M2M ATL entry >> (http://download.eclipse.org/modeling/m2m/atl/updates/milestones/3.3/) and >> it broke, reporting missing repos. Reverting wpiers' change so that it uses >> 3.2 instead works, but I'm sure that's not what's intended. Don't know >> what's going on here or if this is showing up in actual build but I thought >> I'd mention it. >> >> (And yes, my ssh does work, thanks Denis. Now I'm waiting on build to >> complete and may need further tweaks. David, please do not wait on me, but >> I'll re-enable and commit IIF I can get a clean local validation here.) >> >> -Miles >> >> On 2012-05-09, at 9:18 AM, Borislav Kapukaranov wrote: >> >>> Hey David, >>> >>> I just successfully validated the virgo.b3aggrcon and enabled it. We don't >>> have new content for this milestone but I updated the references to Equinox. >>> >>> Best Regards >>> Bobby >>> >>> On Wed, May 9, 2012 at 7:13 PM, Doug Schaefer wrote: >>> CDT is scrambling to fix some major issues. We may ask for more time. >>> Hopefully not. >>> >>> Thanks, >>> Doug >>> >>> From: David M Williams >>> Reply-To: Cross project issues >>> Date: Wednesday, 9 May, 2012 12:11 PM >>> >>> To: Cross project issues >>> Subject: Re: [cross-project-issues-dev] Status and outlook for M7 >>> >>> Reminder ... it is +3 day! 5 PM this evening (Eastern) will be "cut-off" >>> unless someone asks for a few extra hours. >>> >>> I removed the emf compare feature from modeling category, since it was >>> cause build to fail. If there is some other one that's supposed to be >>> there, please add it back. >>> >>> The following still have disabled repositories or features: >>> >>> amp.b3aggrcon >>> equinox.b3aggrcon >>> jetty.b3aggrcon >>> mft.b3aggrcon >>> riena.b3aggrcon >>> virgo.b3aggrcon >>> >>> Any word? >>> >>> I can speak to the equinox one. See bug 378735[1]. It is related to the >>> org.eclipse.rcp.sdk.id "product". I _think_ I can add it back for RC1. But >>> is anyone using it? Can anyone document a use case? It has not been >>> working/available for all of Juno, so far, and no one has really >>> complained, and no one seems to have a clear id of if or why its needed. >>> So, I know it'd be short notice to remove it ... but ... would also >>> appreciate someone clearly saying why its needed. >>> >>> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=378735 >>> >>> >>> David M Williams---05/09/2012 10:45:14 AM---Thanks for >>> replying. But, I'm a little confused, as the be current aggregation builds >>> are failing ou >>> >>> From: David M Williams/Raleigh/IBM@IBMUS >>> To: laurent.gou...@obeo.fr, Cross project issues >>> , >>> Date: 05/09/2012 10:45 AM >>> Subject: Re: [cross-project-issues-dev] Status and outlook for M7 >>> Sent by: cross-project-issues-dev-boun...@eclipse.org >>> >>> >>> >>> Thanks for replying. But, I'm a little confused, as the be current >>> aggregation builds are failing out-of-the-gate saying there is a problem >>> with the model, at the emf.compare in the "modeling category" does not >>> refer to the right one. And, apparently comes from several sources? (at >>> least in past?) so ... is there supposed to be _any_ emf.compare in Juno? >>> Or is it completely gone? If the later, I'll just remove it from the >>> category. If the the former ... I'll have to hunt around for which is "the >>> right one" and use it (so, hoping someone knows off the top of their head). >>> >>> FYI, this can be seen by using the b3 aggregator
[cross-project-issues-dev] M2M ATL Re: Status and outlook for M7
Hi, FWIW, I couldn't get the M2M ATL entry (http://download.eclipse.org/modeling/m2m/atl/updates/milestones/3.3/) and it broke, reporting missing repos. Reverting wpiers' change so that it uses 3.2 instead works, but I'm sure that's not what's intended. Don't know what's going on here or if this is showing up in actual build but I thought I'd mention it. (And yes, my ssh does work, thanks Denis. Now I'm waiting on build to complete and may need further tweaks. David, please do not wait on me, but I'll re-enable and commit IIF I can get a clean local validation here.) -Miles On 2012-05-09, at 9:18 AM, Borislav Kapukaranov wrote: > Hey David, > > I just successfully validated the virgo.b3aggrcon and enabled it. We don't > have new content for this milestone but I updated the references to Equinox. > > Best Regards > Bobby > > On Wed, May 9, 2012 at 7:13 PM, Doug Schaefer wrote: > CDT is scrambling to fix some major issues. We may ask for more time. > Hopefully not. > > Thanks, > Doug > > From: David M Williams > Reply-To: Cross project issues > Date: Wednesday, 9 May, 2012 12:11 PM > > To: Cross project issues > Subject: Re: [cross-project-issues-dev] Status and outlook for M7 > > Reminder ... it is +3 day! 5 PM this evening (Eastern) will be "cut-off" > unless someone asks for a few extra hours. > > I removed the emf compare feature from modeling category, since it was cause > build to fail. If there is some other one that's supposed to be there, please > add it back. > > The following still have disabled repositories or features: > > amp.b3aggrcon > equinox.b3aggrcon > jetty.b3aggrcon > mft.b3aggrcon > riena.b3aggrcon > virgo.b3aggrcon > > Any word? > > I can speak to the equinox one. See bug 378735[1]. It is related to the > org.eclipse.rcp.sdk.id "product". I _think_ I can add it back for RC1. But > is anyone using it? Can anyone document a use case? It has not been > working/available for all of Juno, so far, and no one has really complained, > and no one seems to have a clear id of if or why its needed. > So, I know it'd be short notice to remove it ... but ... would also > appreciate someone clearly saying why its needed. > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=378735 > > > David M Williams---05/09/2012 10:45:14 AM---Thanks for replying. > But, I'm a little confused, as the be current aggregation builds are failing > ou > > From: David M Williams/Raleigh/IBM@IBMUS > To: laurent.gou...@obeo.fr, Cross project issues > , > Date: 05/09/2012 10:45 AM > Subject: Re: [cross-project-issues-dev] Status and outlook for M7 > Sent by: cross-project-issues-dev-boun...@eclipse.org > > > > Thanks for replying. But, I'm a little confused, as the be current > aggregation builds are failing out-of-the-gate saying there is a problem with > the model, at the emf.compare in the "modeling category" does not refer to > the right one. And, apparently comes from several sources? (at least in > past?) so ... is there supposed to be _any_ emf.compare in Juno? Or is it > completely gone? If the later, I'll just remove it from the category. If the > the former ... I'll have to hunt around for which is "the right one" and use > it (so, hoping someone knows off the top of their head). > > FYI, this can be seen by using the b3 aggregator editor, selecting the top > level "aggregation" note, and then running the "validate" command from > context menu. (Not even "validate aggregation", just "validate" which just > validates the XML and EMF model). > > Thanks, > > > Laurent Goubet ---05/09/2012 09:02:33 AM---Hi, Sorry about the delay before > replying, May has a lot of holidays here :). > > From: Laurent Goubet > To: Cross project issues , > Date: 05/09/2012 09:02 AM > Subject: Re: [cross-project-issues-dev] Status and outlook for M7 > Sent by: cross-project-issues-dev-boun...@eclipse.org > > > > Hi, > > Sorry about the delay before replying, May has a lot of holidays here :). > > emf-compare.b3aggrcon indeed had one repository "disabled"... that was only a > leftover from a previous milestone and did not impact M7. We've removed that > repository from the file. > > Laurent Goubet > Obeo > > On 06/05/2012 21:38, David M Williams wrote: > > Yes ... its here, M7 week! And, I'm already giving status! > > First thing to note it that we now have a stand-alone 4.2 primary build from > the Eclipse Project, so for the first time we have a pure and correct 4.2 > repo. In the past, some things from 3.8 were "slipping in" through > aggregation due to the way the platform was producing and partially > (unknowingly) combining 3.8 and 4.2. But no more, 4.2 only. > > One impact of this, is the bundle 'org.eclipse.help.appserver' is no longer > available ... it was actually removed in 4.1, but it is being left in the 3.x > stream, even though 3.8 does not use it. It now correctly does _not_ show up > in 4.2 repo via aggregation. > > And, t
Re: [cross-project-issues-dev] git ssh? Re: Status and outlook for M7
Thanks Adolfo, and yes, I've just noticed that my entire eclipse ssh access is completely down, period. I think it might have been one too many git automated bad login. I've put a bug in for Matt and Dennis to take a look. I can't help thinking that there is a powerful force in the space-time continuum that just doesn't want amp in the Juno release. On 2012-05-09, at 2:24 PM, Adolfo Sanchez Barbudo wrote: > Hello Miles, > > Perhaps your IP has been banned in somehow. > > I''ve got a similar problem last week -> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=378451 > > Send an email to Dennis with your IP address so that he can verify it's not > banned. > > Cheers, > Adolfo. > > 2012/5/9 Miles Parker > > Meanwhile, I can't seem to ssh to the amp repos to make a four character > change. Sigh.. Has anyone run into an issue? I can get there with git and > http, just not with ssh, where I get a timeout. (I haven't tried to push in > the last few months so perhaps something changed on the servers -- the URI > I'm using is using the exact same format as my other repos which work fine.) > > On 2012-05-09, at 2:04 PM, Doug Schaefer wrote: > >> I take that back. We have a fix that will allow the community to test the >> CDT with the Windows gcc compilers. I need to do a new build and submit it. >> Looks like that'll take an hour or so. >> >> Sorry, >> Doug. >> >> From: Doug Schaefer >> Reply-To: Cross project issues >> Date: Wednesday, 9 May, 2012 3:58 PM >> To: Cross project issues >> Subject: Re: [cross-project-issues-dev] Status and outlook for M7 >> >> BTW, CDT is good to go. The next time the aggregator runs it'll pick up our >> new build. >> >> Cheers, >> Doug. >> >> From: Doug Schaefer >> Reply-To: Cross project issues >> Date: Wednesday, 9 May, 2012 12:13 PM >> To: Cross project issues >> Subject: Re: [cross-project-issues-dev] Status and outlook for M7 >> >> CDT is scrambling to fix some major issues. We may ask for more time. >> Hopefully not. >> >> Thanks, >> Doug >> >> From: David M Williams >> Reply-To: Cross project issues >> Date: Wednesday, 9 May, 2012 12:11 PM >> To: Cross project issues >> Subject: Re: [cross-project-issues-dev] Status and outlook for M7 >> >> Reminder ... it is +3 day! 5 PM this evening (Eastern) will be "cut-off" >> unless someone asks for a few extra hours. >> >> I removed the emf compare feature from modeling category, since it was cause >> build to fail. If there is some other one that's supposed to be there, >> please add it back. >> >> The following still have disabled repositories or features: >> >> amp.b3aggrcon >> equinox.b3aggrcon >> jetty.b3aggrcon >> mft.b3aggrcon >> riena.b3aggrcon >> virgo.b3aggrcon >> >> Any word? >> >> I can speak to the equinox one. See bug 378735[1]. It is related to the >> org.eclipse.rcp.sdk.id "product". I _think_ I can add it back for RC1. But >> is anyone using it? Can anyone document a use case? It has not been >> working/available for all of Juno, so far, and no one has really complained, >> and no one seems to have a clear id of if or why its needed. >> So, I know it'd be short notice to remove it ... but ... would also >> appreciate someone clearly saying why its needed. >> >> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=378735 >> >> >> David M Williams---05/09/2012 10:45:14 AM---Thanks for >> replying. But, I'm a little confused, as the be current aggregation builds >> are failing ou >> >> From: David M Williams/Raleigh/IBM@IBMUS >> To: laurent.gou...@obeo.fr, Cross project issues >> , >> Date: 05/09/2012 10:45 AM >> Subject: Re: [cross-project-issues-dev] Status and outlook for M7 >> Sent by: cross-project-issues-dev-boun...@eclipse.org >> >> >> >> Thanks for replying. But, I'm a little confused, as the be current >> aggregation builds are failing out-of-the-gate saying there is a problem >> with the model, at the emf.compare in the "modeling category" does not refer >> to the right one. And, apparently comes from several sources? (at least in >> past?) so ... is there supposed to be _any_ emf.compare in Juno? Or is it >> completely gone? If the later, I'll just remove it from the category. If the >> the former ... I'll have to hunt around for which is
[cross-project-issues-dev] git ssh? Re: Status and outlook for M7
Meanwhile, I can't seem to ssh to the amp repos to make a four character change. Sigh.. Has anyone run into an issue? I can get there with git and http, just not with ssh, where I get a timeout. (I haven't tried to push in the last few months so perhaps something changed on the servers -- the URI I'm using is using the exact same format as my other repos which work fine.) On 2012-05-09, at 2:04 PM, Doug Schaefer wrote: > I take that back. We have a fix that will allow the community to test the CDT > with the Windows gcc compilers. I need to do a new build and submit it. Looks > like that'll take an hour or so. > > Sorry, > Doug. > > From: Doug Schaefer > Reply-To: Cross project issues > Date: Wednesday, 9 May, 2012 3:58 PM > To: Cross project issues > Subject: Re: [cross-project-issues-dev] Status and outlook for M7 > > BTW, CDT is good to go. The next time the aggregator runs it'll pick up our > new build. > > Cheers, > Doug. > > From: Doug Schaefer > Reply-To: Cross project issues > Date: Wednesday, 9 May, 2012 12:13 PM > To: Cross project issues > Subject: Re: [cross-project-issues-dev] Status and outlook for M7 > > CDT is scrambling to fix some major issues. We may ask for more time. > Hopefully not. > > Thanks, > Doug > > From: David M Williams > Reply-To: Cross project issues > Date: Wednesday, 9 May, 2012 12:11 PM > To: Cross project issues > Subject: Re: [cross-project-issues-dev] Status and outlook for M7 > > Reminder ... it is +3 day! 5 PM this evening (Eastern) will be "cut-off" > unless someone asks for a few extra hours. > > I removed the emf compare feature from modeling category, since it was cause > build to fail. If there is some other one that's supposed to be there, please > add it back. > > The following still have disabled repositories or features: > > amp.b3aggrcon > equinox.b3aggrcon > jetty.b3aggrcon > mft.b3aggrcon > riena.b3aggrcon > virgo.b3aggrcon > > Any word? > > I can speak to the equinox one. See bug 378735[1]. It is related to the > org.eclipse.rcp.sdk.id "product". I _think_ I can add it back for RC1. But > is anyone using it? Can anyone document a use case? It has not been > working/available for all of Juno, so far, and no one has really complained, > and no one seems to have a clear id of if or why its needed. > So, I know it'd be short notice to remove it ... but ... would also > appreciate someone clearly saying why its needed. > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=378735 > > > David M Williams---05/09/2012 10:45:14 AM---Thanks for replying. > But, I'm a little confused, as the be current aggregation builds are failing > ou > > From: David M Williams/Raleigh/IBM@IBMUS > To: laurent.gou...@obeo.fr, Cross project issues > , > Date: 05/09/2012 10:45 AM > Subject: Re: [cross-project-issues-dev] Status and outlook for M7 > Sent by: cross-project-issues-dev-boun...@eclipse.org > > > > Thanks for replying. But, I'm a little confused, as the be current > aggregation builds are failing out-of-the-gate saying there is a problem with > the model, at the emf.compare in the "modeling category" does not refer to > the right one. And, apparently comes from several sources? (at least in > past?) so ... is there supposed to be _any_ emf.compare in Juno? Or is it > completely gone? If the later, I'll just remove it from the category. If the > the former ... I'll have to hunt around for which is "the right one" and use > it (so, hoping someone knows off the top of their head). > > FYI, this can be seen by using the b3 aggregator editor, selecting the top > level "aggregation" note, and then running the "validate" command from > context menu. (Not even "validate aggregation", just "validate" which just > validates the XML and EMF model). > > Thanks, > > > Laurent Goubet ---05/09/2012 09:02:33 AM---Hi, Sorry about the delay before > replying, May has a lot of holidays here :). > > From: Laurent Goubet > To: Cross project issues , > Date: 05/09/2012 09:02 AM > Subject: Re: [cross-project-issues-dev] Status and outlook for M7 > Sent by: cross-project-issues-dev-boun...@eclipse.org > > > > Hi, > > Sorry about the delay before replying, May has a lot of holidays here :). > > emf-compare.b3aggrcon indeed had one repository "disabled"... that was only a > leftover from a previous milestone and did not impact M7. We've removed that > repository from the file. > > Laurent Goubet > Obeo > > On 06/05/2012 21:38, David M Williams wrote: > > Yes ... its here, M7 week! And, I'm already giving status! > > First thing to note it that we now have a stand-alone 4.2 primary build from > the Eclipse Project, so for the first time we have a pure and correct 4.2 > repo. In the past, some things from 3.8 were "slipping in" through > aggregation due to the way the platform was producing and partially > (unknowingly) combining 3.8 and 4.2. But no more, 4.2 only. > > One impact of this, is the bundle
Re: [cross-project-issues-dev] Status and outlook for M7
Thanks for the clarification, Carsten. I vote for removing it to avoid confusion. At this point we should have functionality locked down for Juno. On 2012-05-09, at 11:36 AM, Carsten Reckord wrote: > Just to avoid any misunderstanding on the MFT aggregation: > > The MFT Papyrus feature is still listed in there as disabled. Since we > currently don't ship this feature, it should stay disabled or be removed. > > Miles Parker wrote: > >> >> Hi David, >> >> I seem doomed to be involved with projects that are +3 or more. :| >> >> I believe that MFT is ready to go and just needed to be enabled, which >> Steffen took care of a couple of days ago. See: >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=378601 Steffen, should >> this be working now? >> >> Now that BIRT has had their site renamed and fixed some issues, I'm >> going to have another try at getting amp up and running as well. >> >> And no, the Virgo one isn't mine in this case. :) (Virgo Tooling isn't >> in Juno train.) >> >> cheers, >> >> Miles >> >> __ >> Miles T. Parker >> Senior Engineer and Product Manager, Tasktop >> http://tasktop.com >> Committer, Eclipse Mylyn and Virgo >> Project Lead, Model Focussing Tools and AMP >> http://milesparker.blogspot.com >> >> On 2012-05-09, at 9:11 AM, David M Williams wrote: >> >>> Reminder ... it is +3 day! 5 PM this evening (Eastern) will be >> "cut-off" unless someone asks for a few extra hours. >>> >>> I removed the emf compare feature from modeling category, since it >> was cause build to fail. If there is some other one that's supposed to >> be there, please add it back. >>> >>> The following still have disabled repositories or features: >>> >>> amp.b3aggrcon >>> equinox.b3aggrcon >>> jetty.b3aggrcon >>> mft.b3aggrcon >>> riena.b3aggrcon >>> virgo.b3aggrcon >>> >>> Any word? >>> >>> I can speak to the equinox one. See bug 378735[1]. It is related to >> the org.eclipse.rcp.sdk.id "product". I _think_ I can add it back for >> RC1. But is anyone using it? Can anyone document a use case? It has not >> been working/available for all of Juno, so far, and no one has really >> complained, and no one seems to have a clear id of if or why its >> needed. >>> So, I know it'd be short notice to remove it ... but ... would also >> appreciate someone clearly saying why its needed. >>> >>> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=378735 >>> >>> >>> David M Williams---05/09/2012 10:45:14 AM---Thanks for >> replying. But, I'm a little confused, as the be current aggregation >> builds are failing ou >>> >>> From: David M Williams/Raleigh/IBM@IBMUS >>> To: laurent.gou...@obeo.fr, Cross project issues >> , >>> Date: 05/09/2012 10:45 AM >>> Subject:Re: [cross-project-issues-dev] Status and outlook for M7 >>> Sent by:cross-project-issues-dev-boun...@eclipse.org >>> >>> >>> >>> Thanks for replying. But, I'm a little confused, as the be current >> aggregation builds are failing out-of-the-gate saying there is a >> problem with the model, at the emf.compare in the "modeling category" >> does not refer to the right one. And, apparently comes from several >> sources? (at least in past?) so ... is there supposed to be _any_ >> emf.compare in Juno? Or is it completely gone? If the later, I'll just >> remove it from the category. If the the former ... I'll have to hunt >> around for which is "the right one" and use it (so, hoping someone >> knows off the top of their head). >>> >>> FYI, this can be seen by using the b3 aggregator editor, selecting >> the top level "aggregation" note, and then running the "validate" >> command from context menu. (Not even "validate aggregation", just >> "validate" which just validates the XML and EMF model). >>> >>> Thanks, >>> >>> >>> Laurent Goubet ---05/09/2012 09:02:33 AM---Hi, Sorry about the delay >> before replying, May has a lot of holidays here :). >>> >>> From: Laurent Goubet >>> To: Cross project issues , >>> Date: 05/09/2012 09:02 AM >>> Subject: Re: [cross-project-issues-dev] Status and outlook for M7 >>> Sent by: cross-
Re: [cross-project-issues-dev] Status and outlook for M7
Hi David, I seem doomed to be involved with projects that are +3 or more. :| I believe that MFT is ready to go and just needed to be enabled, which Steffen took care of a couple of days ago. See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=378601 Steffen, should this be working now? Now that BIRT has had their site renamed and fixed some issues, I'm going to have another try at getting amp up and running as well. And no, the Virgo one isn't mine in this case. :) (Virgo Tooling isn't in Juno train.) cheers, Miles __ Miles T. Parker Senior Engineer and Product Manager, Tasktop http://tasktop.com Committer, Eclipse Mylyn and Virgo Project Lead, Model Focussing Tools and AMP http://milesparker.blogspot.com On 2012-05-09, at 9:11 AM, David M Williams wrote: > Reminder ... it is +3 day! 5 PM this evening (Eastern) will be "cut-off" > unless someone asks for a few extra hours. > > I removed the emf compare feature from modeling category, since it was cause > build to fail. If there is some other one that's supposed to be there, please > add it back. > > The following still have disabled repositories or features: > > amp.b3aggrcon > equinox.b3aggrcon > jetty.b3aggrcon > mft.b3aggrcon > riena.b3aggrcon > virgo.b3aggrcon > > Any word? > > I can speak to the equinox one. See bug 378735[1]. It is related to the > org.eclipse.rcp.sdk.id "product". I _think_ I can add it back for RC1. But > is anyone using it? Can anyone document a use case? It has not been > working/available for all of Juno, so far, and no one has really complained, > and no one seems to have a clear id of if or why its needed. > So, I know it'd be short notice to remove it ... but ... would also > appreciate someone clearly saying why its needed. > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=378735 > > > David M Williams---05/09/2012 10:45:14 AM---Thanks for replying. > But, I'm a little confused, as the be current aggregation builds are failing > ou > > From: David M Williams/Raleigh/IBM@IBMUS > To: laurent.gou...@obeo.fr, Cross project issues > , > Date: 05/09/2012 10:45 AM > Subject: Re: [cross-project-issues-dev] Status and outlook for M7 > Sent by: cross-project-issues-dev-boun...@eclipse.org > > > > Thanks for replying. But, I'm a little confused, as the be current > aggregation builds are failing out-of-the-gate saying there is a problem with > the model, at the emf.compare in the "modeling category" does not refer to > the right one. And, apparently comes from several sources? (at least in > past?) so ... is there supposed to be _any_ emf.compare in Juno? Or is it > completely gone? If the later, I'll just remove it from the category. If the > the former ... I'll have to hunt around for which is "the right one" and use > it (so, hoping someone knows off the top of their head). > > FYI, this can be seen by using the b3 aggregator editor, selecting the top > level "aggregation" note, and then running the "validate" command from > context menu. (Not even "validate aggregation", just "validate" which just > validates the XML and EMF model). > > Thanks, > > > Laurent Goubet ---05/09/2012 09:02:33 AM---Hi, Sorry about the delay before > replying, May has a lot of holidays here :). > > From: Laurent Goubet > To: Cross project issues , > Date: 05/09/2012 09:02 AM > Subject: Re: [cross-project-issues-dev] Status and outlook for M7 > Sent by: cross-project-issues-dev-boun...@eclipse.org > > > > Hi, > > Sorry about the delay before replying, May has a lot of holidays here :). > > emf-compare.b3aggrcon indeed had one repository "disabled"... that was only a > leftover from a previous milestone and did not impact M7. We've removed that > repository from the file. > > Laurent Goubet > Obeo > > On 06/05/2012 21:38, David M Williams wrote: > > Yes ... its here, M7 week! And, I'm already giving status! > > First thing to note it that we now have a stand-alone 4.2 primary build from > the Eclipse Project, so for the first time we have a pure and correct 4.2 > repo. In the past, some things from 3.8 were "slipping in" through > aggregation due to the way the platform was producing and partially > (unknowingly) combining 3.8 and 4.2. But no more, 4.2 only. > > One impact of this, is the bundle 'org.eclipse.help.appserver' is no longer > available ... it was actually removed in 4.1, but it is being left in the 3.x > stream, even though 3.8 does not use it. It now correctly does _not_ show up > in 4.2 repo via aggregation. > > And, this "broke" BIRT ... so, I disabled that, which rippled across 3 or 4 > others that depend on BIRT charting. > I hope BIRT can live without that old bundle and use the jetty server now > provided by the platform (and used by the help system, in both 3.8 and 4.2). > http://git.eclipse.org/c/platform/eclipse.platform.common.git/plain/bundles/org.eclipse.platform.doc.isv/porting/4.2/incompatibili
[cross-project-issues-dev] Request for comment: Provide standard update site locations
Hi all, Please see the bug below. Isn't it about time we had a good common approach to this? 377111: Provide standard update site locations https://bugs.eclipse.org/bugs/show_bug.cgi?id=377111 Please follow up on bug. cheers, Miles ___ 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] heads up on some temporary disabled repos/features
Thanks Dennis; perhaps this is coming from BIRT or somewhere else. As always, AMP is the universal consumer, so we seem to encounter issues that no one else does. (BTW, I'm not having any time to devote to AMP build/project maintenance right now so it may be that if I can't resolve the BIRT issue easily we may just have to drop out of Juno. I'll of course update the appropriate channels if that becomes true.) On 2012-03-20, at 11:36 AM, Dennis Hübner wrote: > Hi Miles, > Am 20.03.2012 um 18:28 schrieb Miles Parker: > >> My guess is that it is more complicated than that. AMP doesn't have an >> actual google.collect dependency, but XText does, and we're dependent on >> them; for that reason I probably put in the explicit inclusion of >> google.collect to support our RCP build. > > > Xtext depends on com.google.guava bundle > 10.0.1 , therefore we ship and > include it. So there should be any com.google.collect bundle requirements in > Xtext at all. If you find one in Xtext M6, please let me know. > > Regards, > Dennis Huebner. > ___ > 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] heads up on some temporary disabled repos/features
On 2012-03-20, at 9:47 AM, David M Williams wrote:
> Since you may not "see" an error report on this until this evening, I
> wanted to note the following issue:
>
> Amp was conflicting with BIRT's latest contribution (I think that's the
> order of events) and has been for a while, so I disabled Amp for now. Feel
> free to re-enable when ready.
No, it's BIRT that's conflicting with us. :D Something that came up earlier
this year but I thought had been resolved. Thanks for alerting me David!
>
> That's business as usual ... auto error reports were sent, but no fix
> yet ... but the funny thing was _then_ 3 features (one in OCL and two in
> Mylyn)
> started "failing" due to "missing google.collect bundle". Not sure if that
> was due to BIRT change, or Amp omission, but,
> if you have a feature that needs one of those third-party ("orbit") bundles
> the normal thing to do is include it yourself in one of your own features,
> not to count on the "luck" of someone else including it.
My guess is that it is more complicated than that. AMP doesn't have an actual
google.collect dependency, but XText does, and we're dependent on them; for
that reason I probably put in the explicit inclusion of google.collect to
support our RCP build.
>
> So, all that is from some "local" tests since I want to get a green build
> soon ... so after that, will start to "re-enable" those features to make
> sure still happens there, but at the rate
> we're going, that won't show up as "error messages" to you until this
> evening ... so ... thought I'd give a bit of early warning.
>
> Hope this helps,
>
>
> ___
> 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] [virgo-dev] Fwd: Disk usage report for Hudson/Build
Actually, for the record, it wasn't the IDE build, it was the kernel build that had the 27GB usage. But it looks like someone else on Virgo team has taken care of that. On Feb 29, 2012, at 11:13 AM, Miles Parker wrote: > I hadn't thought to look and had no idea we were using up so many resources > :O, thanks for the heads up. I've set us up to keep 30 builds (we need some > back history at the dependencies are evolving rapidly) but only the last five > artifacts. That should reduce things up nicely. :) > > On Feb 29, 2012, at 1:19 AM, Glyn Normington wrote: > >> Thanks for spotting this Hristo. >> >> I've asked someone on the tooling side to look into this. I was unsure about >> setting the limit because of the need to maintain the Virgo IDE update site >> appropriately. >> >> Regards, >> Glyn >> >> On 29 Feb 2012, at 07:33, Hristo Iliev wrote: >> >>> Hi, >>> >>> Virgo IDE build takes a lot of space and it keeps a old builds. Do we need >>> all of these or we can just keep 5 or let's say 10? >>> >>> Additionally there was a problem with Hudson resource usage (discussed in >>> the cross-project mailing list) and all projects are required to minimize >>> the number of builds until the problem is solved. >>> >>> Regards, >>> Hristo Iliev >>> >>> -- Forwarded message -- >>> From: >>> Date: 28 February 2012 20:41 >>> Subject: [cross-project-issues-dev] Disk usage report for Hudson/Build >>> To: cross-project-issues-dev@eclipse.org >>> >>> >>> Compiled 2012-02-28T12:07 >>> >>> build.eclipse.org >>> -> Usage exceeding 1GB for: Hudson master jobs and workspace >>> (2012-02-28T10:00) >>> 17.9G eclipse-equinox-test-N >>> 3.8G cbi-scout-3.7 >>> 3.0G cbi-pdt-3.0-indigo >>> 2.9G cbi-pdt-2.2-helios >>> 2.1G emf-cdo-integration >>> 2.1G Xtext-nightly-HEAD >>> 1.9G rtp-packages >>> 1.5G gmp-graphiti-nightly >>> 1.5G jobs >>> 1.4G tycho-gmp.gmf.tooling >>> 1.4G amp-integration >>> 1.3G ptp-master-release >>> 1.3G virgo.ide.snapshot >>> 1.2G ptp-release >>> 1.2G buckminster-egf-helios >>> 1.2G mdt-etrice-nightly >>> 1.2G buckminster-voicetools-targetplatform >>> 1.2G ptp-nightly >>> 1.1G tycho-query2-nightly >>> 1.1G rap-runtime >>> 1.1G tycho-gmp.gmf.tooling.maintenance >>> 1.1G hudson-core >>> 1.1G epp-mpc-e3.7 >>> 1.1G Xtext-test >>> 1.1G ptp-4.1 >>> 1.0G linuxtools-master >>> 1.0G mylyn-builds-nightly >>> 1.0G Xtext-Maven-Deploy >>> -> Usage exceeding 1GB for: /shared (1000G capacity) (2012-02-28T10:00) >>> 331.8G technology >>> 108.2G eclipse >>> 107.9G jobs.back >>> 106.0G jobs >>> 40.7G rt >>> 23.9G webtools >>> 17.0G SLES >>> 10.7G tools >>> 8.5G modeling >>> 5.4G common >>> 5.0G juno >>> 4.2G orbit >>> 3.0G helios >>> 2.4G indigo >>> 1.3G mylyn >>> 1.2G cbi >>> -> Usage exceeding 1GB for: /shared/modeling >>> 3.7G searchcvs >>> 3.1G build >>> -> Usage exceeding 1GB for: /shared/tools >>> 3.5G tm >>> 2.0G objectteams >>> 1.4G mtj >>> 1.3G windowbuilder >>> 1.2G sequoyah >>> 1.1G aspectj >>> -> Usage exceeding 1GB for: /shared/technology >>> 304.1G epp >>> 14.4G sapphire >>> 4.8G stem >>> 2.4G cosmos >>> 2.4G gyrex >>> 1.8G babel >>> END: build.eclipse.org >>> >>> >>> hudson-slave1.eclipse.org >>> /dev/xvda1334G 131G 204G 40% / >>> -> Usage exceeding 1GB for: Hudson workspace on hudson-slave1 (50G >>> capacity) (2012-02-28T10:00) >>> 22.7G virgo.kernel.snapshot >>> 5.3G cdt-master-maint >>> 4.8G cdt-master-nightly >>> 3.1G tycho-mat-nightly >>> 2.4G ptp-master-nightly >>> 2.0G cdt-edc-nightly >>> 2.0G tcf-maint >>> 2.0G papyrus-0.8-maintenance-nightly >>> 1.9G ptp-master-release >>> 1.9G mylyn-integration >>> 1.6G dltk-nightly >>> 1.4G cbi-scout-3.7 >>> 1.4G rmf-nightly >>> 1.4G
Re: [cross-project-issues-dev] [virgo-dev] Fwd: Disk usage report for Hudson/Build
I hadn't thought to look and had no idea we were using up so many resources :O, thanks for the heads up. I've set us up to keep 30 builds (we need some back history at the dependencies are evolving rapidly) but only the last five artifacts. That should reduce things up nicely. :) On Feb 29, 2012, at 1:19 AM, Glyn Normington wrote: > Thanks for spotting this Hristo. > > I've asked someone on the tooling side to look into this. I was unsure about > setting the limit because of the need to maintain the Virgo IDE update site > appropriately. > > Regards, > Glyn > > On 29 Feb 2012, at 07:33, Hristo Iliev wrote: > >> Hi, >> >> Virgo IDE build takes a lot of space and it keeps a old builds. Do we need >> all of these or we can just keep 5 or let's say 10? >> >> Additionally there was a problem with Hudson resource usage (discussed in >> the cross-project mailing list) and all projects are required to minimize >> the number of builds until the problem is solved. >> >> Regards, >> Hristo Iliev >> >> -- Forwarded message -- >> From: >> Date: 28 February 2012 20:41 >> Subject: [cross-project-issues-dev] Disk usage report for Hudson/Build >> To: cross-project-issues-dev@eclipse.org >> >> >> Compiled 2012-02-28T12:07 >> >> build.eclipse.org >> -> Usage exceeding 1GB for: Hudson master jobs and workspace >> (2012-02-28T10:00) >> 17.9G eclipse-equinox-test-N >> 3.8G cbi-scout-3.7 >> 3.0G cbi-pdt-3.0-indigo >> 2.9G cbi-pdt-2.2-helios >> 2.1G emf-cdo-integration >> 2.1G Xtext-nightly-HEAD >> 1.9G rtp-packages >> 1.5G gmp-graphiti-nightly >> 1.5G jobs >> 1.4G tycho-gmp.gmf.tooling >> 1.4G amp-integration >> 1.3G ptp-master-release >> 1.3G virgo.ide.snapshot >> 1.2G ptp-release >> 1.2G buckminster-egf-helios >> 1.2G mdt-etrice-nightly >> 1.2G buckminster-voicetools-targetplatform >> 1.2G ptp-nightly >> 1.1G tycho-query2-nightly >> 1.1G rap-runtime >> 1.1G tycho-gmp.gmf.tooling.maintenance >> 1.1G hudson-core >> 1.1G epp-mpc-e3.7 >> 1.1G Xtext-test >> 1.1G ptp-4.1 >> 1.0G linuxtools-master >> 1.0G mylyn-builds-nightly >> 1.0G Xtext-Maven-Deploy >> -> Usage exceeding 1GB for: /shared (1000G capacity) (2012-02-28T10:00) >> 331.8G technology >> 108.2G eclipse >> 107.9G jobs.back >> 106.0G jobs >> 40.7G rt >> 23.9G webtools >> 17.0G SLES >> 10.7G tools >> 8.5G modeling >> 5.4G common >> 5.0G juno >> 4.2G orbit >> 3.0G helios >> 2.4G indigo >> 1.3G mylyn >> 1.2G cbi >> -> Usage exceeding 1GB for: /shared/modeling >> 3.7G searchcvs >> 3.1G build >> -> Usage exceeding 1GB for: /shared/tools >> 3.5G tm >> 2.0G objectteams >> 1.4G mtj >> 1.3G windowbuilder >> 1.2G sequoyah >> 1.1G aspectj >> -> Usage exceeding 1GB for: /shared/technology >> 304.1G epp >> 14.4G sapphire >> 4.8G stem >> 2.4G cosmos >> 2.4G gyrex >> 1.8G babel >> END: build.eclipse.org >> >> >> hudson-slave1.eclipse.org >> /dev/xvda1334G 131G 204G 40% / >> -> Usage exceeding 1GB for: Hudson workspace on hudson-slave1 (50G capacity) >> (2012-02-28T10:00) >> 22.7G virgo.kernel.snapshot >> 5.3G cdt-master-maint >> 4.8G cdt-master-nightly >> 3.1G tycho-mat-nightly >> 2.4G ptp-master-nightly >> 2.0G cdt-edc-nightly >> 2.0G tcf-maint >> 2.0G papyrus-0.8-maintenance-nightly >> 1.9G ptp-master-release >> 1.9G mylyn-integration >> 1.6G dltk-nightly >> 1.4G cbi-scout-3.7 >> 1.4G rmf-nightly >> 1.4G sapphire-0.5.x >> 1.3G cdt-nightly >> 1.3G cdt-edc-maint >> 1.3G sapphire-0.4.x >> 1.2G mylyn-context-nightly >> 1.2G Xtext-nightly-HEAD >> 1.1G cbi-wtp.jpaeditor >> END: hudson-slave1.eclipse.org >> >> >> hudson-slave2.eclipse.org >> -> Usage exceeding 1GB for: >> END: hudson-slave2.eclipse.org >> >> >> hudson-slave3.eclipse.org >> /dev/xvda1 55G 37G 19G 67% / >> -> Usage exceeding 1GB for: Hudson workspace on hudson-slave3 (50G capacity) >> (2012-02-28T10:00) >> 1.5G jetty-nightly >> 1.4G tycho-its-linux-nightly >> 1.4G sapphire-0.5.x >> 1.4G Xtext-nightly-Maintenance >> 1.3G mylyn-release >> 1.3G sapphire-0.4.x >> 1.2G Xtext-nightly-HEAD >> 1.2G xtend-head-test >> 1.1G amp-nightly >> 1.1G jetty-nightly-8 >> END: hudson-slave3.eclipse.org >> >> ___ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >> >> ___ >> virgo-dev mailing list >> virgo-...@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/virgo-dev > > ___ > virgo-dev mailing list > virgo-...@eclipse.org > https://dev.eclipse.org/mailman/listinfo/virgo-dev __ Miles T. Parker Senior Engineer and Product Manager, Tasktop http://tasktop.com Committer
Re: [cross-project-issues-dev] Hudson shutdown wait from hell
Sorry Greg, totally my mistake in scanning the console log -- I was awestuck, actually -- but I had seen it hanging out there for quite a while; looks like maybe it was stuck on some kind of maven thing. I doubt that many of us are in the habit of checking up on our hudson builds -- that's sort of the whole point of CI. (It looks like Mylyn-Integration is the non-platform long build champion at 2 hr 40 min.) On Feb 8, 2012, at 2:45 PM, Greg Watson wrote: > Just to be strictly accurate, the last PTP run took 22 minutes, not 22 hours. > In any case, I don't check the hudson page regularly so I had no idea that it > was being shut down and this job was holding things up. An email to this list > would have helped. > > Greg > > On Feb 8, 2012, at 2:42 PM, Ed Willink wrote: > >> Hi Miles >> >> I suspect that the 'longest' job is often a job that is waiting for >> deadlocked broken daemons to magically unlock/time-out. >> >> I know that on a couple of occasions MDT/OCL was one of the blockers even >> though I had explicitly killed the problem jobs. >> >>Regards >> >> Ed >> >> >> On 08/02/2012 18:09, Miles Parker wrote: >>> Hi all, >>> >>> I wanted to bring up a Hudson annoyance and see if people had ideas for >>> improving this. What's happening now is that any time Hudson gets sent a >>> shutdown, everyone is locked out until the last job in queue finishes. >>> Which is a) Good news for the people with running builds, b) Bad news for >>> everyone else. Observing that most of the time most of us are in category >>> b) I vote for making things work better for group b). Nothing against PTP >>> :D, but they happen to be in group a) this time around and the last run >>> took 22 hours. :O But there are lot's of long builds out there. This means >>> that snapshots are delayed for everyone. >>> >>> So I'm wondering if it might be possible to have some kind of policy where >>> builds are terminated with prejudice under shutdown. I'm not sure if a) >>> this is even supportable OOTB in Hudson, and b) whether that would have the >>> possibility of FUBAR'ing anyone project builds. As project builds should >>> not be relying on previous state, I would say that the answer to b is >>> probably no. I also imagine allowance should be made for key builds such as >>> aggregator. IIRC in the past when in release panic mode we were triggering >>> hard shutdowns from time to time. >>> >>> thoughts? >>> >>> Miles >>> ___ >>> 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.1913 / Virus Database: 2112/4794 - Release Date: 02/07/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] Hudson shutdown wait from hell / Virgo jobs killed
I've killed the Virgo jobs I have access to since we're not on release train. Virgo Team: I'm not responsible for builds, so hope that's ok w/ everyone :O but I know that most of the committers are in Europe and may not be monitoring..if anyone on Virgo wants to run before next push you'll need to manually restart. (We actually do have people wanting the Virgo IDE build but it can wait a couple of hours I should think.) On Feb 8, 2012, at 11:49 AM, David M Williams wrote: > I'd agree with this general idea ... perhaps a general notice go out on a > mailing list "hudson is being shutdown and restarted ... any jobs not done > by +1 hour [or something] will be killed". (I'm proud to say I cancelled > one of my running aggregator jobs when I saw it was about to be shutdown, > saving 50 minutes or so (if I was only job running) partially because > I knew it needed to run again anyway. I think we did that during Indigo release right? Problem of course is that people need to be monitoring which given that we're globally distributed means that someone will miss it. Maybe we need an "allow immediate kill on halt"? Or perhaps we could just ask if anyone objects to having their jobs killed unceremoniously? To avoid the deluge post restart, I wonder if there is any way in Hudson to allow projects to voluntarily specify a default wait time after restart to submit their jobs with the understanding that they can manually enqueue as appropriate? ___ 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] Hudson shutdown wait from hell
Hi all, I wanted to bring up a Hudson annoyance and see if people had ideas for improving this. What's happening now is that any time Hudson gets sent a shutdown, everyone is locked out until the last job in queue finishes. Which is a) Good news for the people with running builds, b) Bad news for everyone else. Observing that most of the time most of us are in category b) I vote for making things work better for group b). Nothing against PTP :D, but they happen to be in group a) this time around and the last run took 22 hours. :O But there are lot's of long builds out there. This means that snapshots are delayed for everyone. So I'm wondering if it might be possible to have some kind of policy where builds are terminated with prejudice under shutdown. I'm not sure if a) this is even supportable OOTB in Hudson, and b) whether that would have the possibility of FUBAR'ing anyone project builds. As project builds should not be relying on previous state, I would say that the answer to b is probably no. I also imagine allowance should be made for key builds such as aggregator. IIRC in the past when in release panic mode we were triggering hard shutdowns from time to time. thoughts? Miles ___ 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] Modeling dependencies
le individual. > > In the case of OCL, when the original IBM team retired, the resulting panic > stimulated so much enthusiasm for rescue that the competing offers had to be > mediated. Sadly little of this enthusiasm supports ongoing activities. > > [I don't see the system improving much unless Eclipse employs its committers > and companies make significant contributions to pay the corresponding > salaries.] > >Regards > >Ed Willink > On 17/12/2011 12:55, Philipp W. Kutter | Montages AG wrote: >> Perfect! >> >> I wish you all Happy Holidays! >> >> It is a great feeling that the OMG standards based projects are going strong >> and will all be on the Juno releasse train! >> >> If there is a doubt in the future that any of these projects will not be on >> the release train, simply because nobody is there to fulfill the formalities >> of the project or the details of the newest build project, we can always >> help. As Miles mentions, this may need to add some people of other modeling >> projects to the committer teams. >> >> Could the modeling PMC send out a mail and ask the modeling teams >> a) who sees a risk they will not be on the release train, simply because of >> lack to fulfill the formalities and the build project >> b) who would volunteer to help out for other projects. >> >> As well, it might be a good policy, to have a backup plan, if a component >> lead is either not available, or ill, or otherwise gone in the very moment >> he needs to promote the project. Immagine an important project, with lots of >> dependencies does not release, simply because the component lead is >> in-available. The costs can be huge. >> >> Thanks for the great work of the Eclipse Foundation, >> Philipp >> >> >> >> On 17.12.2011 01:44, Ed Willink wrote: >>> Hi Miles >>> >>> There is no need to panic. In view of some delicacies, considerable >>> correspondence has happened off-list. >>> >>> Nicolas Rouquette has now resolved both the problem and the delicacies by >>> his open email to these lists that you must have missed. >>> >>> Thanks to Nicolas' generosity, QVTo will be available in Juno supported by >>> the existing QVTo team. >>> >>> The only process exception that may be needed is tolerance of a one or two >>> day tardiness in setting the contribution flag. >>> >>> I'm sure we all wish to thank Nicolas for being so helpful to Eclipse. >>> Thank you Nicolas. >>> >>>Regards >>> >>>Ed Willink >>> >>> >>> On 16/12/2011 23:57, Miles Parker wrote: >>>> Philipp, >>>> >>>> You should identify QVTO leadership, which means M2M nee MMT, so that they >>>> can make the change in their portal. (This of course would have to be in >>>> the middle of a project renaming!) That would require all of MMT to join >>>> train, I don't know if it's possible to do this more fine-grained than >>>> that. PMC can flip the bit for MMT, but I don't think we should do that >>>> unless/until we have support from project leadership or at least active >>>> committers if they exist. Comments? >>>> >>>> William, I'm cc'ing you because I note that you have contact with Frédéric >>>> Jouault who is project lead..? Perhaps you could pass on his email to >>>> Phillip. >>>> >>>> FWLIW, I'll support any process exception if needed/possible once that is >>>> sorted out. Phillip, thanks for taking the initiative on this. Why don't >>>> you report back to PMC list as you make progress? >>>> >>>> cheers, >>>> >>>> Miles >>>> >>>> >>>> >>>> On Dec 16, 2011, at 12:29 PM, Philipp W. Kutter | Montages AG wrote: >>>> >>>>> Dear PMC. >>>>> >>>>> I would like to notify that QVTO should flip the bit for Juno. I hope >>>>> this has already been done by the QVTO team itself. >>>>> >>>>> In the unexpected case, that the current QVTO team will not have time to >>>>> trigger the newest ways of building the QVTO, I can guarantee >>>>> development time from the GMF Tolling component lead Michael Golubev, >>>>> who knows well the newest ways of building. >>>>> >>&g
Re: [cross-project-issues-dev] [modeling-pmc] Notifcation to let QVTO contribute to Juno
Philipp, You should identify QVTO leadership, which means M2M nee MMT, so that they can make the change in their portal. (This of course would have to be in the middle of a project renaming!) That would require all of MMT to join train, I don't know if it's possible to do this more fine-grained than that. PMC can flip the bit for MMT, but I don't think we should do that unless/until we have support from project leadership or at least active committers if they exist. Comments? William, I'm cc'ing you because I note that you have contact with Frédéric Jouault who is project lead..? Perhaps you could pass on his email to Phillip. FWLIW, I'll support any process exception if needed/possible once that is sorted out. Phillip, thanks for taking the initiative on this. Why don't you report back to PMC list as you make progress? cheers, Miles On Dec 16, 2011, at 12:29 PM, Philipp W. Kutter | Montages AG wrote: > Dear PMC. > > I would like to notify that QVTO should flip the bit for Juno. I hope > this has already been done by the QVTO team itself. > > In the unexpected case, that the current QVTO team will not have time to > trigger the newest ways of building the QVTO, I can guarantee > development time from the GMF Tolling component lead Michael Golubev, > who knows well the newest ways of building. > > As well, there is a cummulative patch from Nicolas Rouquette, which we > would love to integrate in the new build, if the QVTO team has not yet done. > > The GMF Tooling project has a strong dependency on QVTO and would fail > in their efforts to do their releases in the future, if QVTO build fails. > > As well, the sponsor of the 3 FTE working on GMF tooling requests that > GMF Tooling as well as the project it depends on are remaining in Juno, > so we have a multiyear 3 FTE sponsorship at risk, if this does not happen. > > > We want to do all to support the current team to do the Juno builds. > There is a budget from Nicolas Rouquette and us, which would offer $ > 2000 to who ever in the QVTO team wants to do this. And we support with > development time from the 3 FTE working on GMF Tooling, if needed. > > Please forward this message as well to the QVTO team, whom I do not know > personally. Please assure them of our full support. I did not find a mailing > list for them. > > And, as today is the deadline, please accept this notification, even if > formally it comes from the wrong side. > > Regards, > Philipp > > > ___ > modeling-pmc mailing list > modeling-...@eclipse.org > https://dev.eclipse.org/mailman/listinfo/modeling-pmc ___ 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] Xtext M4 ?
Yes, I think that would make sense for the given infrastructure. To be clear, what I was suggesting was not to necessarily actually *use* the meta-data for nightly and interim sites but simply to *track* them in addition to the milestone sites so that consumers could know with certainty what evolving target they're supposed to be building against. I've been in a situation where I thought I was building to the current repos for a dependency (my project has a very large number of such), but I'd actually been building against a non-maintained 'interim' site that only included stuff from the Helios release. I didn't figure that out until RC1 when my older dependency no longer worked. A significant advantage of that is that we could eventually build part of the project meta-data for the web sites from the aggregator so that any consumers would be pointed to the blessed version of each build site. It seems that almost every project has multiple old update sites out there and it is often an exercise in googling and trial and error to find the correct up to date site. -Miles (aka 'the universal consumer') On Dec 14, 2011, at 11:44 AM, Dennis Hübner wrote: >> > I think it's also a good idea to point b3 aggregator to projects nightly > update site after a milestone is released. > So dependent projects can earlier react to probably breaking changes. > > Regards, > Dennis. > >> >> Cheers, >> Adolfo. >> 2011/12/14 Miles Parker >> >>> I had thought last year that this was what aggregator was for, that is >>> that we could use the update sites indicated in the aggregator, but I >>> discovered that I was wrong. Perhaps we should legislate having that be in >>> sync, or add a separate set for Interim and Nightlies?It sure would be nice >>> to find out what version of dependencies we should be using without having >>> to consult typically out of date project web sites. >>> >>> On Dec 14, 2011, at 10:53 AM, John Arthorne wrote: >>> >>> The general form of this question would be good input for Wayne and his >>> project page organization. Currently projects declare with a flag that they >>> are participating in the simultaneous release, but there is no record that >>> I am aware of indicating which release they will contribute. For projects >>> whose own schedule matches the cadence of the release train this is fairly >>> obvious. But for other projects with more frequent releases I don't think >>> this information is available. To pick a random example, this morning I was >>> asking what release of Jetty would be in Juno and the answer wasn't so >>> clear. Maybe the juno "participation" flag should be metadata on a release >>> rather than just a generic flag on the project? For downstream projects and >>> consumers I expect this information would be really helpful. >>> >>> John >>> >>> >>> >>> >>> *Adolfo Sanchez Barbudo * >>> Sent by: cross-project-issues-dev-boun...@eclipse.org >>> >>> 12/14/2011 10:20 AM >>> Please respond to >>> Cross project issues >>> >>> To >>> cross-project-issues-dev@eclipse.org >>> cc >>> Subject >>> [cross-project-issues-dev] Xtext M4 ? >>> >>> >>> >>> >>> Hello Folks >>> >>> I'm wondering if Xtext guys are going to create any kind of milestone for >>> M4. >>> >>> Looking at their milestones repository[1] I only see an old 2.1.0M2. >>> >>> I don't find any clue in the project plan [2] neither . >>> >>> Any reason about why there is no an updated milestones repository would be >>> appreciated. Take into account that our milestones builds are based on >>> milestones repositories for those projects we depend on, so keeping the >>> usual (probably planned) milestones releases are important for us. >>> >>> [1] >>> *http://download.eclipse.org/modeling/tmf/xtext/updates/milestones*<http://download.eclipse.org/modeling/tmf/xtext/updates/milestones> >>> [2] * >>> http://www.eclipse.org/projects/project-plan.php?projectid=modeling.tmf.xtext >>> *<http://www.eclipse.org/projects/project-plan.php?projectid=modeling.tmf.xtext> >>> >>> P.S: I've not checked other itemis projects (xpand, mwe), but I guess we >>> will have the same problem with them. >>> >>> Best Regards, >>> Adolfo._
Re: [cross-project-issues-dev] Xtext M4 ?
I had thought last year that this was what aggregator was for, that is that we could use the update sites indicated in the aggregator, but I discovered that I was wrong. Perhaps we should legislate having that be in sync, or add a separate set for Interim and Nightlies?It sure would be nice to find out what version of dependencies we should be using without having to consult typically out of date project web sites. On Dec 14, 2011, at 10:53 AM, John Arthorne wrote: > The general form of this question would be good input for Wayne and his > project page organization. Currently projects declare with a flag that they > are participating in the simultaneous release, but there is no record that I > am aware of indicating which release they will contribute. For projects whose > own schedule matches the cadence of the release train this is fairly obvious. > But for other projects with more frequent releases I don't think this > information is available. To pick a random example, this morning I was asking > what release of Jetty would be in Juno and the answer wasn't so clear. Maybe > the juno "participation" flag should be metadata on a release rather than > just a generic flag on the project? For downstream projects and consumers I > expect this information would be really helpful. > > John > > > > > Adolfo Sanchez Barbudo > Sent by: cross-project-issues-dev-boun...@eclipse.org > 12/14/2011 10:20 AM > Please respond to > Cross project issues > > To > cross-project-issues-dev@eclipse.org > cc > Subject > [cross-project-issues-dev] Xtext M4 ? > > > > > > Hello Folks > > I'm wondering if Xtext guys are going to create any kind of milestone for M4. > > Looking at their milestones repository[1] I only see an old 2.1.0M2. > > I don't find any clue in the project plan [2] neither . > > Any reason about why there is no an updated milestones repository would be > appreciated. Take into account that our milestones builds are based on > milestones repositories for those projects we depend on, so keeping the usual > (probably planned) milestones releases are important for us. > > [1] http://download.eclipse.org/modeling/tmf/xtext/updates/milestones > [2] > http://www.eclipse.org/projects/project-plan.php?projectid=modeling.tmf.xtext > > P.S: I've not checked other itemis projects (xpand, mwe), but I guess we will > have the same problem with them. > > Best Regards, > Adolfo.___ > 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] Juno M4 status and outlook at end of +2 day ... calm before the storm?
IIRC, If it's not on the aggregator, we can't use it, and if it isn't in Juno it can't be part of aggregator. Besides AMP, which is comparatively small potatoes, there is GMF, Papyrus and all of the other graphical tools (including new ones like BPEL, etc..), so that would throw us all off. Aren't there some platform bits that consume Zest such as the dependency analyzer? (I guess that one is an add-on, now that I look.) I think the number one issue as far as maintaining for train would be whether GEF itself has dependencies on 3.7 only features, right? Otherwise it should be quite simple to update the build for e4. On Dec 13, 2011, at 8:33 PM, Ian Bull wrote: > Wayne, > > What happens if a 'producer' doesn't sign up for the train? What I mean is, > what happens if GEF -- which has historically been consumed by other projects > -- is not part of the train? Will the previous years bytes be available? Is > anybody who depends on GEF automatically 'off the train'? > > Cheers, > Ian > > On Tue, Dec 13, 2011 at 5:14 PM, Wayne Beaton wrote: > Hi Bob. > > You need to go to the project metadata in the portal and set the "juno" bit > under the simultaneousrelease entry. > > Wayne > > > On 12/13/2011 05:29 PM, Bob Brodt wrote: >> Hi Wayne, >> >> BPEL is hoping to be a new project this year, so just wanted to make sure >> we're on the list :) >> >> Thanks! >> Bob Brodt >> >> According to the participation list [1], we have 59 projects participating. >> Remember that I need you to flip the bit in the portal to show that you're >> participating. Sooner would be better than later. >> >> I did a quick run through of the project and have observed that the >> following projects are MIA from last year: >> AMP >> EMF Query >> EMF Transaction >> EMF Validation >> GEF >> GMF-Notation >> Mobile Tools For Java (MTJ) >> QVT Operational >> Sequoyah >> The math doesn't add up, so I've made a mistake somewhere... I may have to >> write a query. More later. >> >> Let me know if you're having trouble. >> >> Wayne >> >> [1] http://eclipse.org/projects/releases/releases.php >> >> On 12/13/2011 05:06 PM, David M Williams wrote: >> Or, are you all just getting good at this? :) >> >> Everything seems to be going well with contributions to M4 aggregation, but >> thought I'd send a reminder there's only one day left to get contributions >> in for M4. We'll consider 5 PM Wednesday the deadline, unless someone says >> "wait, almost ready". >> >> Thanks, >> >> ___ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >> >> >> -- >> Wayne Beaton >> The Eclipse Foundation >> Twitter: @waynebeaton >> >> >> Q >> >> ___ >> 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 > > -- > Wayne Beaton > The Eclipse Foundation > Twitter: @waynebeaton > <138x38.png> > > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > > > -- > R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 > http://eclipsesource.com | http://twitter.com/eclipsesource > ___ > 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
