Re: [cross-project-issues-dev] Eclipse IDE 2021-09 Simultaneous Release Participation

[Greg Watson]

Wayne,

I’m unclear on service releases. How will you be picking up the latest service 
release, or do we need a release record for it?

Greg

> On Aug 27, 2021, at 12:42 AM, Wayne Beaton 
>  wrote:
> 
> Greetings Folks.
> 
> There's some potentially interesting content about reducing the burden of the 
> IP Due Diligence Process in this note. Please read to the bottom.
> 
> I've created the Eclipse IDE 2021-09 Simultaneous Release Participation 
>  page. Please have a look to 
> ensure that I have the right version information for your project.
> 
> Note that, Eclipse Generation Factories (EGF) has dropped out of this release 
> (as notified 
> 
>  by the project lead). I did notice that the aggrcon file for this project, 
> along with those for Eclipse XWT and Eclipse Papyrus (both of which dropped 
> out of the previous release) still exist in the aggregator repository. I have 
> a vague recollection that we are to expect at least one of them back, so I'll 
> defer to the repository managers to decide what to do with these files.
> 
> As usual, I've tried to pick the version based on the date of the release. In 
> many/most cases, the page records that the same version that was included in 
> the last release is again included in this release. If your project's 
> contribution is a later release than what's indicated on the page, you will 
> need to create a release record for that later release (assuming that I 
> didn't just miss the one that's actually there), and let me know to use that 
> one instead. 
> 
> If your project is contributing a new release that is more than a service 
> release and the project has not engaged in either a release or progress 
> review since September 15/2020, then you need to engage in a review. Contact 
> e...@eclipse.org  at your very earliest convenience 
> to get started. There's more information regarding releases and reviews 
>  in the handbook.
> 
> As you know, we take intellectual property management very seriously. As 
> committers, you form the first line of defense in the Eclipse Foundation's IP 
> Due Diligence Process  and so 
> we depend on you to bring intellectual property issues to the IP Team's 
> attention. Even if your project does not require a review at this time, the 
> intellectual property included in and referred to by it (both project and 
> third party content) does need to be vetted in the usual manner.
> 
> I am hopeful that you have heard about our initiative to attempt to automate 
> the review of third-party content. We already have several projects using 
> this successfully, including a handful that have integrated it into their 
> builds. I've been running the Eclipse Dash License Tool 
>  on many of the repositories from 
> projects participating in the simultaneous release over the past several 
> months with good results. 
> 
> One of the challenges that I'm having with the tool is that it only checks 
> dependencies, it does not discover them. I've had a lot of success using 
> build technology (e.g. Maven) to generate the list of dependencies, but have 
> encountered some cases where the dependency list generated by a build is 
> incomplete. It would be helpful if you could try the Eclipse Dash License 
> Tool on your builds and let me know (i.e., open an issue 
> ) where you encounter challenges 
> generating input to the tool.
> 
> Note that there is an experimental feature that automatically creates review 
> requests for the IP Team via a repository on our new GitLab instance. It 
> would also be helpful to my team for you to try this out.
> 
> Note also that the Eclipse Dash License Tool is intended to help committers 
> work through the Eclipse IP Due Diligence Process. It is not the final 
> authority on what does or does not need to be reviewed. As the first line of 
> defense in the IP Due Diligence Process, we depend on committers to interpret 
> the output of the tool and generally understand the nature of the project's 
> dependencies. Currently, for example, it doesn't handle "works with" 
> dependencies 
>  very 
> well; so if you know that something that the tool complains about is a "works 
> with" dependency, then you can ignore any warnings it gives.
> 
> Taken from a different angle, the important thing is that intellectual 
> property is properly accounted for and vetted, not that the tool is happy 
> with what it finds. 
> 
> Thanks,
> 
> Wayne
> -- 
> Wayne Beaton
> Director of Open Source Projects | Eclipse Foundation
> ___
> cross-project-issues-dev mailing list
> 

Re: [cross-project-issues-dev] Who decided to override my Java installation with JustJ?

[Greg Watson]

Thanks Ed, that helped. Hopefully this will be fixed soon.

Regards,
Greg

> On Oct 15, 2020, at 10:17 AM, Ed Merks  wrote:
> 
> Greg,
> 
> I don't think anyone has figured out why a JRE is automatically installed 
> during update:
> 
>   https://bugs.eclipse.org/bugs/show_bug.cgi?id=567504
> 
> You can undo this effect just by removing the -vm argument (to end up with 
> the default) or by changing the -vm argument to the one you want it to use, 
> in your eclipse.ini.
> 
> It's liable to come back if there is an unexpected updated to the JRE in the 
> future...
> 
> Regards,
> Ed
> 
> 
> On 15.10.2020 15:11, Greg Watson wrote:
>> My Eclipse installation recently prompted me to upgrade (something new), so 
>> I accepted the advice. Now I’ve discovered that an unknown JRE was 
>> downloaded onto my machine and is being used to run Eclipse. This is broken 
>> on so many levels, I don’t even know where to start opening bug reports.
>> 
>> Since when does Eclipse start installing unauthorized versions of the JRE 
>> onto my machine without any notification, and that overrides my choice of 
>> the JRE (or JDK in my case) for running Eclipse? Not only is there no option 
>> to change or uninstall this, it breaks tools that rely on the JDK (e.g. 
>> Spring Boot Live hovers.)
>> 
>> Does anybody else see the problem here? Someone needs to rethink this kind 
>> of behavior.
>> 
>> In the mean time, does anyone know how to undo this mess, or am I forced to 
>> go back to 2020-06?
>> 
>> Regards,
>> Greg
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit 
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Who decided to override my Java installation with JustJ?

[Greg Watson]

My Eclipse installation recently prompted me to upgrade (something new), so I 
accepted the advice. Now I’ve discovered that an unknown JRE was downloaded 
onto my machine and is being used to run Eclipse. This is broken on so many 
levels, I don’t even know where to start opening bug reports. 

Since when does Eclipse start installing unauthorized versions of the JRE onto 
my machine without any notification, and that overrides my choice of the JRE 
(or JDK in my case) for running Eclipse? Not only is there no option to change 
or uninstall this, it breaks tools that rely on the JDK (e.g. Spring Boot Live 
hovers.) 

Does anybody else see the problem here? Someone needs to rethink this kind of 
behavior.

In the mean time, does anyone know how to undo this mess, or am I forced to go 
back to 2020-06?

Regards,
Greg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [eclipse.org-committers] Use Milestones/RCs To Test and Run

[Greg Watson]

Projects have enough on their plates testing their own code, let alone testing 
the platform. This seems to be a deficiency in the regression testing of the 
platform, and should be handled by the platform team IMHO.

Greg

> On Dec 13, 2019, at 5:23 AM, Daniel Megert  wrote:
> 
> It would be great if everyone could at least test or even better, run on the 
> latest milestone/RC. Platform got a stop ship bug for 4.13 and one for 4.14 
> reported after RC2. The 4.13 bug was introduced in M3 and the 4.14 bug in M1. 
> So, there would have been enough room to find the bugs earlier.
> 
> Of course the Platform team does exactly that but everyone has its own 
> patterns how to work and hence, unfortunately did not detect those bugs.
> 
> Thanks to everyone who helps with testing!
> Dani
> ___
> eclipse.org-committers mailing list
> eclipse.org-committ...@eclipse.org
> https://www.eclipse.org/mailman/listinfo/eclipse.org-committers
> 
> IMPORTANT: Membership in this list is generated by processes internal to the 
> Eclipse Foundation.  To be permanently removed from this list, you must 
> contact e...@eclipse.org to request removal.

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Installer Enhancements for 2019-12 / Making Marketplace Great Again

[Greg Watson]

Hi Ed,

I didn’t see that screen at all, but even if I did, I probably wouldn’t have 
entered anything as it’s not clear that you need to. Just to check, I 
re-downloaded the installer and tried again. This time I saw a completely 
different screen that asks for my Eclipse git/gerrit user ID and doesn’t let me 
proceed until I’ve entered one. That is a lot cleaner than the variables 
screen, since it’s not possible to proceed until you’ve entered a sensible 
value. Something seems to have changed since yesterday however.

Thanks,
Greg

> On Dec 11, 2019, at 1:21 AM, Ed Merks  wrote:
> 
> Greg,
> 
> Thanks for trying it!  You didn't feel compelled to change any of the values, 
> not even the "anonymous" ones?  :-P
> 
> For a new installer user, the installer looks like this after applying the 
> configuration: 
> 
> 
> 
> The last variable must be your user ID, i.e., the one for which you have ssh 
> keys registered.  
> 
> Note that if you're not a new installer user, most of these variables will 
> have been saved and are not displayed unless you check mark the "Show all 
> variables" checkbox.  Likely you will need to check mark that to change your 
> previous "anonymous" choice to your actual user ID.  You can even do this in 
> your existing installation where cloning failed via Help -> Perform Setup 
> Tasks, hitting the back button, checking the Show all variables, and changing 
> the value.
> 
> In a typical setup, an anonymous read-only https URI is used for the clone, 
> in which case no ID is prompted.  This is good for new users who will only 
> need read access.  But I specialized the simrel setup to default to ssh 
> because this setup is generally only useful for committers who will of course 
> need read/write access and likely have ssh configured long ago; they need 
> only enter their correct ID.
> 
> To ensure that committers actually enter their ID, I've changed the setup so 
> it comes up like this,  i.e., so even if you are compelled to quickly hit 
> next without reviewing any of the choices presented to you, you can't hit 
> next until you enter an ID:
> 
> 
> 
> As an example, I change the variables to the following to also enable the 
> read/write access to Mylyn's Bugzilla/Gerrit integration:
> 
> 
> 
> And I use the Authenticate button to ensure that I've entered the right 
> password.
> 
> I've also updated the configuration's documentation so it includes details 
> about this including a link to https://wiki.eclipse.org/Gerrit#SSH_Keys 
> <https://wiki.eclipse.org/Gerrit#SSH_Keys>
> 
>> The default Git repository URI uses ssh so you must specify your user ID for 
>> which you've registered your SSH keys 
>> <https://wiki.eclipse.org/Gerrit#SSH_Keys> to use this choice. To exploit 
>> the Mylyn Bugzilla integration, you should enter the email address of your 
>> Eclipse account and enter your password for that account. You can use the 
>> Authenticate... button to ensure you've entered it correctly.
> 
> The unfortunate exceptions you see are detailed in this Bugzilla:
> 
>   https://bugs.eclipse.org/bugs/show_bug.cgi?id=548640 
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=548640>
> 
> It's assigned to the platform, but no fix has been committed.  As I detailed 
> in this comment, it looks to me like a Mylyn problem and that the subsequent 
> platform exceptions are the result of the initial Mylyn exception:
> 
>   https://bugs.eclipse.org/bugs/show_bug.cgi?id=548640#c10 
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=548640#c10>
> 
> I think the platform is only focused on avoid their exception, but not the 
> underlying Mylyn problem.  In any case, there has been no response to my 
> comment.  In any case, his problem has been happening for quite a long time, 
> but only appears to happen in a brand new workspace.  For a subsequent 
> restart, the Mylyn task view initializes properly.
> 
> Finally, notice how easy it is to attribute all problems to the thing you 
> started with.  Users think the installer (or p2) is stupid because it prompts 
> for multiple copies of the same license, but the licenses come from the 
> things being installed.   Even with these exceptions in the Mylyn and the 
> workbench, the initial assumption is likely that it's the installers fault, 
> but of course the installer also doesn't create the bundles. 
> 
> This is why I'm concerned about all the general issues because users will 
> blame everything on Eclipse.  Even when they get the content from a 
> marketplace listing and that listing is broken, it will be perceived as 
> Eclipse's fault, and if the install successfully fetches the bundles from 
> some

Re: [cross-project-issues-dev] Installer Enhancements for 2019-12 / Making Marketplace Great Again

[Greg Watson]

I tried installing the Simrel IDE (on macOS). When I run it, I get four errors 
from org.eclipse.e4.ui.workbench, including two 
ConcurrentModificationExceptions from SWT and a NullPointerException from 
mylyn, a warning from oomph.setup.core 
"org.eclipse.jgit.api.errors.TransportException: 
ssh://anonym...@git.eclipse.org:29418/simrel/org.eclipse.simrel.build: No more 
authentication methods available” a conflicting keybinding warning, and two 
warnings from org.eclipse.emf.ecore about conflicting registrations.

Greg

> On Dec 10, 2019, at 6:12 AM, Ed Merks  wrote:
> 
> Hi,
> 
> On a more positive note, for the 2019-12 release, the installer exploits the 
> platform's cool "link handler" support that was implemented by Matthias 
> Becker; thanks Lars Vogel for drawing my attention to this gem.
> 
> As an example, this means that clicking the following link can automatically 
> launch the installer, in this case, initializing it in order to provision a 
> specialized IDE for contributing to SimRel.
> 
>   
> eclipse+installer:https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/interim/SimultaneousReleaseTrainConfiguration.setup
>  
> https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/interim/SimultaneousReleaseTrainConfiguration.setup>
> It's kind of a chicken-and-egg problem that you must first download and 
> register the installer once.  To make this step more  self-documenting, I've 
> created a "help" page that describes how to exploit this feature:
> 
>   
> https://www.eclipse.org/setups/installer/?url=https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/interim/SimultaneousReleaseTrainConfiguration.setup=true
>  
> 
> This page uses the documentation extracted from the configuration (specified 
> in the query parameter) so that it's contextually tailored, including all its 
> links.
> 
> I've updated the simrel wiki to describe this automated approach to set up an 
> environment for contributing to simrel:
> 
>   
> https://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build#Get_the_simrel.build_project
>  
> 
> So there isn't really a good excuse not to use the aggregation editor.  
> Admitted I too typically just edit my *.aggrcon files actually, but mostly 
> because saving creates such a big delta.  But the editor does have 
> advantages, i.e., I can see if I pasted the URL incorrectly and that the  IUs 
> resolve correctly.   More importantly, as I mentioned previously, if you're 
> adding a feature that needs to be in a category or removing a feature when it 
> or any other feature after it are in a category, you will break the model if 
> you do this textually.  And there were many such broken links as a result...
> 
> This same mechanism can be used to provision a development environment with 
> the source for the full Platform SDK:
> 
>  
> https://www.eclipse.org/setups/installer/?url=https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/interim/PlatformSDKConfiguration.setup=true
>  
> 
> You can do this for your own projects too.  One-click contributions from your 
> community are at you finger tips.
> 
> In addition, this same mechanism can also be used to install marketplace 
> listings, e.g.,
> 
>   
> https://www.eclipse.org/setups/installer/?url=https://marketplace.eclipse.org/content/wild-web-developer-html-css-javascript-typescript-nodejs-angular-json-yaml-kubernetes-xml=true
>  
> 
> So the installer now allows users to create an installation that includes one 
> more additional marketplace listings as well.
> 
> To help make the marketplace listings great again, the listings are now 
> tested daily.  Bad listings give a bad impression of Eclipse, especially when 
> we provide them ourselves.
> 
> Currently there are 1316 marketplace listings that specify update sites.  Of 
> those, 541 have problems; some have minor problems, e.g.,  it can't be 
> installed in the versions of Eclipse with which it's specified to be 
> compatible, but many have major problems, i.e., the p2 site doesn't exist or 
> doesn't contain the bundles/features that are required by the listing. The 
> user perception is that anything they get from marketplace is "Eclipse" and 
> any problem with those are "Eclipse" problems...  
> 
> If you maintain a listing, you can review the test results for your listing 
> as follows:
> 
>   

Re: [cross-project-issues-dev] Do You Constantly Need to Login?

[Greg Watson]

Constantly.

> On Dec 4, 2019, at 10:24 AM, Denis Roy  
> wrote:
> 
> I have to log in once in a while -- but no differently from other sites
> I use. I tend to be "forgotten" from all sites at the same time
> (including non-eclipse), so I think it could be my browser intentionally
> purging cookies or something.
> 
> The Cookie Consent banner is shown, if I'm not mistaken, every 30 days
> and it's tied to the domain. If you accept it on Eclipse.org it will
> stick on wiki.eclipse.org but won't stick on eclipsecon.org or
> jakarta.ee, for instance, even though they are both known as Eclipse web
> properties.
> 
> 
> Denis
> 
> 
> 
> On 2019-12-04 12:09 a.m., Ed Merks wrote:
>> I don't know if it's just me, or because of some Firefox issue, or
>> because of some changes to the Eclipse infrastructure, but I find that
>> I often/constantly need to login when I navigate to a Bugzilla,
>> navigate to a Forum, or navigate to a CI instance.
>> 
>> Particularly with the Forum, it shows me needing to login, but when I
>> do that it navigates me to this page:
>> 
>>   https://www.eclipse.org/forums/index.php/re/
>> 
>> And then I have to go back and refresh the Forum page that I was on
>> before.  It's rather annoying!
>> 
>> Bugzilla seems to remember my login a little longer, but it too often
>> requires a new login as well...
>> 
>> Is anyone else encountering such problems?
>> 
>> Regards,
>> Ed
>> 
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To change your delivery options, retrieve your password, or
>> unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Making SimRel Great Again

[Greg Watson]

Voluntary is good up to a point, and by all means give projects the chance to 
fix the issues before taking action. However if projects are not complying, 
then at some point you need to say that the quality of the release is more 
important. Now that the release cycle is more frequent, there could be a limit 
of N releases (e.g. N=2) for non-conforming projects, then they are excluded.

Regards,
Greg

> On Nov 18, 2019, at 9:18 AM, Karsten Thoms  wrote:
> 
> I don’t think that excluding these projects would be a wise choice. Then 
> immediately a large set of project had to leave SimRel, and clients are used 
> to find many of them in the SimRel.
> Of course the projects that are failing to fulfil the required constraints 
> should know that they have to do something to do. For me the right point 
> would be the SimRel aggregation validation build. If there could be more 
> checks performed there the contributing projects will immediately recognise a 
> task when they can’t get a successful build when contributing to SimRel. 
> These restrictions could be added one by one, starting with most urgent ones, 
> e.g. invalid license, missing signing.
> 
> ~Karsten
> 
>> Am 18.11.2019 um 15:02 schrieb Greg Watson > <mailto:g.wat...@computer.org>>:
>> 
>> Hi Ed,
>> 
>> Thanks for your effort to try to improve the quality of the simrel. I was 
>> wondering why we don’t simply exclude all non conforming projects from the 
>> simrel until these issues have been corrected? This would seem to be 
>> particularly important for projects contributing content that is signed with 
>> expired certificates. Also, as far as I can see, the Simultaneous Release 
>> Requirements page [1] does not go to the level of detail that your email is 
>> suggesting, so it would be good to update this with more specific 
>> requirements, such as with version of Orbit projects should be building 
>> with. Ideally however, these requirements would be checked automatically and 
>> the project excluded if non conforming.
>> 
>> Regards,
>> Greg
>> 
>> [1] https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements 
>> <https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements>
>> 
>>> On Nov 18, 2019, at 4:57 AM, Ed Merks >> <mailto:ed.me...@gmail.com>> wrote:
>>> 
>>> SimRel Participants,
>>> 
>>> While we're making progress on improving the state of the SimRel repo for 
>>> 2019-12, without the active involvement of the ~80 teams contributing 
>>> content, we're still going to fall far short of an acceptable quality 
>>> benchmark.
>>> 
>>> Many projects simply need to do a new build to use the proper and correct 
>>> version of SUA 2.0 from CBI and to use the latest Orbit dependencies.  
>>> 
>>> Roland Grunberg has been kind enough to publish a new Orbit I-build to 
>>> ensure that there are no bundles signed  with expired root certificates:
>>> 
>>>   https://bugs.eclipse.org/bugs/show_bug.cgi?id=552251 
>>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=552251>
>>> The Orbit dependencies that you contribute to the train should come from 
>>> there, and not some antiquated older version.  You should also look closely 
>>> at whether your contributed or Orbit dependencies  align those contributed 
>>> by other projects.  Currently 55 bundles are contributed as duplicates 
>>> which is something we ought to avoid.  But at this point, duplicates is the 
>>> least of my concern.  Just don't contribute old versions of 
>>> com.google.inject.assistedinject_3.0.0.v201402270930 and 
>>> org.antlr.runtime_3.0.0.v200803061811.
>>> 
>>> That mean the ATL teams needs to pay attention
>>> 
>>> https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/staging/2019-12/index/org.eclipse.m2m.atl.dsls_4.1.0.v201909021645.html#osgi.bundle;_org.antlr.runtime_
>>>  
>>> <https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/staging/2019-12/index/org.eclipse.m2m.atl.dsls_4.1.0.v201909021645.html#osgi.bundle;_org.antlr.runtime_>[3.0.0,3.1.0)
>>> 
>>> Also the GEF team:
>>> 
>>> https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/staging/2019-12/index/org.eclipse.gef.mvc.fx.ui_5.1.1.201910161621.html#java.package;_com.google.inject.assistedinject_
>>>  
>>> <https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/staging/2019-12/index/org.eclipse.gef.mvc.fx.ui_5.1.1.201910161621.html#java.package;_com.google.inject.assistedinjec

Re: [cross-project-issues-dev] Making SimRel Great Again

[Greg Watson]

Hi Ed,

Thanks for your effort to try to improve the quality of the simrel. I was 
wondering why we don’t simply exclude all non conforming projects from the 
simrel until these issues have been corrected? This would seem to be 
particularly important for projects contributing content that is signed with 
expired certificates. Also, as far as I can see, the Simultaneous Release 
Requirements page [1] does not go to the level of detail that your email is 
suggesting, so it would be good to update this with more specific requirements, 
such as with version of Orbit projects should be building with. Ideally 
however, these requirements would be checked automatically and the project 
excluded if non conforming.

Regards,
Greg

[1] https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements

> On Nov 18, 2019, at 4:57 AM, Ed Merks  wrote:
> 
> SimRel Participants,
> 
> While we're making progress on improving the state of the SimRel repo for 
> 2019-12, without the active involvement of the ~80 teams contributing 
> content, we're still going to fall far short of an acceptable quality 
> benchmark.
> 
> Many projects simply need to do a new build to use the proper and correct 
> version of SUA 2.0 from CBI and to use the latest Orbit dependencies.  
> 
> Roland Grunberg has been kind enough to publish a new Orbit I-build to ensure 
> that there are no bundles signed  with expired root certificates:
> 
>   https://bugs.eclipse.org/bugs/show_bug.cgi?id=552251 
> 
> The Orbit dependencies that you contribute to the train should come from 
> there, and not some antiquated older version.  You should also look closely 
> at whether your contributed or Orbit dependencies  align those contributed by 
> other projects.  Currently 55 bundles are contributed as duplicates which is 
> something we ought to avoid.  But at this point, duplicates is the least of 
> my concern.  Just don't contribute old versions of 
> com.google.inject.assistedinject_3.0.0.v201402270930 and 
> org.antlr.runtime_3.0.0.v200803061811.
> 
> That mean the ATL teams needs to pay attention
> 
> https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/staging/2019-12/index/org.eclipse.m2m.atl.dsls_4.1.0.v201909021645.html#osgi.bundle;_org.antlr.runtime_
>  
> [3.0.0,3.1.0)
> 
> Also the GEF team:
> 
> https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/staging/2019-12/index/org.eclipse.gef.mvc.fx.ui_5.1.1.201910161621.html#java.package;_com.google.inject.assistedinject_
>  
> [1.3.0,1.4.0)
> 
> These dependency ranges will force the old problematic version.
> 
> What concerns me most is that some teams are completely unresponsive:
> 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=551591 
> 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=551550 
> 
> So it heartens me to see  others who have taken active steps:
> 
> https://github.com/eclipse/eclipse-collections/issues/763 
> 
> Out of respect for all those many active participants who work tirelessly to 
> contribute high quality results, please consider that your inaction reflects 
> poorly on all of us.  In the end, the user doesn't care or know where things 
> come from, they are faced with dialogs displaying many "duplicate" licenses, 
> they see dialogs asking them to accept expired (root) certificates, and 
> dialogs to accept the installation of  unsigned content.   It just doesn't 
> give the user a warm fuzzy feeling that they're about to install something 
> really great and that undermines the effort of hundreds of us who are working 
> hard to give a great first impression and well as a lasting good impression.
> 
> This is is the future state for M3 if no further action is taken:
> 
>   
> https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/staging/2019-12/index.html
>  
> 
> That state is a result of your contributions:
> 
>  https://download.eclipse.org/oomph/archive/simrel/ 
> 
> I believe there are a significant number of contributions that have simply 
> died long ago but their input lingers on in a limbo zombie state.  Those will 
> need to be removed...  And when one sees contributions coming from 
> archive.eclipse.org, or with neon, oxygen, and photon in the name, or ending 
> with 

Re: [cross-project-issues-dev] The end of an era: shell access.

[Greg Watson]

I would like to thank Jonah Graham for helping us to overcome this restriction 
imposed on us by the Foundation. Thanks Jonah!

Greg

> On Jul 5, 2019, at 9:43 AM, Greg Watson  wrote:
> 
> I will also add that I’ve had shell access to build.eclipse.org 
> <http://build.eclipse.org/> for release engineering for something like 15 
> years, so this would affect me to the extent that I would be dropping support 
> for the PTP project. If the foundation wants to do this then it should be 
> providing a generic automated release process that all projects use, and in 
> the interim provide the resources to convert manual release processes to 
> CI-driven ones. If they do this, then I might reconsider, but it would depend 
> on how difficult things become. 
> 
> Regards,
> Greg
> 
>> On Jul 4, 2019, at 3:49 PM, Eclipse Webmaster 
>> mailto:webmas...@eclipse-foundation.org>> 
>> wrote:
>> 
>> Hi Everyone,
>> 
>>   As some of you may know we have traditionally provided a limited set of 
>> committers with shell access to build.eclipse.org 
>> <http://build.eclipse.org/>, and all other committers having restricted 
>> shells.
>> 
>> For the last couple of years[1][2] we've been working to reduce that number 
>> as far as possible, and the time has come to finish the process.
>> 
>> Effective August 28th 2019 we will be transitioning all committers that 
>> still have a regular shell to our restricted shell.  You will still be able 
>> to use SFTP and SCP to interact with the downloads and archive areas(but we 
>> suggest a job on your Eclipse CI instance!)
>> 
>> If you have any questions or concerns please feel free to contact Webmaster.
>> 
>> -Matt.
>> 
>> [1] https://www.eclipse.org/lists/cross-project-issues-dev/msg06625.html 
>> <https://www.eclipse.org/lists/cross-project-issues-dev/msg06625.html>
>> [2] https://www.eclipse.org/lists/eclipse.org-committers/msg01075.html 
>> <https://www.eclipse.org/lists/eclipse.org-committers/msg01075.html>___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org 
>> <mailto:cross-project-issues-dev@eclipse.org>
>> To change your delivery options, retrieve your password, or unsubscribe from 
>> this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] The end of an era: shell access.

[Greg Watson]

I will also add that I’ve had shell access to build.eclipse.org for release 
engineering for something like 15 years, so this would affect me to the extent 
that I would be dropping support for the PTP project. If the foundation wants 
to do this then it should be providing a generic automated release process that 
all projects use, and in the interim provide the resources to convert manual 
release processes to CI-driven ones. If they do this, then I might reconsider, 
but it would depend on how difficult things become. 

Regards,
Greg

> On Jul 4, 2019, at 3:49 PM, Eclipse Webmaster 
>  wrote:
> 
> Hi Everyone,
> 
>   As some of you may know we have traditionally provided a limited set of 
> committers with shell access to build.eclipse.org 
> , and all other committers having restricted 
> shells.
> 
> For the last couple of years[1][2] we've been working to reduce that number 
> as far as possible, and the time has come to finish the process.
> 
> Effective August 28th 2019 we will be transitioning all committers that still 
> have a regular shell to our restricted shell.  You will still be able to use 
> SFTP and SCP to interact with the downloads and archive areas(but we suggest 
> a job on your Eclipse CI instance!)
> 
> If you have any questions or concerns please feel free to contact Webmaster.
> 
> -Matt.
> 
> [1] https://www.eclipse.org/lists/cross-project-issues-dev/msg06625.html 
> 
> [2] https://www.eclipse.org/lists/eclipse.org-committers/msg01075.html 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] SimRel 2019-06 Release Candidate 2 (RC2) staging repo is complete

[Greg Watson]

I can live without it :-)

I agree with Doug though, it should probably be better documented when the last 
contribution can be made. Since the iterations come so frequently now, it’s 
hard to keep up with where we are in a cycle.

Regards,
Greg

> On Jun 13, 2019, at 12:10 PM, Doug Schaefer  wrote:
> 
> If that's the rule, it should really be captured here:
> 
> https://wiki.eclipse.org/SimRel/2019-06/Simultaneous_Release_Plan 
> <https://wiki.eclipse.org/SimRel/2019-06/Simultaneous_Release_Plan>
> 
> Also interesting that the GA date keeps getting earlier. We're in mid-June 
> territory now...
> 
> Doug.
> 
> 
> From: cross-project-issues-dev-boun...@eclipse.org 
> <mailto:cross-project-issues-dev-boun...@eclipse.org> 
> [cross-project-issues-dev-boun...@eclipse.org 
> <mailto:cross-project-issues-dev-boun...@eclipse.org>] on behalf of Frederic 
> Gurr [frederic.g...@eclipse-foundation.org 
> <mailto:frederic.g...@eclipse-foundation.org>]
> Sent: Thursday, June 13, 2019 12:04 PM
> To: cross-project-issues-dev@eclipse.org 
> <mailto:cross-project-issues-dev@eclipse.org>
> Subject: Re: [cross-project-issues-dev] SimRel 2019-06 Release Candidate 2 
> (RC2) staging repo is complete
> 
> Hi,
> 
> The quiet period officially starts tomorrow, but the EPP build is always
> on a Thursday. Unfortunately, last minute contributions have started to
> bleed into Thursday for a while now, even though they should be done by
> Wednesday EOB.
> 
> Are you okay with leaving out that change?
> 
> Regards,
> 
> Fred
> 
> On 13.06.19 17:58, Greg Watson wrote:
>> No, not critical, but I thought tomorrow was the start of the RC2 quiet 
>> period?
>> 
>> Greg
>> 
>>> On Jun 13, 2019, at 11:45 AM, Frederic Gurr 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> Is this a critical fix?
>>> 
>>> Regards,
>>> 
>>> Fred
>>> 
>>> On 13.06.19 16:24, Greg Watson wrote:
>>>> I have an update that only went into the build today because a previous 
>>>> Gerrit changeset was never validated. Is it possible to run the 
>>>> aggregation again today? Sorry for the last minute issue.
>>>> 
>>>> Thanks,
>>>> Greg
>>>> 
>>>>> On Jun 13, 2019, at 9:43 AM, Frederic Gurr 
>>>>>  wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> Since the SimRel aggregator build is quiet, I declare the staging repo
>>>>> for 2019-06 RC2 to be complete.
>>>>> 
>>>>> As usual, it can be found here:
>>>>> 
>>>>> => 
>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__download.eclipse.org_staging_2019-2D06_=DwICAg=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE=NrrbvTHWa2Nbp_kAN0Hl1o3lM1WAwSes64uBjxjNhMc=Kxo5hO9B2vR-RsF79RhPB4XXe9-ohDFoJvX3O40qggU=yyVFt7Kg-duKjZ89Yo9TCo-e3CcfHTVh4J9mMbNFX0M=
>>>>>  
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__download.eclipse.org_staging_2019-2D06_=DwICAg=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE=NrrbvTHWa2Nbp_kAN0Hl1o3lM1WAwSes64uBjxjNhMc=Kxo5hO9B2vR-RsF79RhPB4XXe9-ohDFoJvX3O40qggU=yyVFt7Kg-duKjZ89Yo9TCo-e3CcfHTVh4J9mMbNFX0M=>
>>>>> 
>>>>> Please note, we will enter quiet days for 2019-06. If no blocking
>>>>> issues are found, RC2 will become the official 2019-06 release on
>>>>> Wednesday, June 19th.
>>>>> 
>>>>> Thanks for all your contributions and happy _quiet_ days!
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Fred
>>>>> 
>>>>> 
>>> 
>>> --
>>> Frederic Gurr
>>> Release Engineer | Eclipse Foundation Europe GmbH
>>> 
>>> Annastr. 46, D-64673 Zwingenberg
>>> Handelsregister: Darmstadt HRB 92821
>>> Managing Directors: Ralph Mueller, Mike Milinkovich, Chris Laroque
>>> ___
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@eclipse.org 
>>> <mailto:cross-project-issues-dev@eclipse.org>
>>> To change your delivery options, retrieve your password, or unsubscribe 
>>> from this list, visit
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.eclipse.org_mailman_listinfo_cross-2Dproject-2Dissues-2Ddev=DwICAg=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE=NrrbvTHWa2Nbp_kAN0Hl1o3lM1WAwSes64uBjxjNhMc=Kxo5hO9B2vR-RsF79RhPB4XXe9-ohDFoJvX3O4

Re: [cross-project-issues-dev] SimRel 2019-06 Release Candidate 2 (RC2) staging repo is complete

[Greg Watson]

No, not critical, but I thought tomorrow was the start of the RC2 quiet period?

Greg

> On Jun 13, 2019, at 11:45 AM, Frederic Gurr 
>  wrote:
> 
> Hi,
> 
> Is this a critical fix?
> 
> Regards,
> 
> Fred
> 
> On 13.06.19 16:24, Greg Watson wrote:
>> I have an update that only went into the build today because a previous 
>> Gerrit changeset was never validated. Is it possible to run the aggregation 
>> again today? Sorry for the last minute issue.
>> 
>> Thanks,
>> Greg
>> 
>>> On Jun 13, 2019, at 9:43 AM, Frederic Gurr 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> Since the SimRel aggregator build is quiet, I declare the staging repo
>>> for 2019-06 RC2 to be complete.
>>> 
>>> As usual, it can be found here:
>>> 
>>> => http://download.eclipse.org/staging/2019-06/
>>> 
>>> Please note, we will enter quiet days for 2019-06. If no blocking
>>> issues are found, RC2 will become the official 2019-06 release on
>>> Wednesday, June 19th.
>>> 
>>> Thanks for all your contributions and happy _quiet_ days!
>>> 
>>> Regards,
>>> 
>>> Fred
>>> 
>>> 
> 
> -- 
> Frederic Gurr
> Release Engineer | Eclipse Foundation Europe GmbH
> 
> Annastr. 46, D-64673 Zwingenberg
> Handelsregister: Darmstadt HRB 92821
> Managing Directors: Ralph Mueller, Mike Milinkovich, Chris Laroque
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] SimRel 2019-06 Release Candidate 2 (RC2) staging repo is complete

[Greg Watson]

I have an update that only went into the build today because a previous Gerrit 
changeset was never validated. Is it possible to run the aggregation again 
today? Sorry for the last minute issue.

Thanks,
Greg

> On Jun 13, 2019, at 9:43 AM, Frederic Gurr 
>  wrote:
> 
> Hi,
> 
> Since the SimRel aggregator build is quiet, I declare the staging repo
> for 2019-06 RC2 to be complete.
> 
> As usual, it can be found here:
> 
> => http://download.eclipse.org/staging/2019-06/
> 
> Please note, we will enter quiet days for 2019-06. If no blocking
> issues are found, RC2 will become the official 2019-06 release on
> Wednesday, June 19th.
> 
> Thanks for all your contributions and happy _quiet_ days!
> 
> Regards,
> 
> Fred
> 
> 
> -- 
> Frederic Gurr
> Release Engineer | Eclipse Foundation Europe GmbH
> 
> Annastr. 44, D-64673 Zwingenberg
> Handelsregister: Darmstadt HRB 92821
> Managing Directors: Ralph Mueller, Mike Milinkovich, Chris Laroque
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Problems with dependencies in Eclipse for Testers (Jubula)

[Greg Watson]

PTP is having the same problem that CDT was having, namely that javax.xml.bind 
has been removed from Java 11 so running with that JVM or later causes problem. 
Rather than every project that has this problem having to create a solution, is 
there some way this could be done via the platform?

Thanks,
Greg

> On Jun 3, 2019, at 10:05 AM, Jonah Graham  wrote:
> 
> Hi Marvin,
> 
> There was a bunch of last minute work on 2018-12 release that had similar 
> underlying issues relating to resolution problems around javax.xml.bind. I 
> think there were a number of solutions put forward, but I can point you at 
> what CDT did to resolve the issues:
> 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=536316 
>  and some related 
> commits:
> https://git.eclipse.org/r/#/c/133828/ 
> 
> This may not be the same issue you are facing, but hopefully it points you in 
> a useful direction.
> 
> Thanks
> Jonah
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com 
> 
> 
> On Mon, 3 Jun 2019 at 09:55, Marvin Mueller  > wrote:
> Hello,
> 
>  
> 
> The Jubula part of eclipse for testers is not running at this moment[1] since 
> javax.xml.bind is pulled into the eclipse. The dependency resolution now find 
> multiple exposed packages for “javax.xml.bind”( Uses constraint violation… 
> because it is exposed to package
> 'javax.xml.bind' from resources org.eclipse.osgi and javax.xml.bind) This 
> error did not occur in M2 and I am unsure why javax.xml.bind bundle is now 
> pulled into the eclipse. I assume it has to do with java 11.
>  
> My solution would be to exclude the javax.xml.bind to be excluded from 
> pulling like it was done before for javax.transaction. But I am unsure if 
> this may help.
> Is there any way, that I can get this to run? Any help would be appreciated.
>  
>  
> 
> Thanks and best regards
> 
> Marvin Mueller
> 
>  
> 
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=547865 
> 
> 
>  
> BREDEX GmbH
> Lindentwete 1
> 38100 Braunschweig
> 
> Tel.: +49 531 24330-0
> Fax: +49 531 24330-99
> 
> 
> Geschäftsführer: Andreas Vogel, Ulrich Obst, Achim Lörke
> Amtsgericht Braunschweig HRB 2450
> 
> www.bredex.de 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org 
> 
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Is jsch finally dead?

[Greg Watson]

there is not a public repository,
> and we will accept bug reports at jsch-users mailing list.
> We hesitate to accept source code due to the license violation concerns.
> 
> 
> Sincerely,
> --
> Atsuhiko Yamanaka
> JCraft,Inc.
> <-- address data redacted -->
>  
> -- Forwarded message -
> From: Matthias Sohn mailto:matthias.s...@gmail.com>>
> Date: Thu, Nov 29, 2018 at 1:09 AM
> Subject: jsch maintenance and source code repository
> To: mailto:atsuhiko.yaman...@gmail.com>>
> Cc: Thomas Wolf mailto:thomas.w...@paranor.ch>>
>   
> Hi Atsuhiko, 
>  
> I noticed that a new version of jsch 0.1.55 [1] was deployed on Maven 
> central, looks like you are back ?
>  
> We missed you at Eclipse [2] and came to the impression that jsch is no 
> longer maintained.
> I tried several times in the last 2 years to reach you or your company to 
> clarify if jsch is still
> maintained since it's not a good situation to depend on a security relevant 
> library which is
> no longer maintained. 
>  
> During the last 2 years we implemented a number of workarounds in JGit to 
> workaround
> bugs in jsch.
>  
> Since we didn't get any response for all emails sent to you and your company
> and there was no activity in the jsch sourceforge project we discussed if we 
> should fork jsch
> in order to continue maintenance. But then we couldn't find a source code 
> repository for jsch
> with the jsch source code history and we also couldn't find unit tests. Hence 
> Thomas created
> an alternative implementation for JGit using Apache mina-sshd [2]. The next 
> version JGit 5.2
> to be released before Christmas will come with both the jsch and the new 
> mina-sshd based
> implementation.
>  
> Could you let us know
> - if you intend to continue maintaining jsch
> - where we can find the source code repository
> - if and how you accept contributions for jsch
>  
> [1] https://search.maven.org/artifact/com.jcraft/jsch/0.1.55/jar 
> <https://search.maven.org/artifact/com.jcraft/jsch/0.1.55/jar>
> http://www.jcraft.com/jsch/ <http://www.jcraft.com/jsch/>
> http://www.jcraft.com/jsch/ChangeLog <http://www.jcraft.com/jsch/ChangeLog>
> [2] https://www.eclipse.org/lists/cross-project-issues-dev/msg16175.html 
> <https://www.eclipse.org/lists/cross-project-issues-dev/msg16175.html>
> [3] https://www.eclipse.org/lists/egit-dev/msg04556.html 
> <https://www.eclipse.org/lists/egit-dev/msg04556.html>
>  
> -Matthias
>   
> On Fri, Nov 2, 2018 at 4:29 PM Mat Booth  <mailto:mat.bo...@redhat.com>> wrote:
> I filed a bug against Equinox too. It could also be updated to consume the 
> latest version of org.apache.sshd: 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=540728 
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=540728>
>   
> On Fri, 2 Nov 2018 at 14:47, Greg Watson  <mailto:g.wat...@computer.org>> wrote:
> I've opened a bug against Platform/Team (since this seems to be where jsch 
> resides) [1]. It seems like EGit's Apache Mina work might be a good starting 
> point. 
>   
> Regards,
> Greg 
>  
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=540727 
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=540727>
>   
> On Nov 2, 2018, at 8:16 AM, Matthias Sohn  <mailto:matthias.s...@gmail.com>> wrote:
>   
> Also see this earlier discussion [1] on this list. 
>  
> The biggest problem with jsch is that there seems to be no known public 
> source code repository containing
> the project's real source code history including tests.
> There are a couple of public jsch repositories [2] but they all seem to 
> contain just snapshots of
> source archives downloaded from Maven central. None of these repositories 
> contain any jsch tests.
> There are the source archives available on Maven Central [3]
> and zip archives uploaded on sourceforge [4].
> [1] https://www.eclipse.org/lists/cross-project-issues-dev/msg14979.html 
> <https://www.eclipse.org/lists/cross-project-issues-dev/msg14979.html>
> [2] https://github.com/is/jsch <https://github.com/is/jsch>
> https://github.com/vngx/vngx-jsch <https://github.com/vngx/vngx-jsch>
> https://github.com/rtyley/jsch <https://github.com/rtyley/jsch>
> https://github.com/ePaul/jsch-documentation 
> <https://github.com/ePaul/jsch-documentation>
> https://github.com/feiqitian/JSch <https://github.com/feiqitian/JSch>
> https://github.com/octo47/jsch <https://github.com/octo47/jsch>
> https://gitlab.com/farmboy0/jsch <https://gitlab.com/farmboy0/jsch>
> [3] https://search.maven.org/search?q=g:com.jcraft%20AND%20a:jsch=gav 
> <https://search.

Re: [cross-project-issues-dev] Is jsch finally dead?

[Greg Watson]

I've opened a bug against Platform/Team (since this seems to be where jsch 
resides) [1]. It seems like EGit's Apache Mina work might be a good starting 
point.

Regards,
Greg

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=540727

> On Nov 2, 2018, at 8:16 AM, Matthias Sohn  wrote:
> 
> Also see this earlier discussion [1] on this list.
> 
> The biggest problem with jsch is that there seems to be no known public 
> source code repository containing
> the project's real source code history including tests.
> There are a couple of public jsch repositories [2] but they all seem to 
> contain just snapshots of
> source archives downloaded from Maven central. None of these repositories 
> contain any jsch tests.
> There are the source archives available on Maven Central [3] 
> and zip archives uploaded on sourceforge [4].
> [1] https://www.eclipse.org/lists/cross-project-issues-dev/msg14979.html 
> <https://www.eclipse.org/lists/cross-project-issues-dev/msg14979.html>
> [2] https://github.com/is/jsch <https://github.com/is/jsch>
> https://github.com/vngx/vngx-jsch <https://github.com/vngx/vngx-jsch>
> https://github.com/rtyley/jsch <https://github.com/rtyley/jsch>
> https://github.com/ePaul/jsch-documentation 
> <https://github.com/ePaul/jsch-documentation>
> https://github.com/feiqitian/JSch <https://github.com/feiqitian/JSch>
> https://github.com/octo47/jsch <https://github.com/octo47/jsch>
> https://gitlab.com/farmboy0/jsch <https://gitlab.com/farmboy0/jsch>
> [3] https://search.maven.org/search?q=g:com.jcraft%20AND%20a:jsch=gav 
> <https://search.maven.org/search?q=g:com.jcraft%20AND%20a:jsch=gav>
> [4] https://sourceforge.net/projects/jsch/files/jsch/ 
> <https://sourceforge.net/projects/jsch/files/jsch/>
> 
> On Fri, Nov 2, 2018 at 12:22 PM Matthias Sohn  <mailto:matthias.s...@gmail.com>> wrote:
> I tried several times to reach the jsch maintainer and his company but never 
> got a response.
> We implemented a couple of workarounds around jsch bugs in JGit and are tired 
> to do so.
> 
> Hence Thomas Wolf started an alternative implementation for JGit and EGit 
> based on Apache Mina sshd.
> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=520927 
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=520927>
> 
> -Matthias
> 
> On Fri, Nov 2, 2018 at 12:05 PM Gunnar Wagenknecht  <mailto:gun...@wagenknecht.org>> wrote:
> It looks like. We use it in the IDE and in EGit.
> 
> See here:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=540652 
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=540652>
> 
> -Gunnar
> 
> -- 
> Gunnar Wagenknecht
> gun...@wagenknecht.org <mailto:gun...@wagenknecht.org>, http://guw.io/ 
> <http://guw.io/>
> 
> 
> 
> 
> 
> 
>> On Nov 2, 2018, at 02:19, Greg Watson > <mailto:g.wat...@computer.org>> wrote:
>> 
>> This question has been asked before, but I think it's time to ask it again. 
>> The last version of jsch was 0.1.54 in Sep 2016 and there doesn't seem to 
>> have been any development since then. Given the number of projects that 
>> depend on a decent ssh implementation, and the numerous bugs that still 
>> exist in jsch, what are the plans for maintaining and/or replacing it?
>> 
>> Thanks,
>> Greg
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org 
>> <mailto:cross-project-issues-dev@eclipse.org>
>> To change your delivery options, retrieve your password, or unsubscribe from 
>> this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>> <https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev>
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org 
> <mailto:cross-project-issues-dev@eclipse.org>
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev 
> <https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev>___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Is jsch finally dead?

[Greg Watson]

This question has been asked before, but I think it's time to ask it again. The 
last version of jsch was 0.1.54 in Sep 2016 and there doesn't seem to have been 
any development since then. Given the number of projects that depend on a 
decent ssh implementation, and the numerous bugs that still exist in jsch, what 
are the plans for maintaining and/or replacing it?

Thanks,
Greg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] parallel package

[Greg Watson]

Hi,

I'm planning to change the name of the parallel package to "Eclipse IDE for 
Scientific Computing". I've made the changes to the epp plugins but just wanted 
to let people know this is in the works in case something breaks.

Thanks,
Greg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] SimRel - TM contribution has been disabled

[Greg Watson]

I used your gmail address. The redhat one worked.

Regards,
Greg

> On Feb 13, 2018, at 11:07 AM, Nick Boldt <nickbo...@gmail.com> wrote:
> 
> Which address did you use? If nickbo...@gmail.com 
> <mailto:nickbo...@gmail.com>, that's the problem. If nbo...@redhat.com 
> <mailto:nbo...@redhat.com>, then a possible bug in the portal/nom process.
> 
> Nick
> 
> On Tue, Feb 13, 2018 at 10:19 AM, Greg Watson <g.wat...@computer.org 
> <mailto:g.wat...@computer.org>> wrote:
> Nick,
> 
> I merged the change you indicated, thanks.
> 
> I also tried to nominate you, but for some reason it says your email address 
> is not valid. The actual message is "The nominee field contains an invalid 
> user." I don't know if this is a bug in the nomination form, or you need to 
> be registered somewhere with Eclipse. Does anyone know?
> 
> Regards,
> Greg
> 
> 
>> On Feb 12, 2018, at 6:11 PM, Nick Boldt <nickbo...@gmail.com 
>> <mailto:nickbo...@gmail.com>> wrote:
>> 
>> Considering the list of open TM/RSE gerrits [1] include one that's a 1-line 
>> fix for JDK 9 support, and is 2 weeks old without feedback (I just posted a 
>> +1 on it)... Doug's right, there may be no one to receive my PRs to updated 
>> RSE to work with Photon.
>> 
>> [1] https://git.eclipse.org/r/p/tm/org.eclipse.tm 
>> <https://git.eclipse.org/r/p/tm/org.eclipse.tm>
>> 
>> I also commented on one that's over 5 years old and unmerged. That one and 
>> all those older I suspect should be abandoned as they can't (or shouldn't) 
>> be merged.
>> 
>> If Kaloyan, Lars or any past TM committers [2] want to vote me in, I'll 
>> clean up the open gerrits and get RSE building again in JIPP.
>> 
>> [2] https://projects.eclipse.org/projects/tools.tm/who 
>> <https://projects.eclipse.org/projects/tools.tm/who>
>> 
>> So... Who'd like to nominate me? :)
>> 
>> -- 
>> 
>> Nick Boldt :: http://nick.divbyzero.com <http://nick.divbyzero.com/>
>> FB, IG, Twitter, G+, LinkedIn, Freenode: @nickboldt 
>> WhatsApp: +57 311 530 2074 or +1 647 899 9879 <tel:(647)%20899-9879>
>> 
>> On Feb 12, 2018 10:16 AM, "Lars Vogel" <lars.vo...@vogella.com 
>> <mailto:lars.vo...@vogella.com>> wrote:
>> I suggest to nominate Nick as TM committer 
>> 
>> Am 12.02.2018 16:06 schrieb "Doug Schaefer" <dschae...@blackberry.com 
>> <mailto:dschae...@blackberry.com>>:
>> Nick, who specifically on that “team” do you think should get those changes 
>> in for you? To help, here is the commit log from the git repo.
>> 
>>  
>> 
>> http://git.eclipse.org/c/tm/org.eclipse.tm.git/log/ 
>> <http://git.eclipse.org/c/tm/org.eclipse.tm.git/log/>
>>  
>> 
>> Kaloyan Raev is the only active committer and from his note earlier in this 
>> chain, he has removed the dependency from the projects he works on.
>> 
>>  
>> 
>> We really need to be crystal clear at this point what the plan is.
>> 
>>  
>> 
>> Doug.
>> 
>>  
>> 
>> From: cross-project-issues-dev-boun...@eclipse.org 
>> <mailto:cross-project-issues-dev-boun...@eclipse.org> 
>> [mailto:cross-project-issues-dev-boun...@eclipse.org 
>> <mailto:cross-project-issues-dev-boun...@eclipse.org>] On Behalf Of Nick 
>> Boldt
>> Sent: Monday, February 12, 2018 9:49 AM
>> To: issues, Cross project <cross-project-issues-dev@eclipse.org 
>> <mailto:cross-project-issues-dev@eclipse.org>>
>> Subject: Re: [cross-project-issues-dev] SimRel - TM contribution has been 
>> disabled
>> 
>>  
>> 
>> AFAIK it's out.
>> 
>>  
>> 
>> But if I find time to submit the changes from my/Rob's github fork as gerrit 
>> review(s) back to the master fork on git.eclipse.org 
>> <http://git.eclipse.org/>, that team can evaluate it, merge it, and maybe 
>> decide they want to be included for M6. Then it'll be up to the Planning 
>> Council to approve the late addition.
>> 
>>  
>> 
>> At least that's my interpretation of the rules. EMO might have a different 
>> view. :)
>> 
>>  
>> 
>> Nick
>> 
>> -- 
>> 
>> Nick Boldt
>> Senior Software Engineer, RHCSA
>> Productization Lead :: JBoss Tools & Dev Studio
>> IM: @nickboldt / @nboldt / http://nick.divbyzero.com 
>> <http://nick.divbyzero.com/>
>> Sent from my Android phone
>> 
>>  
>> 
>> On Feb 8, 2018 11:29 AM, &quo

Re: [cross-project-issues-dev] SimRel - TM contribution has been disabled

[Greg Watson]

Nick,

I merged the change you indicated, thanks.

I also tried to nominate you, but for some reason it says your email address is 
not valid. The actual message is "The nominee field contains an invalid user." 
I don't know if this is a bug in the nomination form, or you need to be 
registered somewhere with Eclipse. Does anyone know?

Regards,
Greg

> On Feb 12, 2018, at 6:11 PM, Nick Boldt  wrote:
> 
> Considering the list of open TM/RSE gerrits [1] include one that's a 1-line 
> fix for JDK 9 support, and is 2 weeks old without feedback (I just posted a 
> +1 on it)... Doug's right, there may be no one to receive my PRs to updated 
> RSE to work with Photon.
> 
> [1] https://git.eclipse.org/r/p/tm/org.eclipse.tm 
> 
> 
> I also commented on one that's over 5 years old and unmerged. That one and 
> all those older I suspect should be abandoned as they can't (or shouldn't) be 
> merged.
> 
> If Kaloyan, Lars or any past TM committers [2] want to vote me in, I'll clean 
> up the open gerrits and get RSE building again in JIPP.
> 
> [2] https://projects.eclipse.org/projects/tools.tm/who 
> 
> 
> So... Who'd like to nominate me? :)
> 
> -- 
> 
> Nick Boldt :: http://nick.divbyzero.com 
> FB, IG, Twitter, G+, LinkedIn, Freenode: @nickboldt 
> WhatsApp: +57 311 530 2074 or +1 647 899 9879
> 
> 
> On Feb 12, 2018 10:16 AM, "Lars Vogel"  > wrote:
> I suggest to nominate Nick as TM committer 
> 
> Am 12.02.2018 16:06 schrieb "Doug Schaefer"  >:
> Nick, who specifically on that “team” do you think should get those changes 
> in for you? To help, here is the commit log from the git repo.
> 
>  
> 
> http://git.eclipse.org/c/tm/org.eclipse.tm.git/log/ 
> 
>  
> 
> Kaloyan Raev is the only active committer and from his note earlier in this 
> chain, he has removed the dependency from the projects he works on.
> 
>  
> 
> We really need to be crystal clear at this point what the plan is.
> 
>  
> 
> Doug.
> 
>  
> 
> From: cross-project-issues-dev-boun...@eclipse.org 
>  
> [mailto:cross-project-issues-dev-boun...@eclipse.org 
> ] On Behalf Of Nick Boldt
> Sent: Monday, February 12, 2018 9:49 AM
> To: issues, Cross project  >
> Subject: Re: [cross-project-issues-dev] SimRel - TM contribution has been 
> disabled
> 
>  
> 
> AFAIK it's out.
> 
>  
> 
> But if I find time to submit the changes from my/Rob's github fork as gerrit 
> review(s) back to the master fork on git.eclipse.org 
> , that team can evaluate it, merge it, and maybe 
> decide they want to be included for M6. Then it'll be up to the Planning 
> Council to approve the late addition.
> 
>  
> 
> At least that's my interpretation of the rules. EMO might have a different 
> view. :)
> 
>  
> 
> Nick
> 
> -- 
> 
> Nick Boldt
> Senior Software Engineer, RHCSA
> Productization Lead :: JBoss Tools & Dev Studio
> IM: @nickboldt / @nboldt / http://nick.divbyzero.com 
> 
> Sent from my Android phone
> 
>  
> 
> On Feb 8, 2018 11:29 AM, "Simon Bernard"  > wrote:
> 
> Hi,
> 
> Sry for the delay, I re-enabled LDT removing ldt.remote feature which depends 
> on RSE.
> So this should be ok for photon M6.
> 
> I'm a bit confuse. Will RSE be reintegrated or is  it officially and 
> definitely not part of Photon ?
> 
> Thx,
> 
> Simon
> 
> 
> Le 01/02/2018 à 12:22, Frederic Gurr a écrit :
> 
> Hi,
> 
> Thanks to Kaloyan, Dawid and Eugene for fixing and re-enabling the
> contributions of DLTK, PDT and TCF.
> 
> The only contribution missing is LDT.
> Since it's already past the +3 window, LDT will miss Photon M5.
> Hopefully they can rejoin for M6.
> 
> Regards,
> 
> Fred
> 
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org 
> 
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org 
> 
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
> 

Re: [cross-project-issues-dev] Many projects have not yet opted in to participate in Eclipse Photon

[Greg Watson]

I am not able to provide support TM or RSE for inclusion in Photon, but in any 
case when Terminal moves to CDT I think TM should be archived. If there is 
support for RSE then it should become a tools project in it's own right and a 
decision to join Photon made by the new project. 

I know Kaloyan was providing RSE support, and JBoss were also interested, so 
they should weigh in on this discussion.

Regards,
Greg

> On Dec 19, 2017, at 6:35 AM, Martin Oberhuber  
> wrote:
> 
> Regarding Target Management, IIRC there is a plan moving the Terminal to the 
> CDT.
> 
> But what about RSE?
> Some packages include it now (PHP, JEE, C/C++ as far as I know)...
> 
> I am a TM committer, but I can not personally support TM on the release train.
> 
> Martin
> 
> 
>> On 15 Dec 2017, at 21:01, Wayne Beaton > > wrote:
>> 
>> By way of background, we introduced the requirement that projects publicly 
>> state their intent to participate 
>> 
>>  in each release to ensure that everybody is actually paying attention. In 
>> the past, we've had to scramble to sort out last minute issues because 
>> (some) project teams hadn't engaged. Participation in the simultaneous 
>> release requires some ongoing investment of time and energy from those 
>> projects that join in.
>> 
>> The deadline for stating intent to join the Eclipse Photon simultaneous 
>> release is EOB today. After that, the rules state that projects must work 
>> through their PMC to have the Eclipse Planning Council grant an exception to 
>> join after the deadline. 
>> 
>> I am pretty confident, however, that if you state your intent on this list 
>> by mid-week next week, the Planning Council will accept it. Please, get this 
>> done.
>> 
>> Any project that has not declared an intent to participate will be removed 
>> from the aggregation build prior to the M5 release. I'll work with Fred and 
>> Mikael to deactivate builds early in the new year.
>> 
>> AFAICT, the following projects have not stated their intention to 
>> participate.
>> Eclipse EGerrit
>> Eclipse e(fx)clipse
>> Eclipse Parallel Tools Platform (PTP)
>> Eclipse Sapphire
>> Eclipse Sphinx
>> Eclipse Target Management
>> Eclipse Communication Framework
>> Eclipse XWT
>> Eclipse PMF
>> Eclipse Orion
>> Eclipse Accessibility Tools Framework
>> Eclipse ATL
>> Eclipse Subversive SVN Team Provider
>> Eclipse Data Tools Platform
>> If you represent one of these projects and have chosen not to participate, 
>> please let the group know.
>> 
>> If you're listed here in error, I apologise. Please send me a harshly worded 
>> note pointing out my omission.
>> 
>> I am working with the Eclipse Data Tools Platform, so we'll likely get that 
>> resolved shortly.
>> 
>> The Eclipse Subversive team has indicated that they can no longer support 
>> the project, so we're going to have to sort out what (if anything) to do 
>> about that.
>> 
>> Since I'm pretty sure that the Eclipse Packaging Project is paying attention 
>> (and I am a committer on the project), I've created a 4.8 release 
>>  at 
>> +4 (consider this the project's declaration of participation).
>> 
>> Thanks for your attention,
>> 
>> Wayne
>> -- 
>> Wayne Beaton
>> Director of Open Source Projects
>> The Eclipse Foundation
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org 
>> 
>> To change your delivery options, retrieve your password, or unsubscribe from 
>> this list, visit
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Many projects have not yet opted in to participate in Eclipse Photon

[Greg Watson]

PTP will be participating in Photon with release 9.2 offset +3. I presume the 
remote project will have been transferred to CDT by then.

Regards,
Greg


> On Dec 15, 2017, at 3:01 PM, Wayne Beaton 
>  > wrote:
> 
> By way of background, we introduced the requirement that projects publicly 
> state their intent to participate 
> 
>  in each release to ensure that everybody is actually paying attention. In 
> the past, we've had to scramble to sort out last minute issues because (some) 
> project teams hadn't engaged. Participation in the simultaneous release 
> requires some ongoing investment of time and energy from those projects that 
> join in.
> 
> The deadline for stating intent to join the Eclipse Photon simultaneous 
> release is EOB today. After that, the rules state that projects must work 
> through their PMC to have the Eclipse Planning Council grant an exception to 
> join after the deadline. 
> 
> I am pretty confident, however, that if you state your intent on this list by 
> mid-week next week, the Planning Council will accept it. Please, get this 
> done.
> 
> Any project that has not declared an intent to participate will be removed 
> from the aggregation build prior to the M5 release. I'll work with Fred and 
> Mikael to deactivate builds early in the new year.
> 
> AFAICT, the following projects have not stated their intention to participate.
> Eclipse EGerrit
> Eclipse e(fx)clipse
> Eclipse Parallel Tools Platform (PTP)
> Eclipse Sapphire
> Eclipse Sphinx
> Eclipse Target Management
> Eclipse Communication Framework
> Eclipse XWT
> Eclipse PMF
> Eclipse Orion
> Eclipse Accessibility Tools Framework
> Eclipse ATL
> Eclipse Subversive SVN Team Provider
> Eclipse Data Tools Platform
> If you represent one of these projects and have chosen not to participate, 
> please let the group know.
> 
> If you're listed here in error, I apologise. Please send me a harshly worded 
> note pointing out my omission.
> 
> I am working with the Eclipse Data Tools Platform, so we'll likely get that 
> resolved shortly.
> 
> The Eclipse Subversive team has indicated that they can no longer support the 
> project, so we're going to have to sort out what (if anything) to do about 
> that.
> 
> Since I'm pretty sure that the Eclipse Packaging Project is paying attention 
> (and I am a committer on the project), I've created a 4.8 release 
>  at 
> +4 (consider this the project's declaration of participation).
> 
> Thanks for your attention,
> 
> Wayne
> -- 
> Wayne Beaton
> Director of Open Source Projects
> The Eclipse Foundation
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org 
> 
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Make sure you are committing to the right SimRel aggregation branch

[Greg Watson]

Yes, I committed to the Oxygen_update branch when I discovered it wasn't 
included in RC2.

Thanks,
Greg

> On Sep 4, 2017, at 9:09 AM, Frederic Gurr 
>  wrote:
> 
> Hi,
> 
> Judging by the comments in the following commits to the master branch of
> org.eclipse.simrel.build I believe they were supposed to be committed to
> the Oxygen_update branch instead (I've found no corresponding commits
> there):
> 
> * Update for ECF 3.13.8 for Oxygen.1
> http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?id=2086587c167060c429d9bbc8c2552d9f55984db2
> 
> * Update ptp for RC2
> http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?id=c5e884c67bc77edcb4545b6f49b816651582ea6a
> 
> To reiterate:
> - Contribution for Photon => commit to master
> - Contribution for Oxygen => commit to Oxygen_update
> 
> 
> Regards,
> 
> Fred
> 
> 
> -- 
> Frederic Gurr
> 
> Release Engineer
> Eclipse Foundation

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] New projects: Jenkins or Hudson

[Greg Watson]

Excellent, thanks!

> On Jul 10, 2017, at 4:18 PM, MAGGI Benoit <benoit.ma...@cea.fr> wrote:
> 
> Hi Greg,
> 
> From my understanding, new project should use Jenkins.
> See 
> https://dev.eclipse.org/mhonarc/lists/cbi-dev/msg01771.html
> 
> Regards,
> Benoît
> 
> -Message d'origine-
> De : cross-project-issues-dev-boun...@eclipse.org 
> [mailto:cross-project-issues-dev-boun...@eclipse.org] De la part de Greg 
> Watson
> Envoyé : lundi 10 juillet 2017 04:17
> À : Cross project issues <cross-project-issues-dev@eclipse.org>
> Objet : [cross-project-issues-dev] New projects: Jenkins or Hudson
> 
> Should new projects use Jenkins or Hudson instances these days? Any pointers 
> appreciated.
> 
> Regards,
> Greg
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit 
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] New projects: Jenkins or Hudson

[Greg Watson]

Should new projects use Jenkins or Hudson instances these days? Any pointers 
appreciated.

Regards,
Greg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [ptp-dev] Hudson

[Greg Watson]

No idea. When I tried to restart it from the HIPP control panel, I get:

  Your request to restart Hudson has completed. Output 
text:@@@ @ WARNING: 
REMOTE HOST IDENTIFICATION HAS CHANGED! @ 
@@@ IT IS POSSIBLE THAT 
SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right 
now (man-in-the-middle attack)! It is also possible that a host key has just 
been changed. The fingerprint for the RSA key sent by the remote host is 
d5:56:c7:87:6b:15:b7:3f:aa:ea:e1:cd:2a:ca:ee:3f [MD5]. Please contact your 
system administrator. Add correct host key in 
/home/data/users/genie/.ssh/known_hosts to get rid of this message. Offending 
RSA key in /home/data/users/genie/.ssh/known_hosts:7 Password authentication is 
disabled to avoid man-in-the-middle attacks. Keyboard-interactive 
authentication is disabled to avoid man-in-the-middle attacks.

Greg

> On Jun 20, 2017, at 12:23 AM, Doug Schaefer  wrote:
> 
> Hey gang, I notice that the PTP hudson instance seems to have disappeared. 
> Anyone know why?
> 
> Thanks,
> Doug.
> ___
> ptp-dev mailing list
> ptp-...@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/ptp-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Info Center for Neon.3

[Greg Watson]

+1

Greg

> On Apr 11, 2017, at 11:03 AM, Denis Roy  wrote:
> 
> I think we should have only one infocenter per major release (ie, a
> single Neon infocenter).
> 
> Denis
> 
> On 04/11/2017 05:22 AM, Frederic Gurr wrote:
>> Hi,
>> 
>> There was no feedback in two weeks, so I consider the info center for
>> Neon.3 done.
>> 
>> I'd like to gather some opinions about the following question:
>> 
>> Should there be a separate info center for every release and service
>> release (e.g. separate info center for Neon.0, Neon.1, Neon.2, Neon.3),
>> or should there be only one info center per release with updated content?
>> If this has already been decided and defined somewhere, please point me
>> to it.
>> 
>> Regards,
>> 
>> Fred
>> 
>> On 28.03.2017 19:44, Frederic Gurr wrote:
>>> Hi,
>>> 
>>> The info center for the Neon.3 release is now available here:
>>> http://help.eclipse.org/neon3/index.jsp
>>> 
>>> As proposed in Bug 499411
>>> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=499411), project's
>>> participation in the info center has changed from opt-in to opt-out.
>>> 
>>> Compared to the Neon info center the following user
>>> guides/documentations have been added in Neon.3:
>>> 
>>> * ACTF Visualization SDK Developer Guide
>>> * ACTF Visualization User Guide
>>> * BIRT Report Developer Guide
>>> * BPEL User Guide
>>> * BPMN2 Modeler Table of Contents
>>> * Data Tools Platform Plug-in Developer Guide
>>> * Data Tools Platform User Documentation
>>> * ECF Remote Services Developer Guide
>>> * Eclipse Marketplace User Guide
>>> * EEF Javadoc
>>> * EGF Eclipse Generation Factories Guide
>>> * EGit GitHub Documentation
>>> * GMF Developer Guide
>>> * LDT User Guide
>>> * Modeling Workflow Engine Reference
>>> * RSE User Guide
>>> * Sequoyah User Guide
>>> * Shell Script Editor User Guide
>>> * Sphinx Developer Guide
>>> * Subversive User Guide
>>> * Tcl/Xotcl Development User Guide
>>> * WindowBuilder Pro User Guide
>>> * Xpand Documentation
>>> * XSD Developer Guide
>>> * Xtend User Guide
>>> * Xtext Documentation
>>> 
>>> The following user guides/documentations are included in the Neon info
>>> center, but not in Neon.3:
>>> 
>>> * JavaServer Faces Tooling Developer Guide
>>> * Oomph Utilities Documentation
>>> * PTP Developer's Guide
>>> * XSL Tools SDK Documentation
>>> 
>>> If any user guide/documentation should NOT be included in the Neon.3
>>> info center or is missing in error (e.g. PTP) please comment on bug
>>> 514345 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=514345).
>>> 
>>> If something is missing, please provide the full path and all files that
>>> should be included.
>>> 
>>> 
>>> Regards,
>>> 
>>> Fred
>>> ___
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@eclipse.org
>>> To change your delivery options, retrieve your password, or unsubscribe 
>>> from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>> 
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe from 
>> this list, visit
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Marketplace down?

[Greg Watson]

Apparently is was a cache issue [1]. It's working for me again now.

Thanks,
Greg

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=511934 
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=511934>

> On Feb 8, 2017, at 1:51 PM, Denis Roy <denis@eclipse.org> wrote:
> 
> All good here.
> 
> On 08/02/17 01:41 PM, Greg Watson wrote:
>> I'm getting the message "Error" when I try to access 
>> https://marketplace.eclipse.org. Is anyone else seeing this?
>> 
>> Thanks
>> Greg
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe from 
>> this list, visit
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> 
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] build error

[Greg Watson]

My solution was to remove the old workspace. Thanks!

Greg

> On Nov 23, 2016, at 4:56 PM, Roland Grunberg  wrote:
> 
>> Does anyone know what this build error means? Last time I ran a build
>> (admittedly a while ago), it worked. I presume something has changed
>> somewhere...
> 
> Is it this job ? 
> https://hudson.eclipse.org/ptp/job/ptp-nightly-packages/285/console
> 
> This looks a lot like https://bugs.eclipse.org/bugs/show_bug.cgi?id=507419 .
> Have a look at comment #9. Perhaps you could ask that your HIPP also have
> the mirroring disabled.
> 
> Cheers,
> -- 
> Roland Grunberg
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] build error

[Greg Watson]

Hi,

Does anyone know what this build error means? Last time I ran a build 
(admittedly a while ago), it worked. I presume something has changed 
somewhere...

Thanks,
Greg

[INFO] Resolving dependencies of MavenProject: 
org.eclipse.ptp.master:org.eclipse.ptp.rcp.sysmon:1.0.0-SNAPSHOT @ 
/jobs/genie.ptp/ptp-nightly-packages/workspace/org.eclipse.ptp.rcp.sysmon/pom.xml
[ERROR] All attempts to read artifact 
osgi.bundle,org.eclipse.osgi,3.11.2.v20161107-1947 failed:
[ERROR]An error occurred while transferring artifact packed: 
osgi.bundle,org.eclipse.osgi,3.11.2.v20161107-1947 from repository 
http://download.eclipse.org/staging/neon: 

[ERROR]   Artifact not found: 
http://download.eclipse.org/staging/neon/plugins/org.eclipse.osgi_3.11.2.v20161107-1947.jar.pack.gz
 
.
[ERROR]An error occurred while transferring artifact canonical: 
osgi.bundle,org.eclipse.osgi,3.11.2.v20161107-1947 from repository 
http://download.eclipse.org/staging/neon: 

[ERROR]   Artifact not found: 
http://download.eclipse.org/staging/neon/plugins/org.eclipse.osgi_3.11.2.v20161107-1947.jar
 
.
[INFO] o.h.m.e.h.MavenExecutionResultHandler - Build failed with exception(s)
[INFO] o.h.m.e.h.MavenExecutionResultHandler - [1] 
org.apache.maven.InternalErrorException: Internal error: 
org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException:
 Could not mirror artifact osgi.bundle,org.eclipse.osgi,3.11.2.v20161107-1947 
into the local Maven repository.See log output for details.
[DEBUG] Closing connection to remote
[ERROR] Internal error: 
org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException:
 Could not mirror artifact osgi.bundle,org.eclipse.osgi,3.11.2.v20161107-1947 
into the local Maven repository.See log output for details. 
http://download.eclipse.org/staging/neon/plugins/org.eclipse.osgi_3.11.2.v20161107-1947.jar.pack.gz
 
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] hudson job fail

[Greg Watson]

Ah yes, I missed that in the user friendly output. :-( Thanks!

> On Nov 17, 2016, at 6:05 PM, Stephan Herrmann <stephan.herrm...@berlin.de> 
> wrote:
> 
> On 11/17/2016 06:59 PM, Greg Watson wrote:
>> Hi,
>> 
>> My hudson job is failing with this error. Does anyone have any idea why?
>> 
>> Thanks,
>> Greg
>> 
>> Nov 17, 2016 12:57:40 PM org.sonatype.guice.bean.reflect.Logs$JULSink warn
> > [...]
>> Caused by: java.lang.UnsupportedClassVersionError: 
>> org/eclipse/tycho/core/p2/P2ArtifactRepositoryLayout : Unsupported 
>> major.minor version 52.0
> 
> Using a tycho version that's requires Java 8, and running on Java <= 7?
> 
> Stephan
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] hudson job fail

[Greg Watson]

Hi,

My hudson job is failing with this error. Does anyone have any idea why?

Thanks,
Greg

Nov 17, 2016 12:57:40 PM org.sonatype.guice.bean.reflect.Logs$JULSink warn
WARNING: Error injecting: org.eclipse.tycho.core.p2.P2ArtifactRepositoryLayout
java.lang.TypeNotPresentException: Type 
org.eclipse.tycho.core.p2.P2ArtifactRepositoryLayout not present
at 
org.sonatype.guice.bean.reflect.URLClassSpace.loadClass(URLClassSpace.java:109)
at org.sonatype.guice.bean.reflect.NamedClass.load(NamedClass.java:45)
at 
org.sonatype.guice.bean.reflect.AbstractDeferredClass.get(AbstractDeferredClass.java:45)
at 
com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:84)
at 
com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:52)
at 
com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
at 
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:100)
at 
org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:138)
at 
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:108)
at 
com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
at 
com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
at 
com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
at 
com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at 
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1018)
at 
com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at com.google.inject.Scopes$1$1.get(Scopes.java:59)
at 
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
at 
com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:965)
at 
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1011)
at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:961)
at 
org.sonatype.guice.bean.locators.LazyBeanEntry.getValue(LazyBeanEntry.java:83)
at 
org.sonatype.guice.plexus.locators.LazyPlexusBean.getValue(LazyPlexusBean.java:49)
at java.util.AbstractMap.get(AbstractMap.java:182)
at 
org.apache.maven.repository.legacy.LegacyRepositorySystem.getLayout(LegacyRepositorySystem.java:836)
at 
org.apache.maven.repository.legacy.LegacyRepositorySystem.buildArtifactRepository(LegacyRepositorySystem.java:782)
at 
org.apache.maven.project.DefaultProjectBuildingHelper.createArtifactRepositories(DefaultProjectBuildingHelper.java:112)
at 
org.apache.maven.project.DefaultModelBuildingListener.buildExtensionsAssembled(DefaultModelBuildingListener.java:127)
at 
org.apache.maven.model.building.ModelBuildingEventCatapult$1.fire(ModelBuildingEventCatapult.java:43)
at 
org.apache.maven.model.building.DefaultModelBuilder.fireEvent(DefaultModelBuilder.java:1053)
at 
org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:388)
at 
org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:371)
at 
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:560)
at 
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:352)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:636)
at 
org.apache.maven.DefaultMaven.getProjectsForMavenReactor(DefaultMaven.java:585)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:234)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at 

Re: [cross-project-issues-dev] Upgrading HIPPs to SLES12

[Greg Watson]

It’s working again for me also. Not sure if it was my end or your end. In any 
case, thanks for taking a look.

Greg

> On Sep 13, 2016, at 5:02 AM, Frederic Gurr <frederic.g...@eclipse.org> wrote:
> 
> Hmm. Works on my side.
> 
> Regards,
> 
> Fred
> 
> On 12.09.2016 21:49, Greg Watson wrote:
>> The PTP HIPP appears to be down.
>> 
>> Greg
>> 
>>> On Sep 12, 2016, at 5:52 AM, Frederic Gurr <frederic.g...@eclipse.org> 
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> All mentioned HIPPs are now back online.
>>> We are sorry for the additional downtime.
>>> 
>>> Regards,
>>> 
>>> Fred
>>> 
>>> 
>>> On 12.09.2016 09:38, Pierre-Charles David wrote:
>>>> Le 07/09/2016 à 19:35, Frederic Gurr a écrit :
>>>>> Hi,
>>>>> 
>>>>> The following HIPPs will be upgraded to SLES12:
>>>>> 
>>>>> * bpmn2
>>>>> * ebr
>>>>> * equinox
>>>>> * etrice
>>>>> * ptp
>>>>> * rmf
>>>>> * sirius
>>>>> * thym
>>>>> * umlgen
>>>>> * uomo
>>>>> * vex
>>>>> 
>>>>> The upgrade is scheduled for Friday, September 9th, 10am EDT.
>>>>> 
>>>>> Downtime will be a few hours.
>>>>> 
>>>> 
>>>> It seems none of the HIPPs above are accessible since the upgrade (at
>>>> least the ones I tried). I tried restarting the Sirius one manually, but
>>>> only got an error message regarding SSH fingerprints. I've opened
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=501206 with the details.
>>>> 
>>>> ___
>>>> cross-project-issues-dev mailing list
>>>> cross-project-issues-dev@eclipse.org
>>>> To change your delivery options, retrieve your password, or unsubscribe
>>>> from this list, visit
>>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>> ___
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@eclipse.org
>>> To change your delivery options, retrieve your password, or unsubscribe 
>>> from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>> 
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe from 
>> this list, visit
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Upgrading HIPPs to SLES12

[Greg Watson]

The PTP HIPP appears to be down.

Greg

> On Sep 12, 2016, at 5:52 AM, Frederic Gurr  wrote:
> 
> Hi,
> 
> All mentioned HIPPs are now back online.
> We are sorry for the additional downtime.
> 
> Regards,
> 
> Fred
> 
> 
> On 12.09.2016 09:38, Pierre-Charles David wrote:
>> Le 07/09/2016 à 19:35, Frederic Gurr a écrit :
>>> Hi,
>>> 
>>> The following HIPPs will be upgraded to SLES12:
>>> 
>>> * bpmn2
>>> * ebr
>>> * equinox
>>> * etrice
>>> * ptp
>>> * rmf
>>> * sirius
>>> * thym
>>> * umlgen
>>> * uomo
>>> * vex
>>> 
>>> The upgrade is scheduled for Friday, September 9th, 10am EDT.
>>> 
>>> Downtime will be a few hours.
>>> 
>> 
>> It seems none of the HIPPs above are accessible since the upgrade (at
>> least the ones I tried). I tried restarting the Sirius one manually, but
>> only got an error message regarding SSH fingerprints. I've opened
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=501206 with the details.
>> 
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] PTP will participate in Oxygen

[Greg Watson]

PTP will be participating at Oxygen at offset +3 (remote at +1). I will update 
the release record as soon as http://projects.eclipse.org 
 is working again [1].

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=499478 
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] problem with signing service

[Greg Watson]

This is failing again.

> On Jul 14, 2016, at 2:51 PM, Mikaël Barbero <mik...@eclipse.org> wrote:
> 
> It has been a temporary issue that is solved now. 
> 
>> Le 12 juil. 2016 à 21:13, Greg Watson <g.wat...@computer.org 
>> <mailto:g.wat...@computer.org>> a écrit :
>> 
>> Our builds are hanging while signing the OS X application. Anyone else 
>> having problems?
>> 
>> Greg
>> 
>> [INFO] 
>> [INFO] --- eclipse-macsigner-plugin:1.1.3:sign (default) @ 
>> org.eclipse.ice.product ---
>> [INFO] [Tue Jul 12 20:57:40 EDT 2016] Signing OS X application 
>> '/jobs/genie.ice/ice-next/workspace/ice/org.eclipse.ice.product/target/products/ice.product/macosx/cocoa/x86_64/ICE.app'...
>> [WARNING] [Tue Jul 12 21:03:14 EDT 2016] HTTP request failed.
>> HTTP Error 502 (reason: Proxy Error)
>> 
>> 
>> 502 Proxy Error
>> 
>> Proxy Error
>> The proxy server received an invalid
>> response from an upstream server.
>> The proxy server could not handle the request > href="/macsign.php">POST/macsign.php.
>> Reason: Error reading from remote server
>> 
>> Server response has been saved to 
>> '/jobs/genie.ice/ice-next/workspace/ice/org.eclipse.ice.product/target/products/ice.product/macosx/cocoa/x86_64/ICE.app_8154873188463010492.zip-214291804243594696-OSXAppSigner.log'
>> [WARNING] [Tue Jul 12 21:10:07 EDT 2016] HTTP request failed.
>> HTTP Error 502 (reason: Proxy Error)
>> 
>> 
>> 502 Proxy Error
>> 
>> Proxy Error
>> The proxy server received an invalid
>> response from an upstream server.
>> The proxy server could not handle the request > href="/macsign.php">POST/macsign.php.
>> Reason: Error reading from remote server
>> 
>> 
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org 
>> <mailto:cross-project-issues-dev@eclipse.org>
>> To change your delivery options, retrieve your password, or unsubscribe from 
>> this list, visit
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] problem with signing service

[Greg Watson]

Our builds are hanging while signing the OS X application. Anyone else having 
problems?

Greg

[INFO] 
[INFO] --- eclipse-macsigner-plugin:1.1.3:sign (default) @ 
org.eclipse.ice.product ---
[INFO] [Tue Jul 12 20:57:40 EDT 2016] Signing OS X application 
'/jobs/genie.ice/ice-next/workspace/ice/org.eclipse.ice.product/target/products/ice.product/macosx/cocoa/x86_64/ICE.app'...
[WARNING] [Tue Jul 12 21:03:14 EDT 2016] HTTP request failed.
HTTP Error 502 (reason: Proxy Error)


502 Proxy Error

Proxy Error
The proxy server received an invalid
response from an upstream server.
The proxy server could not handle the request POST/macsign.php.
Reason: Error reading from remote server

Server response has been saved to 
'/jobs/genie.ice/ice-next/workspace/ice/org.eclipse.ice.product/target/products/ice.product/macosx/cocoa/x86_64/ICE.app_8154873188463010492.zip-214291804243594696-OSXAppSigner.log'
[WARNING] [Tue Jul 12 21:10:07 EDT 2016] HTTP request failed.
HTTP Error 502 (reason: Proxy Error)


502 Proxy Error

Proxy Error
The proxy server received an invalid
response from an upstream server.
The proxy server could not handle the request POST/macsign.php.
Reason: Error reading from remote server


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] problems with wiki

[Greg Watson]

Hi,

I’m trying to update the wiki but it just seems to hang when I try to save any 
changes. Is anyone else seeing this?

Greg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Change 73676 insimrel/org.eclipse.simrel.build[master]: Update PTP to RC2

[Greg Watson]

I would have though everyone is using Gerrit by now, but I guess not.

In any case, I’ve submitted another changeset, so hopefully it will work this 
time.

Thanks,
Greg

> On May 25, 2016, at 8:12 PM, David M Williams  
> wrote:
> 
> 
> > ... Does anyone know why, or how to fix it?
> 
> My EGit contacts have not responded to my mail. Or a classic case of 
> "committing, then going home" :) Or at least a classic case where a Gerrit 
> submission would have helped! It would have caught the problem easily and 
> prevented it from getting in the way of others. [I have seen that several 
> times today, folks -- for all you who don't routinely use Gerrit -- please 
> do!]
> 
> I've taken my "best guess" as to what they intended. If my guess was wrong, 
> they'll have to tell us that later, I guess. 
> 
> Thanks, 
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Fwd: Change 73676 in simrel/org.eclipse.simrel.build[master]: Update PTP to RC2

[Greg Watson]

Hi,

I'm trying to update our simrel build but it is failing verification for some 
completely unrelated reason. Does anyone know why, or how to fix it?

Thanks
Greg 


Begin forwarded message:

> From: "Hudson CI (Code Review)" <ger...@eclipse.org>
> Date: May 25, 2016 at 6:37:58 PM EDT
> To: Greg Watson <g.wat...@computer.org>
> Subject: Change 73676 in simrel/org.eclipse.simrel.build[master]: Update PTP 
> to RC2
> 
> Hudson CI has posted comments on this change.
> 
> Change subject: Update PTP to RC2
> ..
> 
> 
> Patch Set 1:
> 
> Build Started 
> https://hudson.eclipse.org/simrel/job/simrel.neon.runaggregator.VALIDATE.gerrit/410/
> 
> -- 
> To view, visit https://git.eclipse.org/r/73676
> To unsubscribe, visit https://git.eclipse.org/r/settings
> 
> Gerrit-MessageType: comment
> Gerrit-Change-Id: I599958cf250eee469cc9034c00c4fb81cf358310
> Gerrit-PatchSet: 1
> Gerrit-Project: simrel/org.eclipse.simrel.build
> Gerrit-Branch: master
> Gerrit-Owner: Greg Watson <g.wat...@computer.org>
> Gerrit-Reviewer: Hudson CI
> Gerrit-HasComments: No
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] OS X application signing

[Greg Watson]

Do you do the same thing when signing windows executables? 
In any case, I’ll give this a try.
Thanks!

> On Mar 1, 2016, at 2:13 PM, Eike Stepper <step...@esc-net.de> wrote:
> 
> Hi Greg,
> 
> We do it as a shell build step in Hudson:
> 
>  zip -r -q unsigned.zip "Eclipse Installer.app"
>  rm -rf "Eclipse Installer.app"
>  curl -o signed.zip -F file=@unsigned.zip 
> http://build.eclipse.org:31338/macsign.php
>  unzip -qq signed.zip
>  rm -f unsigned.zip signed.zip
> 
> Cheers
> /Eike
> 
> 
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
> 
> 
> 
> Am 01.03.2016 um 19:50 schrieb Greg Watson:
>> Has anyone been able to get OS X application signing to work?
>> 
>> I added the following to our build:
>> 
>>
>>org.eclipse.cbi.maven.plugins
>>eclipse-macsigner-plugin
>>${cbi-plugins.version}
>>
>>
>>
>>sign
>>
>>package
>>  
>>  
>>  
>> ${project.build.directory}/products/ice.product/macosx/cocoa/x86_64/ICE.app
>>  
>>  
>>
>>
>>
>> 
>> When the build runs, it says:
>> 
>> [INFO] --- eclipse-macsigner-plugin:1.1.3:sign (default) @ 
>> org.eclipse.ice.repository ---
>> [INFO] [Tue Mar 01 12:42:09 EST 2016] Signing OS X application 
>> '/jobs/genie.ice/ice-next/workspace/ice/org.eclipse.ice.repository/target/products/ice.product/macosx/cocoa/x86_64/ICE.app'...
>> 
>> However, the codesign command says:
>> 
>> $ codesign --verify ICE.app
>> ICE.app: code object is not signed at all
>> In architecture: x86_64
>> 
>> Any help or suggestions appreciated.
>> 
>> Greg
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe from 
>> this list, visit
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>> 
> 
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] OS X application signing

[Greg Watson]

Nope, this just complains about not finding ICE.app. I’ve posted to cbi-dev and 
will see if they can help.
Thanks

> On Mar 1, 2016, at 2:30 PM, David M Williams <david_willi...@us.ibm.com 
> <mailto:david_willi...@us.ibm.com>> wrote:
> 
> I think for the "signFiles" you need *just* the file name. (ICE.app in your 
> case). The "place" it is looking for that, is different than your "whole 
> build directory". 
> 
> cbi-dev is a good list to ask questions like this. 
> 
> 
> 
> 
> From:Greg Watson <g.wat...@computer.org 
> <mailto:g.wat...@computer.org>>
> To:cross-project-issues-dev@eclipse.org 
> <mailto:cross-project-issues-dev@eclipse.org>, 
> Date:03/01/2016 01:50 PM
> Subject:[cross-project-issues-dev] OS X application signing
> Sent by:cross-project-issues-dev-boun...@eclipse.org 
> <mailto:cross-project-issues-dev-boun...@eclipse.org>
> 
> 
> 
> Has anyone been able to get OS X application signing to work?
> 
> I added the following to our build:
> 
>   
>   org.eclipse.cbi.maven.plugins
>   eclipse-macsigner-plugin
>   ${cbi-plugins.version}
>   
>   
>   
>   sign
>   
>   package
>
> 
>   
>   
>   
>
> ${project.build.directory}/products/ice.product/macosx/cocoa/x86_64/ICE.app
>   
>   
>
> 
>   
>   
>   
> 
> When the build runs, it says:
> 
> [INFO] --- eclipse-macsigner-plugin:1.1.3:sign (default) @ 
> org.eclipse.ice.repository ---
> [INFO] [Tue Mar 01 12:42:09 EST 2016] Signing OS X application 
> '/jobs/genie.ice/ice-next/workspace/ice/org.eclipse.ice.repository/target/products/ice.product/macosx/cocoa/x86_64/ICE.app'...
> 
> However, the codesign command says:
> 
> $ codesign --verify ICE.app
> ICE.app: code object is not signed at all
> In architecture: x86_64
> 
> Any help or suggestions appreciated.
> 
> Greg
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org 
> <mailto:cross-project-issues-dev@eclipse.org>
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
> 
> 
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org 
> <mailto:cross-project-issues-dev@eclipse.org>
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] OS X application signing

[Greg Watson]

Has anyone been able to get OS X application signing to work?

I added the following to our build:

   
   org.eclipse.cbi.maven.plugins
   eclipse-macsigner-plugin
   ${cbi-plugins.version}
   
   
   
   sign
   
   package



${project.build.directory}/products/ice.product/macosx/cocoa/x86_64/ICE.app


   
   
   

When the build runs, it says:

[INFO] --- eclipse-macsigner-plugin:1.1.3:sign (default) @ 
org.eclipse.ice.repository ---
[INFO] [Tue Mar 01 12:42:09 EST 2016] Signing OS X application 
'/jobs/genie.ice/ice-next/workspace/ice/org.eclipse.ice.repository/target/products/ice.product/macosx/cocoa/x86_64/ICE.app'...

However, the codesign command says:

$ codesign --verify ICE.app
ICE.app: code object is not signed at all
In architecture: x86_64

Any help or suggestions appreciated.

Greg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] TM participating in Neon

[Greg Watson]

The TM project will be participating in Neon with an offset of +1. The release 
record is here:

https://projects.eclipse.org/projects/tools.tm/releases/4.1.0

Regards,
Greg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [tm-dev] Any RSE dependencies in Neon?

[Greg Watson]

butes a DLTK RSE feature to the release train. My
> >> guess is that no one else on the release train depends on this DLTK RSE
> >> feature, so it would be easy to remove it if necessary.
> >>
> >>
> >>
> >> From adopter's point of view, like JBoss Tools, Zend Studio also heavily
> >> relies on RSE.
> >>
> >> The new o.e.remote really has some advantages like the Synchronized
> >> Project, but still misses some basic features of RSE:
> >>
> >>   - Connecting to Windows systems (no cygwin please)
> >>
> >>   - FTP connections
> >>
> >>   - Remote Systems Explorer view, which allows browsing and editing files
> >> without creating a project on a remote system, but also on the local file
> >> system using the Local connection.
> >>
> >>
> >>
> >> However, I suppose that Zend Studio, JBoss Tools and any other adopter can
> >> continue using RSE outside of the release train, while the project remains
> >> under the Eclipse Foundation.
> >>
> >>
> >>
> >> BTW, something interesting I noticed is that IBM has already a fork of the
> >> RSE project. In the IBM Rational products the RSE plugins exist with the
> >> same org.eclipse.rse.* IDs, but with version 4.4.x. RSE under the Eclipse
> >> Foundation is still with version 3.7.2. This already causes a nasty
> >> fragmentation of RSE in the community. Any plugin that depends on the EF 
> >> RSE
> >> most likely cannot be installed on IBM Rational due to dependency 
> >> conflicts.
> >>
> >>
> >>
> >> So, I have a suggestion. If the TM project has no interest in maintaining
> >> RSE in future, how about moving RSE to a new "orphan" project outside of 
> >> the
> >> TM project, so those adopter who still rely on RSE can continue maintaining
> >> and improving it until they are ready to switch to the new alternative?
> >>
> >>
> >>
> >> Kaloyan
> >>
> >>
> >>
> >>
> >>
> >> On Sat, Dec 12, 2015 at 9:17 AM, Max Rydahl Andersen <mande...@redhat.com 
> >> <mailto:mande...@redhat.com>>
> >> wrote:
> >>
> >> I know we are not on the release train but JBoss tools continues to use
> >> RSE.
> >>
> >> Afaik there are still no replacement for the functionality it provides
> >> with respect to UI for connecting to ssh and ftp based systems.
> >>
> >> If there are I would love to hear about them.
> >>
> >> Thus my interest is still to keep it in.
> >>
> >> If help is needed for including it let me know.
> >>
> >> /max
> >> http://about.me/maxandersen <http://about.me/maxandersen>
> >>
> >>
> >> > On 11 Dec 2015, at 19:13, Greg Watson <g.wat...@computer.org 
> >> > <mailto:g.wat...@computer.org>> wrote:
> >> >
> >> > Are there any projects that have a dependency on Remote System Explorer
> >> > (RSE) in Neon? The TM project must decide if RSE will be included in the
> >> > Neon release. Currently there is only interest in including TM Terminal.
> >> >
> >> > Thanks,
> >> > Greg
> >> > ___
> >> > tm-dev mailing list
> >> > tm-...@eclipse.org <mailto:tm-...@eclipse.org>
> >> > To change your delivery options, retrieve your password, or unsubscribe
> >> > from this list, visit
> >> > https://dev.eclipse.org/mailman/listinfo/tm-dev 
> >> > <https://dev.eclipse.org/mailman/listinfo/tm-dev>
> >>
> >> ___
> >> cross-project-issues-dev mailing list
> >> cross-project-issues-dev@eclipse.org 
> >> <mailto:cross-project-issues-dev@eclipse.org>
> >> To change your delivery options, retrieve your password, or unsubscribe
> >> from this list, visit
> >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
> >> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
> >>
> >>
> >>
> >>
> >> ___
> >> cross-project-issues-dev mailing list
> >> cross-project-issues-dev@eclipse.org 
> >> <mailto:cross-project-issues-dev@eclipse.org>
> >> To change your delivery options, retrieve your password, 

[cross-project-issues-dev] Any RSE dependencies in Neon?

[Greg Watson]

Are there any projects that have a dependency on Remote System Explorer (RSE) 
in Neon? The TM project must decide if RSE will be included in the Neon 
release. Currently there is only interest in including TM Terminal.

Thanks,
Greg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Did I mess up our procedure for Neon? With respect to declaring, and enablement, and our "list of participants"?

[Greg Watson]

PTP/Remote will be in Neon. Versions unknown at this point.

Greg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] DTP for Neon stream ... runtime.compatibility ... and LDT? ... and Neon M2

[Greg Watson]

I don’t have admin access, unfortunately.

> On Sep 30, 2015, at 1:37 PM, Denis Roy <denis@eclipse.org> wrote:
> 
> If you have admin access to your HIPP, you can add a JDK in the Manage Hudson 
> section.
> 
> Have it point to /shared/common/jdk1.8.0-latest
> 
> Denis
> 
> 
>>> 
>>> 
>>> ___
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@eclipse.org 
>>> <mailto:cross-project-issues-dev@eclipse.org>
>>> To change your delivery options, retrieve your password, or unsubscribe 
>>> from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>>> ___
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@eclipse.org 
>>> <mailto:cross-project-issues-dev@eclipse.org>
>>> To change your delivery options, retrieve your password, or unsubscribe 
>>> from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>>> 
>>> ___
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@eclipse.org 
>>> <mailto:cross-project-issues-dev@eclipse.org>
>>> To change your delivery options, retrieve your password, or unsubscribe 
>>> from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>> 
>> 
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org 
>> <mailto:cross-project-issues-dev@eclipse.org>
>> To change your delivery options, retrieve your password, or unsubscribe from 
>> this list, visit
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
> On 30/09/15 01:32 PM, Greg Watson wrote:
>> I’m blocked because I don’t have a JDK 1.8 option on the PTP HIPP instance 
>> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=478669 
>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=478669>). If anyone knows how 
>> to add this, please let me know.
>> 
>> Greg
>> 
>>> On Sep 30, 2015, at 11:02 AM, David M Williams <david_willi...@us.ibm.com 
>>> <mailto:david_willi...@us.ibm.com>> wrote:
>>> 
>>> OK, I give up. 
>>> 
>>> It appears some projects are not going to be able to react to the removal 
>>> of runtime.compatibility bundle, for M2, so I have re-enabled the LDT 
>>> contribution. (Bug 478009 
>>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=478009> and Bug 478330 
>>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=478330>).
>>> This will allow the aggregation build, at least, to complete, so that 
>>> others can make progress. 
>>> 
>>> This won't help projects who have a direct dependancy on, say, DTP (which 
>>> in turn as a dependency on runtime compatibility bundle) since they depend 
>>> on it, but do not provide it. 
>>> For those people, the only work around I know of is to "include" only that 
>>> bundle from our M1 repository, or something similar. 
>>> Less that ideal, but I'd like to push forward and see if we can get out 
>>> some form of M2 that can be used to create a cleaner M3! 
>>> 
>>> Let me know if suggestions or alternative approaches. (And, FYI, it does 
>>> not appear that extending the deadline a few days will help with the 
>>> runtime compatibility issue, but, if anyone has been blocked due to this 
>>> issue, and needs a few days to work around the problem, I think it 
>>> reasonable to consider an extension of a few days ... if you make such a 
>>> request, please be specific ... I'd hate to extend it to Monday instead of 
>>> Friday (let's say) and then that still not be enough time.) 
>>> 
>>> Thanks, 
>>> 
>>> 
>>> 
>>> 
>>> From:David M Williams/Raleigh/IBM@IBMUS
>>> To:Cross project issues <cross-project-issues-dev@eclipse.org 
>>> <mailto:cross-project-issues-dev@eclipse.org>>, 
>>> Date:0

Re: [cross-project-issues-dev] DTP for Neon stream ... runtime.compatibility ... and LDT? ... and Neon M2

[Greg Watson]

I’m blocked because I don’t have a JDK 1.8 option on the PTP HIPP instance 
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=478669 
). If anyone knows how to 
add this, please let me know.

Greg

> On Sep 30, 2015, at 11:02 AM, David M Williams  
> wrote:
> 
> OK, I give up. 
> 
> It appears some projects are not going to be able to react to the removal of 
> runtime.compatibility bundle, for M2, so I have re-enabled the LDT 
> contribution. (Bug 478009 
>  and Bug 478330 
> ).
> This will allow the aggregation build, at least, to complete, so that others 
> can make progress. 
> 
> This won't help projects who have a direct dependancy on, say, DTP (which in 
> turn as a dependency on runtime compatibility bundle) since they depend on 
> it, but do not provide it. 
> For those people, the only work around I know of is to "include" only that 
> bundle from our M1 repository, or something similar. 
> Less that ideal, but I'd like to push forward and see if we can get out some 
> form of M2 that can be used to create a cleaner M3! 
> 
> Let me know if suggestions or alternative approaches. (And, FYI, it does not 
> appear that extending the deadline a few days will help with the runtime 
> compatibility issue, but, if anyone has been blocked due to this issue, and 
> needs a few days to work around the problem, I think it reasonable to 
> consider an extension of a few days ... if you make such a request, please be 
> specific ... I'd hate to extend it to Monday instead of Friday (let's say) 
> and then that still not be enough time.) 
> 
> Thanks, 
> 
> 
> 
> 
> From:David M Williams/Raleigh/IBM@IBMUS
> To:Cross project issues , 
> Date:09/28/2015 08:47 PM
> Subject:Re: [cross-project-issues-dev] DTP for Neon stream ... 
> runtime.compatibility ... and LDT? ... and Neon M2
> Sent by:cross-project-issues-dev-boun...@eclipse.org
> 
> 
> 
> I hope everyone remembers that Neon M2 is this Friday ... and that means your 
> Neon M2 contributions must be done by Wednesday. 
> 
> AND .. it seems, some have not yet reacted to the platform removing 
> org.eclipse. runtime.compatibility bundle (Bug 394739 
> ). 
> 
> AND .. some have been "getting it automatically" from the current Sim. 
> Release contributions, because Lua Development Tools (LDT) duplicates it (and 
> many others) in their repository (Bug 478009 
> ). 
> 
> Since LDT has not updated their repo yet for Neon, I fear some may have of a 
> false sense that "everything is ok".
> 
> Put more bluntly, we all know, some projects do not build against the latest 
> version of their pre-reqs! And, we all know that some projects won't react 
> until "the build fails". 
> 
> Therefore ... I am about to make the build fail for others, by removing LDT's 
> massive contribution. 
> 
> If someone has a better suggestion, that would be good to hear, but I hope I 
> am doing everyone a favor, by making the problem more apparent in the 
> aggregation build. 
> 
> (And, greatest thanks to those of you who HAVE reacted to this change already 
> ... thanks to all your release engineers!) 
> 
> Thank to you all, 
> 
> 
> 
> 
> 
> 
> From:David M Williams/Raleigh/IBM@IBMUS
> To:Cross project issues , 
> Date:09/21/2015 08:09 PM
> Subject:Re: [cross-project-issues-dev] DTP for Neon stream ... and 
> LDT?
> Sent by:cross-project-issues-dev-boun...@eclipse.org
> 
> 
> 
> > A question regarding the aggregation build. I thought it was 
> > designed to catch issues like this, but I don’t see any failures on Hudson.
> 
> I was wondering that too. :) So ... 
> 
> I looked in the log, at 
> https://hudson.eclipse.org/simrel/job/simrel.neon.runaggregator.BUILD__CLEAN/111/consoleFull
>  
> 
> and could see 
> 
> - mirroring artifact 
> osgi.bundle,org.eclipse.core.runtime.compatibility,3.2.300.v20150423-0821
> 
> and then searching backwards in log, for "Mirroring artifacts from",
> could see that the LDT project is (also) contributing that bundle, via their 
> repository at 
> .../download.eclipse.org/ldt/releases/stable/1.3
> 
> I hope that is a temporary condition, since (in this case) do not think the 
> Platform would like others 
> "extending the life" of something they are trying to end. But ... I am not 
> sure. I think the next step 
> is to hear from the LDT project. I have opened bug 478009 
>  for this issue. 
> 
> I did also use b3 aggregator editor to search for others who might be 
> 

Re: [cross-project-issues-dev] DTP for Neon stream ... runtime.compatibility ... and LDT? ... and Neon M2

[Greg Watson]

Thanks!

> On Sep 30, 2015, at 3:37 PM, Denis Roy <denis@eclipse.org> wrote:
> 
> I've given Administer rights to the PTP team on the PTP HIPP, and while I was 
> in there, I've created your JDK 1.8.0.
> 
> Denis
> 
> 
> 
> On 30/09/15 03:01 PM, Greg Watson wrote:
>> I don’t have admin access, unfortunately.
>> 
>>> On Sep 30, 2015, at 1:37 PM, Denis Roy < 
>>> <mailto:denis@eclipse.org>denis@eclipse.org 
>>> <mailto:denis@eclipse.org>> wrote:
>>> 
>>> If you have admin access to your HIPP, you can add a JDK in the Manage 
>>> Hudson section.
>>> 
>>> Have it point to /shared/common/jdk1.8.0-latest
>>> 
>>> Denis
>>> 
>>> 
>>>>> 
>>>>> 
>>>>> ___
>>>>> cross-project-issues-dev mailing list
>>>>> cross-project-issues-dev@eclipse.org 
>>>>> <mailto:cross-project-issues-dev@eclipse.org>
>>>>> To change your delivery options, retrieve your password, or unsubscribe 
>>>>> from this list, visit
>>>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>>>>> ___
>>>>> cross-project-issues-dev mailing list
>>>>> cross-project-issues-dev@eclipse.org 
>>>>> <mailto:cross-project-issues-dev@eclipse.org>
>>>>> To change your delivery options, retrieve your password, or unsubscribe 
>>>>> from this list, visit
>>>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>>>>> 
>>>>> ___
>>>>> cross-project-issues-dev mailing list
>>>>> cross-project-issues-dev@eclipse.org 
>>>>> <mailto:cross-project-issues-dev@eclipse.org>
>>>>> To change your delivery options, retrieve your password, or unsubscribe 
>>>>> from this list, visit
>>>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>>>> 
>>>> 
>>>> ___
>>>> cross-project-issues-dev mailing list
>>>> cross-project-issues-dev@eclipse.org 
>>>> <mailto:cross-project-issues-dev@eclipse.org>
>>>> To change your delivery options, retrieve your password, or unsubscribe 
>>>> from this list, visit
>>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>>> On 30/09/15 01:32 PM, Greg Watson wrote:
>>>> I’m blocked because I don’t have a JDK 1.8 option on the PTP HIPP instance 
>>>> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=478669 
>>>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=478669>). If anyone knows 
>>>> how to add this, please let me know.
>>>> 
>>>> Greg
>>>> 
>>>>> On Sep 30, 2015, at 11:02 AM, David M Williams <david_willi...@us.ibm.com 
>>>>> <mailto:david_willi...@us.ibm.com>> wrote:
>>>>> 
>>>>> OK, I give up. 
>>>>> 
>>>>> It appears some projects are not going to be able to react to the removal 
>>>>> of runtime.compatibility bundle, for M2, so I have re-enabled the LDT 
>>>>> contribution. (Bug 478009 
>>>>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=478009> and Bug 478330 
>>>>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=478330>).
>>>>> This will allow the aggregation build, at least, to complete, so that 
>>>>> others can make progress. 
>>>>> 
>>>>> This won't help projects who have a direct dependancy on, say, DTP (which 
>>>>> in turn as a dependency on runtime compatibility bundle) since they 
>>>>> depend on it, but do not provide it. 
>>>>> For those people, the only work around I know of is to "include" only 
>>>>> that bundle from our M1 repository, or something similar. 
>>>>> Less that ideal, but I'd like to push forward and see if we can get out 
>

Re: [cross-project-issues-dev] automated error reporting

[Greg Watson]

Ok, that explains it.

Thanks!

 On Jun 2, 2015, at 9:40 AM, Marcel Bruch marcel.br...@codetrails.com wrote:
 
 Hi Greg,
 
 daily digest contain errors that (i) have been reported in the past 24 hours 
 and (ii) passed some thresholds like minimum number of users. For PTP the 
 last report was on 2015-05-30 - which might explain why you did not get a 
 daily digest in the last two days.
 
 I assume you had a different expectation. Please let me know what you were 
 expecting and we can work out how to accomplish what you are looking for.
 
 Best,
 Marcel
 
 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/?projects=ptpkinds=NORMALpage=0size=10sort=modifiedOn,desc
 
 
 On 02 Jun 2015, at 15:14, Greg Watson g.wat...@computer.org wrote:
 
 Hi,
 
 I’ve enabled daily digests for PTP, but we’re not seeing any emails. Is 
 there something else I need to do? Does the error reporting address need to 
 be subscribed to the list?
 
 Thanks,
 Greg
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 To change your delivery options, retrieve your password, or unsubscribe from 
 this list, visit
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
 
 -- 
 Codetrails GmbH
 The knowledge transfer company
 
 Robert-Bosch-Str. 7, 64293 Darmstadt
 Phone: +49-6151-276-7092
 Mobile: +49-179-131-7721
 http://www.codetrails.com/
 
 Managing Director: Dr. Marcel Bruch
 Handelsregister: Darmstadt HRB 91940
 
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 To change your delivery options, retrieve your password, or unsubscribe from 
 this list, visit
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] automated error reporting

[Greg Watson]

Hi,

I’ve enabled daily digests for PTP, but we’re not seeing any emails. Is there 
something else I need to do? Does the error reporting address need to be 
subscribed to the list?

Thanks,
Greg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] PTP hudson page

[Greg Watson]

Anyone know why the PTP [1] hudson page is showing a “Hudson CI Server Initial 
Setup” screen? Has someone changed something?

Greg

1. https://hudson.eclipse.org/ptp/
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] TM participation in Mars

[Greg Watson]

Hi, 

Due to the uncertainty around RSE, it looks like we didn’t officially announce, 
so apologies in advance. TM will be participating to the Mars Simultaneous 
release, with an offset of +1. This will be version 4.0 of TM: 
https://projects.eclipse.org/projects/tools.tm/releases/4.0.0 
https://projects.eclipse.org/projects/tools.tm/releases/4.0.0. RSE will 
remain at version 3.7.

Greg

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Mars aggregation build failed due to update of TM to version 4.0

[Greg Watson]

I’m just changing the RSE versions back to 3.7. 

Greg

 On Feb 7, 2015, at 9:51 AM, Kaloyan Raev kaloya...@zend.com wrote:
 
 Hi,
 
 The TM project was updated [1] to version 4.0 on Thursday. DLTK has a 
 [3.0.0,4.0.0) dependency to TM RSE and hence the build failed. See below for 
 the log.
 
 I need to understand what is the incompatible changes in TM, so an update in 
 the major version was required. I tried to find this myself, but I cannot 
 find any record of TM 4.0 in PMI [2], or a record of TM's participation in 
 Mars [3].
 
 [1] 
 http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?id=eb8c9a7105fccc1250981067f27877712833aac9
  
 http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?id=eb8c9a7105fccc1250981067f27877712833aac9
 [2] https://projects.eclipse.org/projects/tools.tm/governance 
 https://projects.eclipse.org/projects/tools.tm/governance
 [3] https://projects.eclipse.org/releases/mars/ 
 https://projects.eclipse.org/releases/mars/
 
 Any info about what's going on will be appreciated.
 
 Thanks,
 Kaloyan
 
 -- Forwarded message --
 From: David Williams david_willi...@us.ibm.com 
 mailto:david_willi...@us.ibm.com
 Date: Sat, Feb 7, 2015 at 4:17 AM
 Subject: [marsAggregation] Failed for build 2015-02-06_21-16-34
 To: Kaloyan Raev kaloya...@zend.com mailto:kaloya...@zend.com, DLTK Build 
 Team alex.panche...@gmail.com mailto:alex.panche...@gmail.com, DLTK Build 
 Team and...@xored.com mailto:and...@xored.com
 Cc: David Williams david_willi...@us.ibm.com 
 mailto:david_willi...@us.ibm.com
 
 
 The following errors occured when building Mars:
 
 Software being installed: validationSet_main 1.0.0
 
 Only one of the following can be installed at once: 
 [org.eclipse.rse.core.feature.jar 3.4.100.201406091451, 
 org.eclipse.rse.core.feature.jar 4.0.0.201502051008]
 
 Cannot satisfy dependency: 
 mappedRepo_home_data_httpd_download.eclipse.org_technology_dltk_updates-dev_5.1.1
  1.0.0 depends on: org.eclipse.dltk.rse.feature.group 5.1.1
 
 Cannot satisfy dependency: 
 mappedRepo_home_data_httpd_download.eclipse.org_tm_updates_4.0milestones 
 1.0.0 depends on: org.eclipse.rse.feature.group 4.0.0
 
 Cannot satisfy dependency: org.eclipse.dltk.rse.feature.group 
 5.1.1.201501300504 depends on: org.eclipse.rse.core.feature.group 
 [3.0.0,4.0.0)
 
 Cannot satisfy dependency: org.eclipse.rse.core.feature.group 
 3.4.100.201406091451 depends on: org.eclipse.rse.core.feature.jar 
 [3.4.100.201406091451]
 
 Cannot satisfy dependency: org.eclipse.rse.core.feature.group 
 4.0.0.201502051008 depends on: org.eclipse.rse.core.feature.jar 
 [4.0.0.201502051008]
 
 Cannot satisfy dependency: org.eclipse.rse.feature.group 4.0.0.201502051008 
 depends on: org.eclipse.rse.core.feature.group [4.0.0.201502051008]
 
 Cannot satisfy dependency: validationSet_main 1.0.0 depends on: 
 mappedRepo_home_data_httpd_download.eclipse.org_technology_dltk_updates-dev_5.1.1
  [1.0.0]
 
 Cannot satisfy dependency: validationSet_main 1.0.0 depends on: 
 mappedRepo_home_data_httpd_download.eclipse.org_tm_updates_4.0milestones 
 [1.0.0]
 
 Check the log file for more information: 
 https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/simrel.mars.runaggregator/433/console
  
 https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/simrel.mars.runaggregator/433/console
 
 

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Gerrit down?

[Greg Watson]

Thanks.
Greg

 On Jan 14, 2015, at 5:19 PM, Stephan Herrmann stephan.herrm...@berlin.de 
 wrote:
 
 On 01/14/2015 11:11 PM, Greg Watson wrote:
 Is anyone else seeing “Service Temporarily Unavailable” for Gerrit?
 
 Yep, see 
 http://dev.eclipse.org/mhonarc/lists/eclipse.org-committers/msg01030.html
 
 Stephan
 
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 To change your delivery options, retrieve your password, or unsubscribe from 
 this list, visit
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Gerrit down?

[Greg Watson]

Is anyone else seeing “Service Temporarily Unavailable” for Gerrit?

Greg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Projects missing from Mars

[Greg Watson]

I’m fine with waiting until Jan to see if we have enough momentum. I’d be happy 
to see TM go forward with o.e.remote, the launch bar, and TM/TCF Terminal. 
Until we have someone who is willing to sign up to support and test RSE, 
though, I think it’s inclusion for Mars is problematic. If someone does sign up 
for this, I have no problem with RSE going in as well.

Greg

 On Dec 11, 2014, at 2:49 PM, Doug Schaefer dschae...@qnx.com wrote:
 
 I'm working with Greg Watson and the TM, PTP, and CDT teams to come up with a 
 new target management system based on org.eclipse.remote. All signs point to 
 that being available for Mars. Coding is underway but I'm just not ready to 
 commit at this time. Let's see what January brings. 
 
 Doug
 
 Sent from my BlackBerry 10 smartphone on the Rogers network.
 From: Wayne Beaton
 Sent: Thursday, December 11, 2014 2:29 PM
 To: Cross project issues
 Reply To: Cross project issues
 Subject: [cross-project-issues-dev] Projects missing from Mars
 
 Greetings folks.
 
 I believe that I'm caught up with the opt-in.
 
 The following projects are on the dropped list:
 Intent
 Target Management
 Data Tools Platform
 Java Workflow Tooling
 Marketplace Client
 Koneki
 Target Communication Framework
 
 Both Intent and Target Management have informed the community that they've 
 dropped out (though there is still some ongoing discussion regarding TM).
 
 The rest have not yet created a release record. I'm expecting that least two 
 of them (Data Tools and Marketplace Client) really do want to participate. 
 I'll give them all a kick.
 
 Wayne
 -- 
 Wayne Beaton
 @waynebeaton
 The Eclipse Foundation
 728X90.jpg 
 http://www.eclipsecon.org/na2015___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 To change your delivery options, retrieve your password, or unsubscribe from 
 this list, visit
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] TM withdrawal from Mars

[Greg Watson]

 On Nov 26, 2014, at 1:10 AM, Mickael Istria mist...@redhat.com wrote:
 
 On 11/25/2014 08:54 PM, Greg Watson wrote:
 we would need to determine which parts are unsupported and remove them.
 I don't understand why you want to remove things that are not actively 
 supported any more? The fact that no-one currently plans to making changes in 
 those parts doesn't make that they need to be removed. RSE is a mature 
 project, and in its current state, it provides satisfaction to some users, 
 and I believe it could easily keep on providing value without changing a 
 single line of code nor doing any rebuild. The project is still useful 
 independently of whether it has active contributors or not.

This may be the case if you are considering a project in isolation, however we 
are deciding if TM should part of a simultaneous release. Being part of the 
simultaneous release means that projects must work together in any combination 
of any install. This requires a degree of testing at least, as well as fixing 
bugs if any problems are encountered. If no-one has agreed to undertake this 
level of support, then I don’t see how the project can meet the mandatory 
requirements for a simultaneous release.

Greg

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] TM withdrawal from Mars

[Greg Watson]

The org.eclipse.remote API currently supports SSH/SFTP using JSch. There is no 
support for FTP or TELNET, however it is possible that these could be added. It 
is primarily designed to provide a programmatic interface to remote processes 
and remote filesystem access (including an EFS service), so it doesn’t provide 
a UI in the same way that RSE does. However this is discussion going on the 
tm-dev list about using the TCF Target Explorer to provide this functionality. 

Regards,
Greg

On Nov 21, 2014, at 5:19 PM, Max Rydahl Andersen mande...@redhat.com wrote:

 Looks interesting. Will need to look closer ;)
 
 Looking mainly for answers to:
 
 Is this part of Mars ?
 
 Does it support ftp ?
 
 Does it support using them as linked folders/remote file systems ?
 
 /max
 http://about.me/maxandersen
 
 
 On 21 Nov 2014, at 22:15, Denis Roy denis@eclipse.org wrote:
 
 On 11/21/2014 04:04 PM, Max Rydahl Andersen wrote:
 Got info on this org.eclipse.parralls option?
 
 http://git.eclipse.org/c/ptp/org.eclipse.remote.git/  ?
 
 
 
 Btw. I used as little as possible from tm. But the remote explorer and file 
 system support 
 I haven't found anywhere else in eclipse ecosystem so 
 If we got something in the release train that is better I'm interested. 
 
 /max
 http://about.me/maxandersen
 
 
 On 21 Nov 2014, at 21:46, Wayne Beaton wa...@eclipse.org wrote:
 
 You had me at hello.
 
 Wayne
 
 On 21/11/14 03:30 PM, Doug Schaefern   wrote:
 The fact of the matter is that RSE is an architectural nightmare. It has 
 a history as a remote environment for IBM mainframes which was super 
 overkill for what we use it for in the Linux and embedded space. Good 
 riddance IMHO.
 
 To that end, I am currently working on removing our dependency on RSE in 
 CDT and will be using the org.eclipse.remote plug-ins started by the 
 Parallel Tools folks. It’s a much simpler architecture and super easy to 
 extend. It already has support for ssh connections.
 
 Doug.
 
 From: Wayne Beaton wa...@eclipse.org
 Organization: The Eclipse Foundation
 Reply-To: Cross project issues cross-project-issues-dev@eclipse.org
 Date: Friday, November 21, 2014 at 2:51 PM
 To: cross-project-issues-dev@eclipse.org 
 cross-project-issues-dev@eclipse.org
 Subject: Re: [cross-project-issues-dev] TM withdrawal from Mars
 
 I had a similar thought. I actually use RSE. In fact, I just did a bunch 
 of work to include an adapter for my image viewer plug-in to preview 
 images via RSE (I'll share this shortly).
 
 There's no requirement for a project to make new releases for the 
 simultaneous release. There's nothing stopping a project from just 
 contributing a service release.
 
 I should think that most of the heavy lifting is done. It's perfectly 
 reasonable for a project to remain in maintenance mode.
 
 What additional resources to you believe that you require? I believe that 
 all you need to do is declare your participation and make sure that the 
 aggregation file is correct. Perhaps others can help with this.
 
 Wayne
 
 On 21/11/14 02:41 PM, Max Rydahl Andersen wrote:
 That sounds really bad :/
 This means if I grok it right that eclipse will loose its ability to 
 mount and browse Ftp and scp files systems, correct ?
 
 If that goes eclipse becomes really weak in the already remote heavy 
 access world with cloud and containers. 
 
 For one our server adapters utilizes this to support remote deployment 
 to file based servers. 
 
 What would it take for keeping rse or at least parts of it alive for 
 mars and future releases ?
 
 /max
 http://about.me/maxandersen
 On 21 Nov 2014, at 17:25, Greg Watson g.wat...@computer.org wrote:
 
 The Target Management (TM) project is comprised of two main projects: 
 Remote System Explorer (RSE) and Terminal. Only the Terminal project is 
 under active development, and there are plans currently to merge this 
 with the TCF Terminal project. We are planning to have one final 
 release of TM (3.7) to coincide with Luna SR2, and then only provide 
 service releases on an as-needed basis. As a consequence, we don’t have 
 the resources to contribute to a Mars release, so are notifying 
 everyone of our intention to withdraw from Mars. 
 
 Please let us know if there are any comments or concerns regarding this.
 
 Regards,
 Greg
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 To change your delivery options, retrieve your password, or unsubscribe 
 from this list, visit
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 To change your delivery options, retrieve your password, or unsubscribe 
 from this list, visit
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
 
 -- 
 Wayne Beaton
 @waynebeaton
 The Eclipse Foundation
 728X90.jpg

[cross-project-issues-dev] TM withdrawal from Mars

[Greg Watson]

The Target Management (TM) project is comprised of two main projects: Remote 
System Explorer (RSE) and Terminal. Only the Terminal project is under active 
development, and there are plans currently to merge this with the TCF Terminal 
project. We are planning to have one final release of TM (3.7) to coincide with 
Luna SR2, and then only provide service releases on an as-needed basis. As a 
consequence, we don’t have the resources to contribute to a Mars release, so 
are notifying everyone of our intention to withdraw from Mars. 

Please let us know if there are any comments or concerns regarding this.

Regards,
Greg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Did somebody just break git?

[Greg Watson]

Working again. Thanks!

On Aug 21, 2014, at 4:09 PM, Denis Roy denis@eclipse.org wrote:

 /gitroot wasn't mounted on one of the servers after a reboot. Try now.
 
 Denis
 
 
 On 08/21/2014 03:59 PM, Greg Watson wrote:
 When I try to view any Git repos [1],  I get the message No repositories 
 found”.
 
 Any ideas?
 Greg
 
 [1] https://git.eclipse.org/c/cdt/org.eclipse.cdt.git
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 To change your delivery options, retrieve your password, or unsubscribe from 
 this list, visit
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
 
 
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 To change your delivery options, retrieve your password, or unsubscribe from 
 this list, visit
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Did somebody just break git?

[Greg Watson]

When I try to view any Git repos [1],  I get the message No repositories 
found”. 

Any ideas?
Greg

[1] https://git.eclipse.org/c/cdt/org.eclipse.cdt.git
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] PTP participating in Mars release

[Greg Watson]

Works for me.
Greg

On Aug 19, 2014, at 10:49 AM, Wayne Beaton wa...@eclipse.org wrote:

 The project is the granularity for participation. I've put you down as a 
 solid +3 on the participation page [1].
 
 I believe that you can do what you need to do with the build aggregator (e.g. 
 split contributions if that makes sense).
 
 Wayne
 
 [1] https://projects.eclipse.org/releases/mars
 
 On 18/08/14 09:15 AM, Greg Watson wrote:
 Hi,
 
 PTP will be participating in the Mars simultaneous release. The offset for 
 PTP will be +1 for the remote component and +3 for the remainder of PTP 
 (including Photran).
 
 The release record is here: 
 https://projects.eclipse.org/projects/tools.ptp/releases/9.0.0
 
 Thanks,
 Greg
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 To change your delivery options, retrieve your password, or unsubscribe from 
 this list, visit
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
 
 
 -- 
 Wayne Beaton
 @waynebeaton
 The Eclipse Foundation
 ECE Friends 480x60.png
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 To change your delivery options, retrieve your password, or unsubscribe from 
 this list, visit
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] PTP participating in Mars release

[Greg Watson]

Hi,

PTP will be participating in the Mars simultaneous release. The offset for PTP 
will be +1 for the remote component and +3 for the remainder of PTP (including 
Photran).

The release record is here: 
https://projects.eclipse.org/projects/tools.ptp/releases/9.0.0

Thanks,
Greg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] projects page

[Greg Watson]

It appears to be broken again.

Greg

On Jul 17, 2014, at 9:09 AM, Webmaster(Matt Ward) webmas...@eclipse.org wrote:

 We added an extra node to help offset load increases on the pool of machines 
 that back projects.eclipse.org.  I've pulled it from service, and I'll talk 
 to the Webdev team about what happened with the install.
 
 -Matt.
 
 On 07/17/2014 08:14 AM, Greg Watson wrote:
 Anyone know what is going on with http://projects.eclipse.org? I’m getting 
 redirected to some kind of installation page.
 
 Greg
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 To change your delivery options, retrieve your password, or unsubscribe from 
 this list, visit
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
 
 
 
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 To change your delivery options, retrieve your password, or unsubscribe from 
 this list, visit
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] projects page

[Greg Watson]

Anyone know what is going on with http://projects.eclipse.org? I’m getting 
redirected to some kind of installation page.

Greg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] unable to complete PTP build

[Greg Watson]

Hi,

We’re unable to complete the PTP build as it is failing with the following 
errors:


ava HotSpot(TM) 64-Bit Server VM warning: INFO: 
os::commit_memory(0x00073688, 1262485504, 0) failed; error='Cannot 
allocate memory' (errno=12)
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 1262485504 bytes for 
committing reserved memory.
# An error report file with more information is saved as:
# /jobs/genie.tools.ptp/ptp-nightly-repo/workspace/hs_err_pid13307.log
[ERROR] Failure: hudson.remoting.RequestAbortedException: 
hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected 
termination of the channel
FATAL: hudson.remoting.RequestAbortedException: 
hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected 
termination of the channel

org.hudsonci.utils.tasks.OperationFailure
: hudson.remoting.RequestAbortedException: 
hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected 
termination of the channel
at 
org.hudsonci.utils.tasks.PerformOperation.execute(PerformOperation.java:64)

at 
org.hudsonci.maven.plugin.builder.MavenBuilder.perform(MavenBuilder.java:169)

at 
hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:34)

at 
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:646)

at 
hudson.model.Build$RunnerImpl.build(Build.java:181)

at 
hudson.model.Build$RunnerImpl.doRun(Build.java:136)

at 
hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:434)

at 
hudson.model.Run.run(Run.java:1390)

at 
hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:40)

at 
hudson.model.ResourceController.execute(ResourceController.java:82)

at 
hudson.model.Executor.run(Executor.java:137)

Caused by: 
hudson.remoting.RequestAbortedException
: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected 
termination of the channel
at 
hudson.remoting.Request.call(Request.java:142)

at 
hudson.remoting.Channel.call(Channel.java:643)

at 
org.hudsonci.maven.plugin.builder.internal.PerformBuild.doExecute(PerformBuild.java:198)

at 
org.hudsonci.utils.tasks.PerformOperation.execute(PerformOperation.java:50)

... 10 more
Caused by: 
hudson.remoting.RequestAbortedException
: java.io.IOException: Unexpected termination of the channel
at 
hudson.remoting.Request.abort(Request.java:262)

at 
hudson.remoting.Channel.terminate(Channel.java:743)

at 
hudson.slaves.Channels$1.terminate(Channels.java:71)

at 
hudson.remoting.Channel$ReaderThread.run(Channel.java:1042)

Caused by: 
java.io.IOException
: Unexpected termination of the channel
at 
hudson.remoting.Channel$ReaderThread.run(Channel.java:1023)

Caused by: 
java.io.EOFException

at 
java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2598)

at 
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1318)

at 
java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)

at 
hudson.remoting.Channel$ReaderThread.run(Channel.java:1017)


Powered by Hudson Open Source Continuous Integration Server from the Eclipse 
Foundation
Instance: PTP
___
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] unable to complete PTP build

[Greg Watson]

It seems to have fixed itself…

Greg

On Jun 10, 2014, at 6:08 PM, Greg Watson g.wat...@computer.org wrote:

 Hi,
 
 We’re unable to complete the PTP build as it is failing with the following 
 errors:
 
 
 ava HotSpot(TM) 64-Bit Server VM warning: INFO: 
 os::commit_memory(0x00073688, 1262485504, 0) failed; error='Cannot 
 allocate memory' (errno=12)
 #
 # There is insufficient memory for the Java Runtime Environment to continue.
 # Native memory allocation (malloc) failed to allocate 1262485504 bytes for 
 committing reserved memory.
 # An error report file with more information is saved as:
 # /jobs/genie.tools.ptp/ptp-nightly-repo/workspace/hs_err_pid13307.log
 [ERROR] Failure: hudson.remoting.RequestAbortedException: 
 hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected 
 termination of the channel
 FATAL: hudson.remoting.RequestAbortedException: 
 hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected 
 termination of the channel
 
 org.hudsonci.utils.tasks.OperationFailure
 : hudson.remoting.RequestAbortedException: 
 hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected 
 termination of the channel
   at 
 org.hudsonci.utils.tasks.PerformOperation.execute(PerformOperation.java:64)
 
   at 
 org.hudsonci.maven.plugin.builder.MavenBuilder.perform(MavenBuilder.java:169)
 
   at 
 hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:34)
 
   at 
 hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:646)
 
   at 
 hudson.model.Build$RunnerImpl.build(Build.java:181)
 
   at 
 hudson.model.Build$RunnerImpl.doRun(Build.java:136)
 
   at 
 hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:434)
 
   at 
 hudson.model.Run.run(Run.java:1390)
 
   at 
 hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:40)
 
   at 
 hudson.model.ResourceController.execute(ResourceController.java:82)
 
   at 
 hudson.model.Executor.run(Executor.java:137)
 
 Caused by: 
 hudson.remoting.RequestAbortedException
 : hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected 
 termination of the channel
   at 
 hudson.remoting.Request.call(Request.java:142)
 
   at 
 hudson.remoting.Channel.call(Channel.java:643)
 
   at 
 org.hudsonci.maven.plugin.builder.internal.PerformBuild.doExecute(PerformBuild.java:198)
 
   at 
 org.hudsonci.utils.tasks.PerformOperation.execute(PerformOperation.java:50)
 
   ... 10 more
 Caused by: 
 hudson.remoting.RequestAbortedException
 : java.io.IOException: Unexpected termination of the channel
   at 
 hudson.remoting.Request.abort(Request.java:262)
 
   at 
 hudson.remoting.Channel.terminate(Channel.java:743)
 
   at 
 hudson.slaves.Channels$1.terminate(Channels.java:71)
 
   at 
 hudson.remoting.Channel$ReaderThread.run(Channel.java:1042)
 
 Caused by: 
 java.io.IOException
 : Unexpected termination of the channel
   at 
 hudson.remoting.Channel$ReaderThread.run(Channel.java:1023)
 
 Caused by: 
 java.io.EOFException
 
   at 
 java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2598)
 
   at 
 java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1318)
 
   at 
 java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
 
   at 
 hudson.remoting.Channel$ReaderThread.run(Channel.java:1017)
 
 
 Powered by Hudson Open Source Continuous Integration Server from the Eclipse 
 Foundation
 Instance: PTP
 ___
 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] Missing legal files

[Greg Watson]

Object not found!

The requested URL was not found on this server. If you entered the URL manually 
please check your spelling and try again.

If you think this is a server error, please contact the webmaster.

Error 404

build.eclipse.org
Wed Jun 4 15:07:01 2014
Apache

On Jun 4, 2014, at 11:45 AM, Wayne Beaton wa...@eclipse.org wrote:

 Some projects are missing required legal files in downloads.
 
 The master list is here:
 
 http://build.eclipse.org/simrel/luna/reporeports/reports/layoutCheck.txt
 
 I've contacted representatives from each project separately. This needs to be 
 addressed.
 
 Thanks for your attention in this matter.
 
 PMC-approved review materials are due today.
 
 Wayne
 -- 
 Wayne Beaton
 Director of Open Source Projects, The Eclipse Foundation
 Learn about Eclipse Projects
 eclipsecon-480x60.jpg
 ___
 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] Missing legal files

[Greg Watson]

Wow man, cosmic :-) It’s working for me too now.

Greg

On Jun 4, 2014, at 3:16 PM, Denis Roy denis@eclipse.org wrote:

 It works now.  I guess Greg and I had an unusual cosmic connection and we 
 both tried at the same time.
 
 
 
 On 06/04/2014 03:14 PM, Wayne Beaton wrote:
 Works for me.
 
 Maybe there was a build in progress?
 
 Wayne
 
 On 06/04/2014 03:08 PM, Denis Roy wrote:
 Am I the only one getting a 404 on that URL?
 
 Denis
 
 On 06/04/2014 11:45 AM, Wayne Beaton wrote:
 Some projects are missing required legal files in downloads.
 
 The master list is here:
 
 http://build.eclipse.org/simrel/luna/reporeports/reports/layoutCheck.txt
 
 I've contacted representatives from each project separately. This needs to 
 be addressed.
 
 Thanks for your attention in this matter.
 
 PMC-approved review materials are due today.
 
 Wayne
 
 
 
 
 ___
 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] PTP may be late for +2

[Greg Watson]

Due to a late change in CDT [1] that has broken the PTP build, we may not be 
able to make the +2 deadline. It's hard to estimate when this will be fixed, as 
I've only just started looking at this, so I don't know the extent of the 
changes that will be necessary.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=303083
___
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] IP Logs for Luna are due tomorrow

[Greg Watson]

The Parallel Tools Platform (PTP) Committers link does nothing when I click 
on it (in Safari).

Greg

On May 22, 2014, at 8:43 PM, Wayne Beaton wrote:

 The IP Log generator is not itself part of the PMI (though I do have a new 
 PMI-based implementation almost ready for deployment; more on that later).
 
 At the bottom of your project's PMI page, if you are logged in as a project 
 committer, you should see a tray with a project Committers item. Click 
 that. In that list, you'll see an option to open the IP Log generator. It 
 will take you to the right place.
 
 If your project's release includes subprojects (e.g. Eclipse or Web Tools), 
 open the PMI record for the release and open the tray item to select the IP 
 Log entry for the release (it will automatically open the IP Log generator 
 including the subprojects participating in your release).
 
 I hope this makes sense. I'm feeling a little dozy myself...
 
 Wayne
 
 On 05/22/2014 03:47 PM, Ed Willink wrote:
 Hi
 
 I must be dozy.
 
 I thought the IP tool had moved from the portal to the PMI, but I can't find 
 it in either location.
 
 Regards
 
 Ed Willink
 
 On 22/05/2014 20:36, Wayne Beaton wrote:
 Greetings folks.
 
 Gentle reminder that IP Logs for Luna are due tomorrow.
 
 If circumstances require an extension, please let me know ASAP.
 
 Thanks,
 
 Wayne
 -- 
 Wayne Beaton
 Director of Open Source Projects, The Eclipse Foundation
 Learn about Eclipse Projects
 Mail Attachment.jpeg
 
 
 ___
 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: 2014.0.4592 / Virus Database: 3950/7542 - Release Date: 05/22/14
 
 
 
 
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
 
 -- 
 Wayne Beaton
 Director of Open Source Projects, The Eclipse Foundation
 Learn about Eclipse Projects
 eclipsecon-480x60.jpg
 ___
 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] TM may be late for Luna M4

[Greg Watson]

The RSE component of TM was relying on some internal platform classes that were 
recently removed. This is causing build problems, so TM may be late for M4. 
Please see https://bugs.eclipse.org/bugs/show_bug.cgi?id=422844 for details.

Regards,
Greg
___
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] PTP Participating in Luna

[Greg Watson]

The PTP project will be participating in the Luna simultaneous release at an 
offset of +2. The release record can be found here [1].

[1] https://projects.eclipse.org/projects/tools.ptp/releases/8.0.0/plan

Regards,
Greg
___
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 Luna M1

[Greg Watson]

Thanks!

On Aug 21, 2013, at 3:39 PM, David Dykstal david_dyks...@us.ibm.com wrote:

 It exists now. 
 http://download.eclipse.org/tm/updates/3.6milestones/ 
 
 -- David Dykstal,  Architect - Rational Developer for i 
 
 
 
 From:Greg Watson g.wat...@computer.org 
 To:Cross project issues cross-project-issues-dev@eclipse.org, 
 Date:08/21/2013 01:45 PM 
 Subject:Re: [cross-project-issues-dev] Status and outlook for Luna M1 
 Sent by:cross-project-issues-dev-boun...@eclipse.org 
 
 
 
 Does TM have a luna repo somewhere? I can't seem to find one.
 
 Thanks,
 Greg
 
 On Aug 21, 2013, at 1:14 PM, David Dykstal ddykstal.ecli...@gmail.com wrote:
 
  I have enabled TM.
  
  Doug Schaefer wrote:
  Sigh. RSE isn't enabled so CDT fails.
  
  ___
  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] Ready for Luna (M1) aggregation

[Greg Watson]

Does anyone know if CDT will be enabled for M1? We can't enable PTP without CDT.

Thanks,
Greg

On Aug 9, 2013, at 10:06 AM, David M Williams david_willi...@us.ibm.com wrote:

 I hope everyone has enjoyed their summer vacations ... but now back to work! 
 :) 
 
 We do have a preliminary schedule for Luna milestones, see 
 http://wiki.eclipse.org/Luna/Simultaneous_Release_Plan#Schedule 
 (though, that one table is only part of that document to review, at the 
 moment). 
 
 The complete schedule is still open for review and tweaking, but the first 
 several milestones are pretty much a given, and the first one is due in two 
 weeks! The overall schedule (of having approximately 6 week milestones) is 
 pretty much just like previous years. The one main difference is that we 
 moved up M5 and M6 to make sure M6 finished before EclipseCon 2014 started 
 (so ... we don't allow an extra week for end-of-year holidays) and this M5 
 and M6 change means M7 is a week longer than usual: 8 weeks instead of 7! 
 
 As always, we hope everyone in 'kepler' stays in 'luna', but ... to make sure 
 ... we require explicit buy in. In practice, this means I started the 
 'master' branch with what ever it was for Kepler, but then set 
 enabled=false for everyone's contribution.  If you plan to be in Luna, 
 please removed the enabled=false from your contribution element. If you 
 are not quite ready to actually make a contribution, you can put 
 enabled=false in your repository element to signify the difference of 
 planning to participate, but contribution not ready yet. If nothing else, 
 you may simply have to wait until your pre-reqs make their contributions. 
 
 I have enabled the contributions for Eclipse and Equinox (with out likely 
 Luna M1 content), and produced a preliminary staging repo ... which has 
 only those two projects in it, at the moment. 
 
 Let the fun begin! As always, questions to this list are welcome. 
 
 ___
 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] Are too many packages actually hurting Eclipse?

[Greg Watson]

On Jul 30, 2013, at 6:13 AM, Konstantin Komissarchik 
konstantin.komissarc...@oracle.com wrote:

  so they are actually useful to end-users.
  
 Actually, we have no evidence that users find packages useful. They download 
 them because what else is there for them to do. Then if they are experienced, 
 they know what’s included and how to install the missing pieces. If not, they 
 thrash on forums wondering why Eclipse for Java Developers doesn’t come with 
 an XML editor.

In the parallel computing community, we have plenty of evidence that the 
package is useful. We get lots of feedback that our all-in-one package is much 
preferred over having to install packages into Eclipse. Our users did this for 
years and it was a never ending source of complaints.

However, if the process was changed to downloading Eclipse, then when you first 
started Eclipse it displayed a screen that said something like What would you 
like to use Eclipse for, then presented a list similar to the current list of 
packages, then our users would probably still be happy.

I wouldn't support the idea of creating a single download with the entire 
aggregated repository at all. Apart from being huge, it would contain many 
features that users would never use, but would add to the feature bloat and UI 
confusion. This is exactly the opposite of where we should be heading. Users 
have been saying for years that they want a simpler and more functional UI, so 
we should be focussing on how to make this happen.

Regards,
Greg___
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/git problem

[Greg Watson]

I'm getting read timed out pushing to git via gerrit. Is there a problem with 
either server?

Greg
___
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] bad gateway

[Greg Watson]

Hi,

I'm getting Bad Gateway messages when I try to access hudson. Is anybody else 
seeing this?

Greg
___
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] 6 month release cycle

[Greg Watson]

While I support more frequent release cycles (PTP release more frequently so it 
would suit us well), I'd like to also suggest that projects also have more 
control over the packages available on the download site. In particular, we'd 
like to be able to update our package with a new build when we bring out a bug 
fix release so that new users don't need to update the package as soon as they 
download it. If you're interested in discussing this more, I've opened bug 
412864 on this issue.

Greg

On Jul 2, 2013, at 3:30 PM, Doug Schaefer dschae...@qnx.com wrote:

 Hey gang,
 
 We have a discussion going in the CDT community and we are currently planning 
 out how to achieve a 6 month release cycle. The feeling is that we need to 
 get new features out faster to our users. The year long wait we currently 
 have is making releases sluggish and I fear it's slowing down growth in our 
 community. A 6 month cycle should infuse us with a little more energy, so 
 goes the hope.
 
 I mentioned CDT's plans on twitter and a number of senior members of our 
 larger Eclipse community thought it might be a good idea for other projects 
 at Eclipse and maybe for the train itself. And I think so too.
 
 Instead of continuing that discussion on twitter, which is fun and 
 everything, I thought we should bring that to a greater audience and see what 
 other projects thought and whether it's something we should bring to the 
 Planning Council and the rest of the EMO.
 
 I know there are a number of projects already releasing off stream during the 
 year, but bringing things together more often might be a help to many others. 
 But I'd like to hear your thoughts on that.
 
 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

[cross-project-issues-dev] hudson problem

[Greg Watson]

It looks like hudson has a problem:

Started by user gwatson
Building remotely on hudson-slave2
Checkout:ptp-nightly / /opt/buildhomes/hudsonBuild/workspace/ptp-nightly - 
hudson.remoting.Channel@3e125554:hudson-slave2
Using strategy: Default
Last Built Revision: Revision 65855817ce0f1da63d0d6b536ebdb89da404180b 
(origin1/master)
FATAL: cannot assign instance of hudson.EnvVars to field 
hudson.plugins.git.GitSCM$3.val$environment of type hudson.EnvVars in instance 
of hudson.plugins.git.GitSCM$3

java.lang.ClassCastException
: cannot assign instance of hudson.EnvVars to field 
hudson.plugins.git.GitSCM$3.val$environment of type hudson.EnvVars in instance 
of hudson.plugins.git.GitSCM$3
at 
java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2032)

at 
java.io.ObjectStreamClass.setObjFieldValues(ObjectStreamClass.java:1212)

at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1953)

at 
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)

at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)

at 
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)

at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)

at 
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)

at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)

at 
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)

at 
java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)

at 
hudson.remoting.UserRequest.deserialize(UserRequest.java:178)

at 
hudson.remoting.UserRequest.perform(UserRequest.java:98)

at 
hudson.remoting.UserRequest.perform(UserRequest.java:48)

at 
hudson.remoting.Request$2.run(Request.java:283)

at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)

at 
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)

at 
java.util.concurrent.FutureTask.run(FutureTask.java:138)

at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

at 
java.lang.Thread.run(Thread.java:619)
___
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] IP Logs were due last Friday

[Greg Watson]

Wayne,

I clicked on some of the jar files that were flagged in the tools.ptp project 
and they appear to be from releases from years ago (such as 1.0 and galileo). 
Is there any way to turn these off, or otherwise how should these be dealt with?

Regards,
Greg

On May 29, 2013, at 6:58 PM, Wayne Beaton wa...@eclipse.org wrote:

 Greetings folks.
 
 Most projects have submitted their Kepler IP Logs for review. If you have 
 submitted your IP Log, please accept my thanks. But keep reading, there's 
 some good stuff below.
 
 The deadline to submit IP Logs for Kepler was last Friday. If you have not 
 yet submitted your IP log, you are late. Being late has a downstream effect 
 that and adds stress to the process. If you have not already done so, please 
 make it happen ASAP.
 
 The deadline to submit your PMC-approved review materials to EMO is June 
 5/2013. Earlier is fine (better, even). Send me the document, or a link to 
 the document along with a link to the public approval discussion with your 
 PMC. Please do not be late. Let me know if you require assistance. 
 
 Please take a minute to use the Download Review tool (e.g. [1]) to review 
 your project downloads before submitting your IP Log. Note that I've added a 
 handy Review Downloads link on project pages in the PMI (you need to be 
 logged in as a project committer). I use this tool as part of the review that 
 I do before handing the log off to the IP team to complete the review.
 
 This page displays the result of scanning your project's download directory 
 for JAR files. It scans the file structure itself as well as the contents of 
 any ZIP, JAR, and WAR files it finds (I only just added support for nested 
 JARs in JAR files). The scan runs weekly on Friday afternoon. Contact me 
 directly via email if you want me to manually invoke the scan.
 
 The tool is not perfect, but it is generally useful for most projects (it 
 fails miserably on the Eclipse project due--I believe--to the shear size of 
 its download directory). It does sometimes report reasonable files as 
 potential problems (this deficiency is noted on the page itself). 
 
 To function, the tool depends on a mapping from CQ to bundle file name 
 pattern that I maintain. I update the mapping whenever I discover a bundle 
 pattern that's not covered. The tool currently only considers the absolute 
 file name, so it incorrectly identifies JARs that do not have version 
 information in their name as potential issues (many 'ant' files for example). 
 A future version--that considers the full file path--will reduce the number 
 of false hits.
 
 It also attempts to identify the inclusion of bundles from other Eclipse 
 projects (and their corresponding third-party libraries) based on file paths. 
 Some reports do include 'org.eclipse.*' hits in cases that the project is 
 difficult to determine from the bundle name (the generally happens when a 
 project does not follow the convention of using their project short name as 
 the third segment in bundles). I have another mapping for exceptions that I 
 update periodically. I'm considering adding an entry in the project metadata 
 to allow projects to explicitly specify bundle patterns that belong them.
 
 Please take a few minutes to review the project downloads 
 every-once-in-a-while. There should almost never be a legitimate missing CQ 
 warning in the report. The only case in which this should happen is if the 
 project has been given parallel IP check in permission for a library in 
 advance of full approval of the CQ.
 
 HTH,
 
 Wayne
 
 [1] http://www.eclipse.org/projects/tools/downloads.php?id=technology.dltk
 -- 
 Wayne Beaton
 Director of Open Source Projects, The Eclipse Foundation
 Learn about Eclipse Projects
 Mail Attachment.html
 ___
 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 RC1 ... its going to be a late night!

[Greg Watson]

On May 22, 2013, at 11:43 PM, David M Williams david_willi...@us.ibm.com 
wrote:

 There's no change in policy. Projects choose to be in the (our) common repo. 
 Part of that is to provide valid input to the build. Normally the tools work 
 well to send out notifications for problems. Occasionally the contributed 
 input is so bad that the tool can't even read it well enough to find the 
 email addresses. You can wait until someone tells you that, if you'd like. 
 But, as tonight, sometimes that takes 3 or 4 hours (or longer) for someone 
 else to notice. As you said, you were waiting for a build ... how long 
 would you wait before you looked at 
 https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/simrel.kepler.runaggregator/
  ? 

I looked at it and the error was exec returned: 13. How am I supposed to know 
that this is related to ptp? Is your expectation that I should dig into how it 
works to determine what is causing this problem? I don't think so.

 
 The automatic notifications may be deceptive, because they say they are from 
 me  but  its all automated. I do not send them. I do not even see 
 most of them ... at least, usually, until after the contributors have already 
 fixed their problem. If it fails so badly that it can not find email 
 addresses, I get an RSS notification that the Hudson failed. But, you may be 
 surprised to hear, I am not on-line monitoring that queue 24 hours a day! 

Come on David, you said that it was ptp breaking the builds... and you 
...spent an extra hour of my time fixing that. So you obviously knew there 
was a problem, but chose not to inform anyone about it.

 
 And, I'll be blunt, I'm sensitive to this for the PTP project, because 
 similar things have happened several times before, most recently in M7... 
 also last minute. (I know, I know, you were on vacation then :) 
 
 But, I somehow how get the impression your project has not yet learned the 
 convenience of using the b3 aggregator editor, a requirement that is well 
 documented in 
 http://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build 
 Maybe it should be named the b3 repository interactive compiler and you'd 
 have a different impression of it :)  But seriously, you say you have no 
 idea how the aggregation works. Well, if you want to know, here it is: it 
 works just like p2 installing software ... and does a few extra quality 
 checks.  And, if it can read the addresses, it sends email if it can not 
 install someone's contribution. That's about it. 
 
 If I may, I'll quote another contributor who recently learned to use it ... 
 that is, after I suggested him to use the validate and validate aggregation 
 functions ... 
  Sure enough I am impressed :-) That was easy and it does stuff :-)  

Actually the change was made using the b3 aggregation editor. I was going to 
make the change by hand because the editor doesn't appear to work for me in 
kepler, but Beth insisted on using it. So whatever went wrong was caused by 
your own tools.

 
 I hope a few of my comments are constructive and encouraging, I don't mean to 
 argue about it. 
 
 But, I am pretty firm about schedules. And you've not answered any of my 
 original questions (except to provide a bug number), so if you'd like an 
 exception, I'll ask you go through the full Planning Council exception 
 process: 
 http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Planning_Council_Exception_Process
  
 (And, BTW, I'm not blind to the fact that is it a very bad bug ... but ... at 
 the time of this writing, it doesn't say very much, such as what the fix is, 
 if there are workarounds, etc. 

Although the fix has zero chance of affecting anyone, I don't think it's worth 
the chance that there will be build problems at this late stage.

 
 Seriously, thanks for your comments and and thanks for your contributions to 
 Eclipse. 
   
 
 
 
 
 From:Greg Watson g.wat...@computer.org 
 To:Cross project issues cross-project-issues-dev@eclipse.org, 
 Date:05/22/2013 10:28 PM 
 Subject:Re: [cross-project-issues-dev] Status and outlook for RC1 
...itsgoing to be a late night! 
 Sent by:cross-project-issues-dev-boun...@eclipse.org 
 
 
 
 David, 
 
 Somewhat late at night to be arguing, but I find this statement perplexing: 
 
 All projects are responsible for making sure the build works, notified or 
 not.   
 
 I have no idea how the aggregation works, nor have I seen any policy that 
 indicates that I need to. I'm happy to take responsibility for our repo, but 
 I think those responsible for the aggregation are also responsible for 
 contacting projects if there are any problems. Isn't this is why we are 
 listed as contacts in the simrel.b3aggr file, after all?  As far as I'm 
 aware, this is how it has worked in the past. Are you proposing a change to 
 the process? 
 
 Greg 
 ___
 cross

Re: [cross-project-issues-dev] Status and outlook for RC1 ... its going to be a late night!

[Greg Watson]

David,

BTW, I do appreciate all the work you do to ensure the releases are successful. 
It can be a bit frustrating when things don't go quite right, so we need to all 
work together to ensure that everything goes as smoothly as possible.

Cheers,
Greg


On May 23, 2013, at 7:38 AM, Greg Watson g.wat...@computer.org wrote:

 
 On May 22, 2013, at 11:43 PM, David M Williams david_willi...@us.ibm.com 
 wrote:
 
 There's no change in policy. Projects choose to be in the (our) common repo. 
 Part of that is to provide valid input to the build. Normally the tools work 
 well to send out notifications for problems. Occasionally the contributed 
 input is so bad that the tool can't even read it well enough to find the 
 email addresses. You can wait until someone tells you that, if you'd like. 
 But, as tonight, sometimes that takes 3 or 4 hours (or longer) for someone 
 else to notice. As you said, you were waiting for a build ... how long 
 would you wait before you looked at 
 https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/simrel.kepler.runaggregator/
  ? 
 
 I looked at it and the error was exec returned: 13. How am I supposed to 
 know that this is related to ptp? Is your expectation that I should dig into 
 how it works to determine what is causing this problem? I don't think so.
 
 
 The automatic notifications may be deceptive, because they say they are from 
 me  but  its all automated. I do not send them. I do not even see 
 most of them ... at least, usually, until after the contributors have 
 already fixed their problem. If it fails so badly that it can not find email 
 addresses, I get an RSS notification that the Hudson failed. But, you may be 
 surprised to hear, I am not on-line monitoring that queue 24 hours a day! 
 
 Come on David, you said that it was ptp breaking the builds... and you 
 ...spent an extra hour of my time fixing that. So you obviously knew there 
 was a problem, but chose not to inform anyone about it.
 
 
 And, I'll be blunt, I'm sensitive to this for the PTP project, because 
 similar things have happened several times before, most recently in M7... 
 also last minute. (I know, I know, you were on vacation then :) 
 
 But, I somehow how get the impression your project has not yet learned the 
 convenience of using the b3 aggregator editor, a requirement that is well 
 documented in 
 http://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build 
 Maybe it should be named the b3 repository interactive compiler and you'd 
 have a different impression of it :)  But seriously, you say you have no 
 idea how the aggregation works. Well, if you want to know, here it is: it 
 works just like p2 installing software ... and does a few extra quality 
 checks.  And, if it can read the addresses, it sends email if it can not 
 install someone's contribution. That's about it. 
 
 If I may, I'll quote another contributor who recently learned to use it ... 
 that is, after I suggested him to use the validate and validate aggregation 
 functions ... 
  Sure enough I am impressed :-) That was easy and it does stuff :-)  
 
 Actually the change was made using the b3 aggregation editor. I was going to 
 make the change by hand because the editor doesn't appear to work for me in 
 kepler, but Beth insisted on using it. So whatever went wrong was caused by 
 your own tools.
 
 
 I hope a few of my comments are constructive and encouraging, I don't mean 
 to argue about it. 
 
 But, I am pretty firm about schedules. And you've not answered any of my 
 original questions (except to provide a bug number), so if you'd like an 
 exception, I'll ask you go through the full Planning Council exception 
 process: 
 http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Planning_Council_Exception_Process
  
 (And, BTW, I'm not blind to the fact that is it a very bad bug ... but ... 
 at the time of this writing, it doesn't say very much, such as what the fix 
 is, if there are workarounds, etc. 
 
 Although the fix has zero chance of affecting anyone, I don't think it's 
 worth the chance that there will be build problems at this late stage.
 
 
 Seriously, thanks for your comments and and thanks for your contributions to 
 Eclipse. 
   
 
 
 
 
 From:Greg Watson g.wat...@computer.org 
 To:Cross project issues cross-project-issues-dev@eclipse.org, 
 Date:05/22/2013 10:28 PM 
 Subject:Re: [cross-project-issues-dev] Status and outlook for RC1
 ...itsgoing to be a late night! 
 Sent by:cross-project-issues-dev-boun...@eclipse.org 
 
 
 
 David, 
 
 Somewhat late at night to be arguing, but I find this statement perplexing: 
 
 All projects are responsible for making sure the build works, notified or 
 not.   
 
 I have no idea how the aggregation works, nor have I seen any policy that 
 indicates that I need to. I'm happy to take responsibility for our repo, but 
 I think those responsible

Re: [cross-project-issues-dev] Status and outlook for RC1 ... its going to be a late night!

[Greg Watson]

David,

We have a breaking issue that was just fixed, and our build is currently 
running. I'd like to request a respin at 10pm if possible.

Thanks,
Greg

On May 22, 2013, at 8:00 PM, David M Williams david_willi...@us.ibm.com wrote:

 Builds have been failing this afternoon, lots of contributions made. No 
 notices sent for failures. 
 I finally took a look and discovered an empty feature in ptp.b3aggrecon 
 file: 
 
 features 
   categories 
 href=simrel.b3aggr#//@customCategories[identifier='General%20Purpose%20Tools']/
  
 /features 
 
 So, not sure if something was supposed to be there ... but, it's gone now. 
 
 I hope that will allow the aggregator to run to completion and if not, at 
 least perhaps provide an error message. 
 
 I've discovered it gets very confused about empty features, probably 
 especially when naming a category. 
 
 If things go smooth ... we might have our RC1 staging by 10 PM. If not smooth 
 ... then ... some time after that. 
 
 Thanks, 
 ___
 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 RC1 ... its going to be a late night!

[Greg Watson]

David,

Somewhat late at night to be arguing, but I find this statement perplexing:

 All projects are responsible for making sure the build works, notified or 
 not.   

I have no idea how the aggregation works, nor have I seen any policy that 
indicates that I need to. I'm happy to take responsibility for our repo, but I 
think those responsible for the aggregation are also responsible for contacting 
projects if there are any problems. Isn't this is why we are listed as contacts 
in the simrel.b3aggr file, after all?  As far as I'm aware, this is how it has 
worked in the past. Are you proposing a change to the process?

Greg

___
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] build problems

[Greg Watson]

We're seeing this error on hudson. Is anyone else having problems?

Thanks,
Greg

[INFO] Building zip: 
https://hudson.eclipse.org/hudson/job/ptp-master-nightly/ws/target/packed/org.eclipse.ptp.master-7.0.0-SNAPSHOT.zip-after-removing.zip
[ERROR] 
org.apache.maven.plugin.MojoFailureException: Unable to create the directory 
/home/data/httpd/download-staging.priv/tools/ptp/f742444f-87c5-4c0a-9053-446c4f033da7
at 
org.eclipse.dash.m4e.eclipse.signing.SignMojo.signLocally(SignMojo.java:199)
at 
org.eclipse.dash.m4e.eclipse.signing.SignMojo.execute(SignMojo.java:167)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 5:03.426s
[INFO] Finished at: Thu Apr 18 22:26:48 EDT 2013
[INFO] Final Memory: 166M/1720M
[INFO] 
[INFO] o.h.m.e.h.MavenExecutionResultHandler - Build failed with exception(s)
[INFO] o.h.m.e.h.MavenExecutionResultHandler - [1] 
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.eclipse.dash.maven:eclipse-signing-maven-plugin:1.0.5:sign (sign) on 
project org.eclipse.ptp.master: Unable to create the directory 
/home/data/httpd/download-staging.priv/tools/ptp/f742444f-87c5-4c0a-9053-446c4f033da7
[DEBUG] Closing connection to remote
[ERROR] Failed to execute goal 
org.eclipse.dash.maven:eclipse-signing-maven-plugin:1.0.5:sign (sign) on 
project org.eclipse.ptp.master: Unable to create the directory 
/home/data/httpd/download-staging.priv/tools/ptp/f742444f-87c5-4c0a-9053-446c4f033da7
 - [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[DEBUG] Waiting for process to finish
[DEBUG] Result: 1
Archiving artifacts
___
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 down?

[Greg Watson]

Hi,

I'm getting Bad Gateway trying to connect to hudson.eclipse.org. Anyone else 
seeing this?

Greg
___
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 Final Juno SR2

[Greg Watson]

PTP may be late depending on a resolution of an RSE regression issue.

Regards,
Greg

On Feb 12, 2013, at 2:50 PM, David M Williams david_willi...@us.ibm.com wrote:

 Its been a pretty quiet RC4 week! Just wanted to send a reminder that final 
 contributions are due tomorrow, 2/13, 5 PM (with final EPP packages done by 
 Friday). 
 
 And then begins quiet week. While there is no specific document for Final 
 Daze for maintenance releases, the release engineers among you should 
 re-read 
 
 http://wiki.eclipse.org/Juno/Final_Daze 
 
 to be reminded of the concepts (e.g. leave builds/repos invisible until the 
 release date, 2/22). 
 
 Thanks, 
   
 ___
 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 Final Juno SR2

[Greg Watson]

PTP is rebuilding now. Should be finished by around 7:30pm.

Thanks!

On Feb 12, 2013, at 6:39 PM, David Dykstal david_dyks...@us.ibm.com wrote:

 David Williams -- 
 
 The TM RC4 contribution has been updated to supply a fix for PTP. We now have 
 RC4b. Is this all the notice you need? 
 
 -- David Dykstal,  Architect - Rational Developer for Power Systems 
 
 
 
 From:David Dykstal/Rochester/IBM@IBMUS 
 To:Cross project issues cross-project-issues-dev@eclipse.org, 
 Date:02/12/2013 03:00 PM 
 Subject:Re: [cross-project-issues-dev] Status and outlook for Final 
 Juno SR2 
 Sent by:cross-project-issues-dev-boun...@eclipse.org 
 
 
 
 Where would we be without some excitement? We're have a fix and are 
 attempting a rebuild if Hudson will cooperate. We'll then resubmit our RC4 
 contribution. 
 
 -- David Dykstal,  Architect - Rational Developer for Power Systems 
 
 
 
 From:Greg Watson g.wat...@computer.org 
 To:Cross project issues cross-project-issues-dev@eclipse.org, 
 Date:02/12/2013 02:10 PM 
 Subject:Re: [cross-project-issues-dev] Status and outlook for Final 
 Juno SR2 
 Sent by:cross-project-issues-dev-boun...@eclipse.org 
 
 
 
 PTP may be late depending on a resolution of an RSE regression issue. 
 
 Regards, 
 Greg 
 
 On Feb 12, 2013, at 2:50 PM, David M Williams david_willi...@us.ibm.com 
 wrote: 
 
 Its been a pretty quiet RC4 week! Just wanted to send a reminder that final 
 contributions are due tomorrow, 2/13, 5 PM (with final EPP packages done by 
 Friday). 
 
 And then begins quiet week. While there is no specific document for Final 
 Daze for maintenance releases, the release engineers among you should 
 re-read 
 
 http://wiki.eclipse.org/Juno/Final_Daze 
 
 to be reminded of the concepts (e.g. leave builds/repos invisible until the 
 release date, 2/22). 
 
 Thanks, 
 
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
 
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] aggregation conflict of TM Terminal with PTP

[Greg Watson]

This should be fixed. Rebuilding now.
Greg

On Feb 4, 2013, at 4:54 AM, Oberhuber, Martin 
martin.oberhu...@windriver.com wrote:

 It looks like org.eclipse.ptp.remote.terminal has an “includes” statement for 
 the Terminal with an old version:
  
 cd 
 /home/data/httpd/download.eclipse.org/tools/ptp/builds/kepler/milestones/M5/features
 unzip -p org.eclipse.ptp.remote.terminal_7.0.0.201301162143.jar feature.xml
 ?xml version=1.0 encoding=UTF-8?
 feature
   id=org.eclipse.ptp.remote.terminal
   label=%featureName
   version=7.0.0.201301162143
   provider-name=%providerName
 […]
includes
  id=org.eclipse.tm.terminal
  version=3.2.0.201205300905-41-312316411A16/
includes
  id=org.eclipse.tm.terminal.view
  version=2.3.0.201205300905-32-312316411A16/
  
 I’m not sure what’s the best way resolving this. It might work if PTP simply 
 builds after TM
 (assuming that it can pull in the TM milestone contribution).
  
 There used to be some conversation about “includes” vs “requires” of 
 features, and I seem
 To remember that “requires” was always considered better…
  
 Thanks,
 Martin
 --
 Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River
 direct +43.662.457915.85  fax +43.662.457915.6
  
 From: cross-project-issues-dev-boun...@eclipse.org 
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David 
 Dykstal
 Sent: Sunday, February 03, 2013 7:51 PM
 To: cross-project-issues-dev@eclipse.org
 Subject: [cross-project-issues-dev] aggregation conflict of TM Terminal with 
 PTP
  
 I get the following problem when validating the TM M5 contribution for 
 Kepler. It appears that PTP has a strict requirement for a particular version 
 of tm.terminal. Can this be corrected? 
 I haven't yet filed a PTP bug, but will if it is necessary. 
 
 Cannot complete the install because of a conflicting dependency. 
 Only one of the following can be installed at once: 
   Target Management Terminal Widget 3.2.1.201209191030 
 (org.eclipse.tm.terminal 3.2.1.201209191030) 
   Target Management Terminal Widget 3.2.2.201301071106 
 (org.eclipse.tm.terminal 3.2.2.201301071106) 
   Target Management Terminal Widget 3.2.0.201205300905 
 (org.eclipse.tm.terminal 3.2.0.201205300905) 
 
 bundle(org.eclipse.tm.terminal 3.2.2.201301071106) is required by: 
   ValidationSet(main) 
 Contribution(TM) 
   MappedRepository(http://download.eclipse.org/tm/updates/3.5milestones) 
 Feature(org.eclipse.tm.terminal.local.feature.group 0.2.100) 
 bundle(org.eclipse.tm.terminal 3.2.0.201205300905) is required by: 
   ValidationSet(main) 
 Contribution(PTP) 
   
 MappedRepository(http://download.eclipse.org/tools/ptp/builds/kepler/milestones/M5)
  
 Feature(org.eclipse.ptp.feature.group 6.0.4.201212181107) 
   InstallableUnit(org.eclipse.ptp.remote.terminal.feature.group 
 7.0.0.201301162143) 
 InstallableUnit(org.eclipse.tm.terminal.feature.group 
 3.2.0.201205300905-41-312316411A16) 
 
 
 
 -- David Dykstal,  Architect - Rational Developer for Power Systems

___
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 failure

[Greg Watson]

For some reason Hudson has started failing. Anyone else seeing this?

Greg

Begin forwarded message:

 From: hudsonbu...@eclipse.org
 Subject: [ptp-dev] [Hudson] Build failed in Hudson: ptp-master-release #75
 Date: February 1, 2013 7:28:14 PM EST
 To: ptp-...@eclipse.org
 Reply-To: Parallel Tools Platform general developers ptp-...@eclipse.org
 
 See https://hudson.eclipse.org/hudson/job/ptp-master-release/75/
 
 --
 Started by user gwatson
 Building remotely on hudson-slave1
 Checkout:ptp-master-release / 
 https://hudson.eclipse.org/hudson/job/ptp-master-release/ws/ - 
 hudson.remoting.Channel@5e253843:hudson-slave1
 Using strategy: Default
 Last Built Revision: Revision d36d8a3a57bd0a05c347fb723747c0c12d2bfd3b 
 (origin/ptp_6_0)
 FATAL: cannot assign instance of hudson.EnvVars to field 
 hudson.plugins.git.GitSCM$3.val$environment of type hudson.EnvVars in 
 instance of hudson.plugins.git.GitSCM$3
 java.lang.ClassCastException: cannot assign instance of hudson.EnvVars to 
 field hudson.plugins.git.GitSCM$3.val$environment of type hudson.EnvVars in 
 instance of hudson.plugins.git.GitSCM$3
   at 
 java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2032)
   at 
 java.io.ObjectStreamClass.setObjFieldValues(ObjectStreamClass.java:1212)
   at 
 java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1953)
   at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
   at 
 java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
   at 
 java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
   at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
   at 
 java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
   at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
   at hudson.remoting.UserRequest.deserialize(UserRequest.java:178)
   at hudson.remoting.UserRequest.perform(UserRequest.java:98)
   at hudson.remoting.UserRequest.perform(UserRequest.java:48)
   at hudson.remoting.Request$2.run(Request.java:283)
   at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:619)
 
 --
 This message is automatically generated by Hudson. 
 For more information on Hudson, see: http://hudson-ci.org/
 ___
 ptp-dev mailing list
 ptp-...@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/ptp-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] Juno SR2 aggregation

[Greg Watson]

Sorry if this is another dumb question. The result of the Juno aggregation goes 
to releases/maintenance, right? 

The reason that I ask is that the console log appears to indicate that the last 
build aggregated PTP 6.0.4.201301291850, however when I look in 
releases/maintenance, all I see is 6.0.4.201301240321. 

Thanks,
Greg
___
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 is broken

[Greg Watson]

Build is failing with the following message:

Started by upstream project ptp-photran-nightly build number 94
Building remotely on hudson-slave2
Checkout:ptp-nightly / https://hudson.eclipse.org/hudson/job/ptp-nightly/ws/ 
- hudson.remoting.Channel@32cf63bb:hudson-slave2
Using strategy: Default
Last Built Revision: Revision 566cf34845fd51c6a95bf37513e781ada6487da1 
(origin1/master)
Checkout:ptp-nightly / https://hudson.eclipse.org/hudson/job/ptp-nightly/ws/ 
- hudson.remoting.LocalChannel@30097f5f
Fetching changes from the remote Git repository
Fetching upstream changes from 
git://git.eclipse.org/gitroot/ptp/org.eclipse.ptp.git
FATAL: null
java.lang.NullPointerException
at 
hudson.remoting.MultiClassLoaderSerializer$Input.readClassLoader(MultiClassLoaderSerializer.java:94)
at 
hudson.remoting.MultiClassLoaderSerializer$Input.resolveClass(MultiClassLoaderSerializer.java:111)
at 
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at hudson.remoting.UserRequest.deserialize(UserRequest.java:178)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:207)
at hudson.remoting.Channel.call(Channel.java:651)
at hudson.FilePath.act(FilePath.java:747)
at hudson.FilePath.act(FilePath.java:740)
at hudson.plugins.git.GitSCM.gerRevisionToBuild(GitSCM.java:845)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:622)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1483)
at 
hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:507)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:424)
at hudson.model.Run.run(Run.java:1366)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:145)
___
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] Thank you to the 18 projects that have enabled for Kepler ...

[Greg Watson]

Hmmm, I thought I'd enabled PTP, but maybe I did something wrong…

Greg

On Aug 14, 2012, at 5:08 PM, David M Williams wrote:

 But, that still leaves 49 to go! 
 
 Remember, next week we will be producing Kepler M1 as well as Juno SR1 RC1 
 ... all Monday through Wednesday ... so, best if those that are planning to 
 participate in Kepler enable their project now, or there won't be time to 
 refine details next week. 
 
 
 actf.b3aggrcon 
 amalgam.b3aggrcon 
 amp.b3aggrcon 
 birt.b3aggrcon 
 cdt.b3aggrcon 
 dltk.b3aggrcon 
 dtp.b3aggrcon 
 ecf.b3aggrcon 
 emf-cdo.b3aggrcon 
 emf-compare.b3aggrcon 
 emf-query.b3aggrcon 
 emf-query2.b3aggrcon 
 emf-transaction.b3aggrcon 
 emf-validation.b3aggrcon 
 emft-ecoretools.b3aggrcon 
 emft-eef.b3aggrcon 
 emft-egf.b3aggrcon 
 emft-emffacet.b3aggrcon 
 epp-mpc.b3aggrcon 
 gmp-gmf-notation.b3aggrcon 
 gmp-gmf-runtime.b3aggrcon 
 gmp-gmf-tooling.b3aggrcon 
 gyrex.b3aggrcon 
 jetty.b3aggrcon 
 jubula.b3aggrcon 
 jwt.b3aggrcon 
 koneki.b3aggrcon 
 m2e.b3aggrcon 
 m2m-atl.b3aggrcon 
 m2m-qvtoml.b3aggrcon 
 m2t-acceleo.b3aggrcon 
 mat.b3aggrcon 
 mdt-modisco.b3aggrcon 
 mdt-papyrus.b3aggrcon 
 mft.b3aggrcon 
 mylyn-docs-intent.b3aggrcon 
 pdt.b3aggrcon 
 rap.b3aggrcon 
 recommenders.b3aggrcon 
 rtp.b3aggrcon 
 scout.b3aggrcon 
 soa-bpel.b3aggrcon 
 soa-sca.b3aggrcon 
 subversive.b3aggrcon 
 tcf.b3aggrcon 
 tm.b3aggrcon 
 virgo.b3aggrcon 
 webtools.b3aggrcon 
 windowbuilder.b3aggrcon 
 
 ___
 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] Migrating SimRel files this weekend to Git

[Greg Watson]

Ok, it's enabled now.

Thanks,
Greg

On Aug 7, 2012, at 2:50 PM, David M Williams wrote:

 I'm fine either way ... since I want it to be as most convenient for 
 everyone. So what ever works for you.   
 
 It does slightly increase the odds I might want to disable someone just to 
 get a green build, in which case, you'd have to re-enable later, once prereqs 
 were in. But all that won't be a factor until next week.   
 
 But, let's follow this convention: 
 
 Currently the contribution element itself has the enabled=false flag. 
 
 If you remove that, and I later need to disable something to get a temporary 
 build, I will disable the repository element, not the whole contribution 
 itself. I think that will effectively have same result (not include your 
 stuff, so not be broken by missing prereqs) but will be clear that you did/do 
 contribute to Kepler, and are in a just a temporarily disabled state. 
 
 Guess I should have been explicit, if anyone _knows_ they will not be in 
 Kepler, then feel free to say so explicitly, here to this list, to help 
 communication. But ... I have a feeling CDT will be :) [At least ... I hope!] 
 
 Thanks, 
 
 
 
 
 
 From:Greg Watson g.wat...@computer.org 
 To:Cross project issues cross-project-issues-dev@eclipse.org, 
 Date:08/07/2012 02:16 PM 
 Subject:Re: [cross-project-issues-dev] Migrating SimRel files this 
 weekendto Git 
 Sent by:cross-project-issues-dev-boun...@eclipse.org 
 
 
 
 David, 
 
 We're dependent on CDT, so if I re-enable PTP it will generate a validation 
 error. Do you want me to go ahead and enable it anyway, or wait until CDT 
 enables theirs? 
 
 Greg 
 
 On Aug 7, 2012, at 10:23 AM, David M Williams wrote: 
 
 The re-enable part is in the b3aggrcon file. There is now an enabled=fasle 
 attribute for your contribution (in master branch) that you have to remove, 
 commit, and push. 
 
 Not sue what the status of the kepler flag is for simultaneous release in 
 the Portal. AFAIK, the EMO is planning to roll-out their new Portal soon and 
 I am assume that will all be handled then. 
 
 The re-enable contribution is independent of that. (They could be made 
 related ... but ... not sure anyone is thinking that far ahead). 
 
 Thanks! 
 
  
 
 
 
 From:Ed Merks ed.me...@gmail.com 
 To:David M Williams/Raleigh/IBM@IBMUS, 
 Cc:dennis.hueb...@itemis.de 
 Date:08/07/2012 03:30 AM 
 Subject:Re: [cross-project-issues-dev] Migrating SimRel files this 
 weekend to Git 
 
 
 
 David,
 
 I'm not sure what I need to do to reenable EMF and XSD from the referenced 
 bugzilla.  I went to the portal to manage modeling.emf.emf, but I don't see 
 Kepler in the choices: 
 Mail Attachment.png 
 
 Regards,
 Ed
 
 On 07/08/2012 1:56 AM, David M Williams wrote: 
 Ok, all done 
 
 The main changes were in 
 http://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build 
 
 Which itself was renamed from previous Juno specific version (Seems things 
 are constant and steady enough to justify one document for both Juno and 
 Kepler). 
 
 If I've missed anything (or, anything unclear) let me me know. 
 
 Most important, in the master branch (for Kepler), I have disabled every 
 contribution and will require projects to re-enable themselves as a sign they 
 are intending to participate in Kepler (See bug 365738). 
 
 The bad news is there is a large order effect here. For example, EMF and 
 GEF must re-enable themselves before WTP (or nearly anyone else) could 
 correctly aggregate. 
 
 The good news is that I put an early warm-up I build in for Eclipse and 
 Equinox (and, yes, enabled them) and from some quick checks, it appears 
 everyone still builds with the Platform's Kepler M1 (at least, as of right 
 now, with warm-up) so ... the point is ... many low level projects such as 
 EMF or GEF could likely re-enable themselves quickly before any new 
 contributions were made/ready, thereby enabling your consuming projects to 
 re-enable themselves too. Put another way, there is no reason to wait until 
 your designated +n day to re-enable yourself, and if you do, it'd likely 
 complicate getting M1 done. 
 
 This complete the 5 steps outlined in my original note. Transition complete 
  now on to business. 
 
 Both Kepler M1 and Juno RC1 complete the same week (final contributions from 
 8/20 to 8/22). That will be a busy week, so anything that can be done early, 
 even if done as warmup willl likely help that week complete on time. 
 
 Thanks, 
 
 
 
 
 
 
 
 From:David M Williams/Raleigh/IBM@IBMUS 
 To:Cross project issues cross-project-issues-dev@eclipse.org, 
 Date:08/06/2012 12:52 AM 
 Subject:Re: [cross-project-issues-dev] Migrating SimRel files this 
 weekendtoGit 
 Sent by:cross-project-issues-dev-boun...@eclipse.org 
 
 
 
 Just to keep all informed. I have migrated sim rel file to Git 
 https://bugs.eclipse.org

Re: [cross-project-issues-dev] 4.2 speed issues

[Greg Watson]

I've had this impression for some time, but thought it was only the early 
builds of 4.2. It seems sluggish compared to 3.7.

Greg

On Jun 20, 2012, at 11:22 AM, Wim Jongman wrote:

 Hi,
 
 My impression after letting our team take 4.2 for a spin (with varying sets 
 of components) is that it is considerably slower then comparable 
 configurations in 3.7. Are there things that require special attention that 
 might affect the speed? We are all running with modern hardware and loads of 
 memory.
 
 Any other experiences ?
 
 Regards,
 
 Wim Jongman 
 ___
 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] PTP is late for +2

[Greg Watson]

Hi,

PTP will be late for it's +2 build, but there are some changes we need to get 
into RC2 for testing. It will be ready as soon as the build runs (within the 
next hour).

This should have no impact on the Juno aggregation.

Thanks,
Greg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev