From jmaury at redhat.com Wed Jun 1 03:17:53 2016 From: jmaury at redhat.com (Jean-Francois Maury) Date: Wed, 1 Jun 2016 09:17:53 +0200 Subject: [jbosstools-dev] ACTION REQUIRED: Code Freeze for Sprint 115 :: prepare for this week's staging build In-Reply-To: References: Message-ID: Hello, just as a remainder. We are still building with a SNAPSHOT version of the Openshift REST Java Client. When do we think this will be fixed ? Jeff On Tue, May 31, 2016 at 11:17 PM, Nick Boldt wrote: > * Target platform will be updated ASAP to move to *Neon.0.RC2*. Watch for > email updates. > > * Task JIRAs will be sent out tomorrow, and you will *create a branch & > update your root poms* to use the latest parent pom. > > * Code freeze for all projects' jbosstools-4.4.x branches will start *Thursday > at 2pm PST / 5pm EST / 11pm CST*. > > (We're back to the old way of branching and updating root & parent poms. > Did you enjoy the lightweight approach? Tell us!) > > * *build will run Thursday night* and be copied to /staging/ on Friday > morning EST. > > * *From Fri until the end of the sprint, you should *NOT* push anything > into the jbosstools-4.4.x stable branch unless it's a blocker fix approved > by Alexey* > > ** *master branch is open for new work once you've created your > jbosstools-4.4.x branch. > > ---- > > Looking ahead... > > We will be moving from Neon.0.RC2 to RC4 next week as soon as the *RC4 > bits are available, starting on Jun 8 or 9*. > > There will be a *respin on Jun 10* to move up to RC4. This will hopefully > the LAST build before *GA on June 14.* > > I hope to go rock climbing at a place call Bon Echo the weekend of June > 11-12. So... please, if you need to cause/find/fix blockers, please do so > before Jun 8 so they can be fixed at the same time as the TP update on Jun > 9 -- thanks! > > -- > Nick Boldt :: JBoss by Red Hat > Productization Lead :: JBoss Tools & Dev Studio > http://nick.divbyzero.com > > > > -- > Nick Boldt :: JBoss by Red Hat > Productization Lead :: JBoss Tools & Dev Studio > http://nick.divbyzero.com > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160601/ac7cfc86/attachment.html From alkazako at redhat.com Wed Jun 1 09:28:23 2016 From: alkazako at redhat.com (Alexey Kazakov) Date: Wed, 1 Jun 2016 09:28:23 -0400 Subject: [jbosstools-dev] ACTION REQUIRED: Code Freeze for Sprint 115 :: prepare for this week's staging build In-Reply-To: References: Message-ID: <574EE2F7.4060607@redhat.com> On 06/01/2016 03:17 AM, Jean-Francois Maury wrote: > Hello, > > just as a remainder. We are still building with a SNAPSHOT version of > the Openshift REST Java Client. When do we think this will be fixed ? Do we have it in JIRA? I can't find it in the current sprint. Thanks. > > Jeff > > On Tue, May 31, 2016 at 11:17 PM, Nick Boldt > wrote: > > * Target platform will be updated ASAP to move to *Neon.0.RC2*. > Watch for email updates. > > * Task JIRAs will be sent out tomorrow, and you will *create a > branch & update your root poms* to use the latest parent pom. > > * Code freeze for all projects' jbosstools-4.4.x branches will > start *Thursday at 2pm PST / 5pm EST / 11pm CST*. > > (We're back to the old way of branching and updating root & parent > poms. Did you enjoy the lightweight approach? Tell us!) > > * *build will run Thursday night* and be copied to /staging/ on > Friday morning EST. > > * *From Fri until the end of the sprint, you should *NOT* push > anything into the jbosstools-4.4.x stable branch unless it's a > blocker fix approved by Alexey* > > ** *master branch is open for new work once you've created your > jbosstools-4.4.x branch. > > ---- > > Looking ahead... > > We will be moving from Neon.0.RC2 to RC4 next week as soon as the > *RC4 bits are available, starting on Jun 8 or 9*. > > There will be a *respin on Jun 10* to move up to RC4. This will > hopefully the LAST build before *GA on June 14.* > > I hope to go rock climbing at a place call Bon Echo the weekend of > June 11-12. So... please, if you need to cause/find/fix blockers, > please do so before Jun 8 so they can be fixed at the same time as > the TP update on Jun 9 -- thanks! > > -- > Nick Boldt :: JBoss by Red Hat > Productization Lead :: JBoss Tools & Dev Studio > http://nick.divbyzero.com > > > > -- > Nick Boldt :: JBoss by Red Hat > Productization Lead :: JBoss Tools & Dev Studio > http://nick.divbyzero.com > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160601/f030dc9f/attachment-0001.html From jmaury at redhat.com Wed Jun 1 11:26:25 2016 From: jmaury at redhat.com (Jean-Francois Maury) Date: Wed, 1 Jun 2016 17:26:25 +0200 Subject: [jbosstools-dev] ACTION REQUIRED: Code Freeze for Sprint 115 :: prepare for this week's staging build In-Reply-To: <574EE2F7.4060607@redhat.com> References: <574EE2F7.4060607@redhat.com> Message-ID: https://issues.jboss.org/browse/JBIDE-22446 it is not in current sprint because we decided to be clean and not to add issues after the sprint is started? Jeff On Wed, Jun 1, 2016 at 3:28 PM, Alexey Kazakov wrote: > > > On 06/01/2016 03:17 AM, Jean-Francois Maury wrote: > > Hello, > > just as a remainder. We are still building with a SNAPSHOT version of the > Openshift REST Java Client. When do we think this will be fixed ? > > > Do we have it in JIRA? I can't find it in the current sprint. > > Thanks. > > > > Jeff > > On Tue, May 31, 2016 at 11:17 PM, Nick Boldt wrote: > >> * Target platform will be updated ASAP to move to *Neon.0.RC2*. Watch >> for email updates. >> >> * Task JIRAs will be sent out tomorrow, and you will *create a branch & >> update your root poms* to use the latest parent pom. >> >> * Code freeze for all projects' jbosstools-4.4.x branches will start *Thursday >> at 2pm PST / 5pm EST / 11pm CST*. >> >> (We're back to the old way of branching and updating root & parent poms. >> Did you enjoy the lightweight approach? Tell us!) >> >> * *build will run Thursday night* and be copied to /staging/ on Friday >> morning EST. >> >> * *From Fri until the end of the sprint, you should *NOT* push anything >> into the jbosstools-4.4.x stable branch unless it's a blocker fix approved >> by Alexey* >> >> ** *master branch is open for new work once you've created your >> jbosstools-4.4.x branch. >> >> ---- >> >> Looking ahead... >> >> We will be moving from Neon.0.RC2 to RC4 next week as soon as the *RC4 >> bits are available, starting on Jun 8 or 9*. >> >> There will be a *respin on Jun 10* to move up to RC4. This will >> hopefully the LAST build before *GA on June 14.* >> >> I hope to go rock climbing at a place call Bon Echo the weekend of June >> 11-12. So... please, if you need to cause/find/fix blockers, please do so >> before Jun 8 so they can be fixed at the same time as the TP update on Jun >> 9 -- thanks! >> >> -- >> Nick Boldt :: JBoss by Red Hat >> Productization Lead :: JBoss Tools & Dev Studio >> http://nick.divbyzero.com >> >> >> >> -- >> Nick Boldt :: JBoss by Red Hat >> Productization Lead :: JBoss Tools & Dev Studio >> http://nick.divbyzero.com >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> > > > > _______________________________________________ > jbosstools-dev mailing listjbosstools-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160601/dc393bb3/attachment.html From nboldt at redhat.com Wed Jun 1 13:41:54 2016 From: nboldt at redhat.com (Nick Boldt) Date: Wed, 1 Jun 2016 13:41:54 -0400 Subject: [jbosstools-dev] Alpha3 will be renamed to Final/GA Message-ID: >From Alexey: "@all Just got an official final conformation about releasing GA instead of Alpha/Beta. Please remember we have a code freeze tomorrow [Thursday Jun 2] 5pm EST. @NickBoldt we are good to rename JIRA version etc." Today: * I will rename 4.4.0.Alpha3 to 4.4.0.Final and 10.0.0.Alpha3 to 10.0.0.GA in JBIDE & JBDS JIRAs. * I will also be updating/renaming the current parent pom from 4.4.0.Alpha1 to 4.4.0.Final and sending the task JIRAs out today to get everyone to update their root poms to use this new version. * The target platform version will also move up to 4.60.0.Final-SNAPSHOT, and will be updated once Neon.0.RC4 bits are available on Jun 9 or 10. Once we have the RC4 bits in place, we can release the target platform in Nexus (no more -SNAPSHOT). If I'm forgetting something or this seems wrong, please don't hesitate to ask questions or correct my assumptions. Cheers, -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com From nboldt at redhat.com Wed Jun 1 16:57:39 2016 From: nboldt at redhat.com (Nick Boldt) Date: Wed, 1 Jun 2016 16:57:39 -0400 Subject: [jbosstools-dev] ACTION REQUIRED: branches and root pom updates in prep for JBT 4.4.0.Final / devstudio 10.0.0.GA code freeze on Thurs Jun 2 Message-ID: Task JIRA created for this milestone include: JBDS : https://issues.jboss.org/browse/JBDS-3920 JBoss Tools : https://issues.jboss.org/browse/JBIDE-22477 Aerogear : https://issues.jboss.org/browse/JBIDE-22478 Central Discovery : https://issues.jboss.org/browse/JBIDE-22479 VPE : https://issues.jboss.org/browse/JBIDE-22480 Integration Tests : https://issues.jboss.org/browse/JBIDE-22481 Server : https://issues.jboss.org/browse/JBIDE-22483 Hibernate : https://issues.jboss.org/browse/JBIDE-22484 Base : https://issues.jboss.org/browse/JBIDE-22485 OpenShift : https://issues.jboss.org/browse/JBIDE-22486 Playground : https://issues.jboss.org/browse/JBIDE-22487 JavaEE : https://issues.jboss.org/browse/JBIDE-22488 JST : https://issues.jboss.org/browse/JBIDE-22489 Forge : https://issues.jboss.org/browse/JBIDE-22490 BrowserSim : https://issues.jboss.org/browse/JBIDE-22491 Webservices : https://issues.jboss.org/browse/JBIDE-22492 Arquillian : https://issues.jboss.org/browse/JBIDE-22493 Freemarker : https://issues.jboss.org/browse/JBIDE-22494 Central : https://issues.jboss.org/browse/JBIDE-22495 LiveReload : https://issues.jboss.org/browse/JBIDE-22496 build, build-sites, build-ci, maven-plugins, dl.jb.org, devdoc, versionwatch: https://issues.jboss.org/browse/JBIDE-22482 -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com From nboldt at redhat.com Fri Jun 3 10:55:26 2016 From: nboldt at redhat.com (nboldt at redhat.com) Date: Fri, 3 Jun 2016 10:55:26 -0400 Subject: [jbosstools-dev] JBoss Tools Core 4.4.0.Final bits available for QE testing Message-ID: <201606031455.u53EtQ1l023744@dev01.mw.lab.eng.bos.redhat.com> These are not FINAL bits, but preliminary results for QE & community testing. Not for redistribution to customers or end users. Note that there is an issue installing the Integration Stack content -- currently, everything except Teiid Designer can be installed, prompting remediation. Update site: http://download.jboss.org/jbosstools/neon/staging/updates/ New + noteworthy (subject to change): * https://github.com/jbosstools/jbosstools-website/tree/master/documentation/whatsnew * http://tools.jboss.org/documentation/whatsnew/ Schedule: https://issues.jboss.org/projects/JBIDE?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page -- Additional update sites: * http://download.jboss.org/jbosstools/neon/staging/updates/core/4.4.0.Final/ * http://download.jboss.org/jbosstools/neon/staging/updates/coretests/4.4.0.Final/ Target platforms: * http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.60.0.Final-SNAPSHOT * http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.60.0.Final-SNAPSHOT Discovery sites: * http://download.jboss.org/jbosstools/neon/staging/updates/discovery.central/4.4.0.Final/ * http://download.jboss.org/jbosstools/neon/staging/updates/discovery.earlyaccess/4.4.0.Final/ Build folders (for build logs & update site zips): * http://download.jboss.org/jbosstools/neon/staging/builds/ From nboldt at redhat.com Fri Jun 3 11:57:26 2016 From: nboldt at redhat.com (Nick Boldt) Date: Fri, 3 Jun 2016 11:57:26 -0400 Subject: [jbosstools-dev] JBoss Tools Core 4.4.0.Final bits available for QE testing In-Reply-To: <201606031455.u53EtQ1l023744@dev01.mw.lab.eng.bos.redhat.com> References: <201606031455.u53EtQ1l023744@dev01.mw.lab.eng.bos.redhat.com> Message-ID: FYI, the Teiid Designer install problem is related to changes to the JBT and devstudio target platforms: https://issues.jboss.org/browse/JBTIS-729 It can be resolved with a new IS build, which includes this missing plugin. On Fri, Jun 3, 2016 at 10:55 AM, wrote: > > These are not FINAL bits, but preliminary results for QE & community testing. Not for redistribution to customers or end users. > > Note that there is an issue installing the Integration Stack content -- currently, everything except Teiid Designer can be installed, prompting remediation. > > Update site: http://download.jboss.org/jbosstools/neon/staging/updates/ > > New + noteworthy (subject to change): > * https://github.com/jbosstools/jbosstools-website/tree/master/documentation/whatsnew > * http://tools.jboss.org/documentation/whatsnew/ > > Schedule: https://issues.jboss.org/projects/JBIDE?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page > > -- > > Additional update sites: > * http://download.jboss.org/jbosstools/neon/staging/updates/core/4.4.0.Final/ > * http://download.jboss.org/jbosstools/neon/staging/updates/coretests/4.4.0.Final/ > > Target platforms: > * http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.60.0.Final-SNAPSHOT > * http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.60.0.Final-SNAPSHOT > > Discovery sites: > * http://download.jboss.org/jbosstools/neon/staging/updates/discovery.central/4.4.0.Final/ > * http://download.jboss.org/jbosstools/neon/staging/updates/discovery.earlyaccess/4.4.0.Final/ > > Build folders (for build logs & update site zips): > * http://download.jboss.org/jbosstools/neon/staging/builds/ > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com From nboldt at redhat.com Fri Jun 3 18:50:01 2016 From: nboldt at redhat.com (Nick Boldt) Date: Fri, 3 Jun 2016 18:50:01 -0400 Subject: [jbosstools-dev] 4.4.x branches have been moved to 4.4.0.x so that master can be used for 4.4.1.* work Message-ID: Max and Alexey have decided that to avoid confusion, the 4.4.x branches should be renamed to 4.4.0.x, so that master branch can be used for 4.4.1.* work. This way those who don't have triage, sprint planning, N&N, doc, blogs, videos, and other non-code work to do during the end of Sprint 115 can continue to do stuff for 4.4.1 in the master branch. This change has been done for all the main component projects (base, server, openshift, ...) and will be done for the build-related and devstudio repos shortly. Nick -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com From aer-bot at ctrlflow.com Sun Jun 5 23:30:00 2016 From: aer-bot at ctrlflow.com (Automated Error Reporting Bot) Date: Mon, 6 Jun 2016 03:30:00 +0000 (UTC) Subject: [jbosstools-dev] [aeri] Weekly JBoss Tools Error Reports Digest Message-ID: <1700021082.1.1465183800754.JavaMail.ec2-user@aeri-rh> An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160606/dd20bbac/attachment-0001.html From xcoulon at redhat.com Mon Jun 6 02:47:01 2016 From: xcoulon at redhat.com (Xavier Coulon) Date: Mon, 6 Jun 2016 08:47:01 +0200 Subject: [jbosstools-dev] 4.4.x branches have been moved to 4.4.0.x so that master can be used for 4.4.1.* work In-Reply-To: References: Message-ID: Thanks Nick. Best regards, Xavier > On 04 Jun 2016, at 00:50, Nick Boldt wrote: > > Max and Alexey have decided that to avoid confusion, the 4.4.x > branches should be renamed to 4.4.0.x, so that master branch can be > used for 4.4.1.* work. > > This way those who don't have triage, sprint planning, N&N, doc, > blogs, videos, and other non-code work to do during the end of Sprint > 115 can continue to do stuff for 4.4.1 in the master branch. > > This change has been done for all the main component projects (base, > server, openshift, ...) and will be done for the build-related and > devstudio repos shortly. > > Nick > > -- > Nick Boldt :: JBoss by Red Hat > Productization Lead :: JBoss Tools & Dev Studio > http://nick.divbyzero.com > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev From manderse at redhat.com Mon Jun 6 02:58:46 2016 From: manderse at redhat.com (manderse at redhat.com) Date: Mon, 6 Jun 2016 02:58:46 -0400 Subject: [jbosstools-dev] ACTION REQUIRED: 1 issue with no component Message-ID: <201606060658.u566wkX0022271@int-mx13.intmail.prod.int.phx2.redhat.com> This email is the result of a query to locate stalled/invalid jiras. Please fix them. Thanks! * No component for JBDS-3924 https://issues.jboss.org/browse/JBDS-3924 Summary: Installation looks incomplete but is actually completed Assignee: None set. Component: None set - please fix. Problem: No component - please assign this issue to one or more components. Last Update: 5:30:22.986630 ---------------------------- Query used: https://issues.jboss.org/issues/?jql=filter%3D%27ds_lint_nocomponent%27 From manderse at redhat.com Mon Jun 6 06:27:02 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Mon, 06 Jun 2016 12:27:02 +0200 Subject: [jbosstools-dev] JBoss Tools Core 4.4.0.Final bits available for QE testing In-Reply-To: References: <201606031455.u53EtQ1l023744@dev01.mw.lab.eng.bos.redhat.com> Message-ID: <97CF33E4-0126-40BB-84CD-FEA113FD6C53@redhat.com> On 3 Jun 2016, at 17:57, Nick Boldt wrote: > FYI, the Teiid Designer install problem is related to changes to the > JBT and devstudio target platforms: > > https://issues.jboss.org/browse/JBTIS-729 > > It can be resolved with a new IS build, which includes this missing > plugin. that plugin "org.eclipse.core.runtime.compatibility" should not be included. that is something Teiid need to fix. This api was there for Eclipse 2.0 compatibility - it is code that we should not use the last 10+ years. It was officially deprecated and mark for removal 3 years ago: https://bugs.eclipse.org/bugs/show_bug.cgi?id=394739 this should not have been "fixed" by letting it in again IMO. /max > > On Fri, Jun 3, 2016 at 10:55 AM, wrote: >> >> These are not FINAL bits, but preliminary results for QE & community >> testing. Not for redistribution to customers or end users. >> >> Note that there is an issue installing the Integration Stack content >> -- currently, everything except Teiid Designer can be installed, >> prompting remediation. >> >> Update site: >> http://download.jboss.org/jbosstools/neon/staging/updates/ >> >> New + noteworthy (subject to change): >> * >> https://github.com/jbosstools/jbosstools-website/tree/master/documentation/whatsnew >> * http://tools.jboss.org/documentation/whatsnew/ >> >> Schedule: >> https://issues.jboss.org/projects/JBIDE?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page >> >> -- >> >> Additional update sites: >> * >> http://download.jboss.org/jbosstools/neon/staging/updates/core/4.4.0.Final/ >> * >> http://download.jboss.org/jbosstools/neon/staging/updates/coretests/4.4.0.Final/ >> >> Target platforms: >> * >> http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.60.0.Final-SNAPSHOT >> * >> http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.60.0.Final-SNAPSHOT >> >> Discovery sites: >> * >> http://download.jboss.org/jbosstools/neon/staging/updates/discovery.central/4.4.0.Final/ >> * >> http://download.jboss.org/jbosstools/neon/staging/updates/discovery.earlyaccess/4.4.0.Final/ >> >> Build folders (for build logs & update site zips): >> * http://download.jboss.org/jbosstools/neon/staging/builds/ >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > -- > Nick Boldt :: JBoss by Red Hat > Productization Lead :: JBoss Tools & Dev Studio > http://nick.divbyzero.com > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev /max http://about.me/maxandersen From manderse at redhat.com Mon Jun 6 06:32:00 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Mon, 06 Jun 2016 12:32:00 +0200 Subject: [jbosstools-dev] ACTION REQUIRED: Code Freeze for Sprint 115 :: prepare for this week's staging build In-Reply-To: References: <574EE2F7.4060607@redhat.com> Message-ID: <4A159D21-4812-4417-BD5B-CD3AE49DB3FD@redhat.com> On 1 Jun 2016, at 17:26, Jean-Francois Maury wrote: > https://issues.jboss.org/browse/JBIDE-22446 > > it is not in current sprint because we decided to be clean and not to > add > issues after the sprint is started? This does not make sense - the GA release was part of this sprint scope. I've marked this for 4.4.0.Final with respin-a label so we can keep track of what we've found of issues. /max > > Jeff > > On Wed, Jun 1, 2016 at 3:28 PM, Alexey Kazakov > wrote: > >> >> >> On 06/01/2016 03:17 AM, Jean-Francois Maury wrote: >> >> Hello, >> >> just as a remainder. We are still building with a SNAPSHOT version of >> the >> Openshift REST Java Client. When do we think this will be fixed ? >> >> >> Do we have it in JIRA? I can't find it in the current sprint. >> >> Thanks. >> >> >> >> Jeff >> >> On Tue, May 31, 2016 at 11:17 PM, Nick Boldt >> wrote: >> >>> * Target platform will be updated ASAP to move to *Neon.0.RC2*. >>> Watch >>> for email updates. >>> >>> * Task JIRAs will be sent out tomorrow, and you will *create a >>> branch & >>> update your root poms* to use the latest parent pom. >>> >>> * Code freeze for all projects' jbosstools-4.4.x branches will start >>> *Thursday >>> at 2pm PST / 5pm EST / 11pm CST*. >>> >>> (We're back to the old way of branching and updating root & parent >>> poms. >>> Did you enjoy the lightweight approach? Tell us!) >>> >>> * *build will run Thursday night* and be copied to /staging/ on >>> Friday >>> morning EST. >>> >>> * *From Fri until the end of the sprint, you should *NOT* push >>> anything >>> into the jbosstools-4.4.x stable branch unless it's a blocker fix >>> approved >>> by Alexey* >>> >>> ** *master branch is open for new work once you've created your >>> jbosstools-4.4.x branch. >>> >>> ---- >>> >>> Looking ahead... >>> >>> We will be moving from Neon.0.RC2 to RC4 next week as soon as the >>> *RC4 >>> bits are available, starting on Jun 8 or 9*. >>> >>> There will be a *respin on Jun 10* to move up to RC4. This will >>> hopefully the LAST build before *GA on June 14.* >>> >>> I hope to go rock climbing at a place call Bon Echo the weekend of >>> June >>> 11-12. So... please, if you need to cause/find/fix blockers, please >>> do so >>> before Jun 8 so they can be fixed at the same time as the TP update >>> on Jun >>> 9 -- thanks! >>> >>> -- >>> Nick Boldt :: JBoss by Red Hat >>> Productization Lead :: JBoss Tools & Dev Studio >>> http://nick.divbyzero.com >>> >>> >>> >>> -- >>> Nick Boldt :: JBoss by Red Hat >>> Productization Lead :: JBoss Tools & Dev Studio >>> http://nick.divbyzero.com >>> >>> _______________________________________________ >>> jbosstools-dev mailing list >>> jbosstools-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>> >> >> >> >> _______________________________________________ >> jbosstools-dev mailing >> listjbosstools-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/jbosstools-dev >> >> >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev /max http://about.me/maxandersen From alkazako at redhat.com Mon Jun 6 10:06:01 2016 From: alkazako at redhat.com (Alexey Kazakov) Date: Mon, 6 Jun 2016 10:06:01 -0400 Subject: [jbosstools-dev] ACTION REQUIRED: Code Freeze for Sprint 115 :: prepare for this week's staging build In-Reply-To: <4A159D21-4812-4417-BD5B-CD3AE49DB3FD@redhat.com> References: <574EE2F7.4060607@redhat.com> <4A159D21-4812-4417-BD5B-CD3AE49DB3FD@redhat.com> Message-ID: <57558349.4060204@redhat.com> On 06/06/2016 06:32 AM, Max Rydahl Andersen wrote: > On 1 Jun 2016, at 17:26, Jean-Francois Maury wrote: > >> https://issues.jboss.org/browse/JBIDE-22446 >> >> it is not in current sprint because we decided to be clean and not to >> add >> issues after the sprint is started? > > This does not make sense - the GA release was part of this sprint scope. > > I've marked this for 4.4.0.Final with respin-a label so we can keep > track of > what we've found of issues. Max, there is another issue [1] (linked to this one) for releasing and including openshift-restclient-java into devstudio 10.0.0.GA That issue was resolved before our codefreeze. The issues is mentioned by Jeff above [2] is actually about some automated detection/test if we include some snapshot artefacts instead of released versions. This detection/test itself is not a blocker for GA and it wasn't planed for this sprint. So I'm going to add some clarification to the jira and move it to backlog. [1] https://issues.jboss.org/browse/JBIDE-22444 [2] https://issues.jboss.org/browse/JBIDE-22446 Thanks. > > /max > >> >> Jeff >> >> On Wed, Jun 1, 2016 at 3:28 PM, Alexey Kazakov >> wrote: >> >>> >>> >>> On 06/01/2016 03:17 AM, Jean-Francois Maury wrote: >>> >>> Hello, >>> >>> just as a remainder. We are still building with a SNAPSHOT version >>> of the >>> Openshift REST Java Client. When do we think this will be fixed ? >>> >>> >>> Do we have it in JIRA? I can't find it in the current sprint. >>> >>> Thanks. >>> >>> >>> >>> Jeff >>> >>> On Tue, May 31, 2016 at 11:17 PM, Nick Boldt wrote: >>> >>>> * Target platform will be updated ASAP to move to *Neon.0.RC2*. Watch >>>> for email updates. >>>> >>>> * Task JIRAs will be sent out tomorrow, and you will *create a >>>> branch & >>>> update your root poms* to use the latest parent pom. >>>> >>>> * Code freeze for all projects' jbosstools-4.4.x branches will >>>> start *Thursday >>>> at 2pm PST / 5pm EST / 11pm CST*. >>>> >>>> (We're back to the old way of branching and updating root & parent >>>> poms. >>>> Did you enjoy the lightweight approach? Tell us!) >>>> >>>> * *build will run Thursday night* and be copied to /staging/ on Friday >>>> morning EST. >>>> >>>> * *From Fri until the end of the sprint, you should *NOT* push >>>> anything >>>> into the jbosstools-4.4.x stable branch unless it's a blocker fix >>>> approved >>>> by Alexey* >>>> >>>> ** *master branch is open for new work once you've created your >>>> jbosstools-4.4.x branch. >>>> >>>> ---- >>>> >>>> Looking ahead... >>>> >>>> We will be moving from Neon.0.RC2 to RC4 next week as soon as the *RC4 >>>> bits are available, starting on Jun 8 or 9*. >>>> >>>> There will be a *respin on Jun 10* to move up to RC4. This will >>>> hopefully the LAST build before *GA on June 14.* >>>> >>>> I hope to go rock climbing at a place call Bon Echo the weekend of >>>> June >>>> 11-12. So... please, if you need to cause/find/fix blockers, please >>>> do so >>>> before Jun 8 so they can be fixed at the same time as the TP update >>>> on Jun >>>> 9 -- thanks! >>>> >>>> -- >>>> Nick Boldt :: JBoss by Red Hat >>>> Productization Lead :: JBoss Tools & Dev Studio >>>> http://nick.divbyzero.com >>>> >>>> >>>> >>>> -- >>>> Nick Boldt :: JBoss by Red Hat >>>> Productization Lead :: JBoss Tools & Dev Studio >>>> http://nick.divbyzero.com >>>> >>>> _______________________________________________ >>>> jbosstools-dev mailing list >>>> jbosstools-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>>> >>> >>> >>> >>> _______________________________________________ >>> jbosstools-dev mailing >>> listjbosstools-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/jbosstools-dev >>> >>> >>> >>> _______________________________________________ >>> jbosstools-dev mailing list >>> jbosstools-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>> > > >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > /max > http://about.me/maxandersen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160606/55de614d/attachment-0001.html From nboldt at redhat.com Mon Jun 6 11:38:33 2016 From: nboldt at redhat.com (Nick Boldt) Date: Mon, 6 Jun 2016 11:38:33 -0400 Subject: [jbosstools-dev] 4.4.x branches have been moved to 4.4.0.x so that master can be used for 4.4.1.* work In-Reply-To: References: Message-ID: The remaining branches have been renamed too, for build, build-ci, build-sites, maven-plugins, dl.jb.org, discovery, versionwatch, devdoc, and the devstudio-* projects too. I did not rename the jbosstools-integration-tests repo, which still has a 4.4.x branch. On Mon, Jun 6, 2016 at 2:47 AM, Xavier Coulon wrote: > Thanks Nick. > > Best regards, > Xavier >> On 04 Jun 2016, at 00:50, Nick Boldt wrote: >> >> Max and Alexey have decided that to avoid confusion, the 4.4.x >> branches should be renamed to 4.4.0.x, so that master branch can be >> used for 4.4.1.* work. >> >> This way those who don't have triage, sprint planning, N&N, doc, >> blogs, videos, and other non-code work to do during the end of Sprint >> 115 can continue to do stuff for 4.4.1 in the master branch. >> >> This change has been done for all the main component projects (base, >> server, openshift, ...) and will be done for the build-related and >> devstudio repos shortly. >> >> Nick >> >> -- >> Nick Boldt :: JBoss by Red Hat >> Productization Lead :: JBoss Tools & Dev Studio >> http://nick.divbyzero.com >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com From nboldt at redhat.com Mon Jun 6 11:43:09 2016 From: nboldt at redhat.com (Nick Boldt) Date: Mon, 6 Jun 2016 11:43:09 -0400 Subject: [jbosstools-dev] JBoss Tools Core 4.4.0.Final bits available for QE testing In-Reply-To: <97CF33E4-0126-40BB-84CD-FEA113FD6C53@redhat.com> References: <201606031455.u53EtQ1l023744@dev01.mw.lab.eng.bos.redhat.com> <97CF33E4-0126-40BB-84CD-FEA113FD6C53@redhat.com> Message-ID: Since the org.eclipse.core.runtime.compatibility 3.2.300.v20150423-0821 plugin exists in http://download.jboss.org/jbosstools/updates/requirements/birt/4.5.0.v201510231925/plugins/ it can now be accessed when installing Teiid 10.0.0.Beta3 from the Mars-based Integration Stack sites. Therefore it doesn't need to be in the 4.60.0.Final-SNAPSHOT target platform for JBT 4.4.0.Final / 10.0.0.GA, and I've re-removed it. The patchfix to the IS 4.3.x / 9.x EA composite sites (adding a child site link to http://download.jboss.org/jbosstools/updates/requirements/birt/4.5.0.v201510231925 ) allows the old Mars-based Teiid 10.0.0.Beta3 to be installable on all of JBT 4.3.x/4.4.0, devstudio 9.x/10.0.0. Eventually, I would hope that something newer than Teiid 10.0.0.Beta3-v20160218-1807-B4076 will be updated to NOT depend on the runtime.compatibility plugin. (Seems surprising that after *nearly 4 months* the latest is only a Beta3.) But updating Teiid Designer no longer blocks the release of JBT 4.4.0.Final / devstudio 10.0.0.GA. On Mon, Jun 6, 2016 at 6:27 AM, Max Rydahl Andersen wrote: > On 3 Jun 2016, at 17:57, Nick Boldt wrote: > >> FYI, the Teiid Designer install problem is related to changes to the >> JBT and devstudio target platforms: >> >> https://issues.jboss.org/browse/JBTIS-729 >> >> It can be resolved with a new IS build, which includes this missing >> plugin. > > > that plugin "org.eclipse.core.runtime.compatibility" should not be included. > that is something Teiid need to fix. > > This api was there for Eclipse 2.0 compatibility - it is code that we should > not use the last 10+ years. > > It was officially deprecated and mark for removal 3 years ago: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=394739 > > this should not have been "fixed" by letting it in again IMO. > > /max > > >> >> On Fri, Jun 3, 2016 at 10:55 AM, wrote: >>> >>> >>> These are not FINAL bits, but preliminary results for QE & community >>> testing. Not for redistribution to customers or end users. >>> >>> Note that there is an issue installing the Integration Stack content -- >>> currently, everything except Teiid Designer can be installed, prompting >>> remediation. >>> >>> Update site: http://download.jboss.org/jbosstools/neon/staging/updates/ >>> >>> New + noteworthy (subject to change): >>> * >>> https://github.com/jbosstools/jbosstools-website/tree/master/documentation/whatsnew >>> * http://tools.jboss.org/documentation/whatsnew/ >>> >>> Schedule: >>> https://issues.jboss.org/projects/JBIDE?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page >>> >>> -- >>> >>> Additional update sites: >>> * >>> http://download.jboss.org/jbosstools/neon/staging/updates/core/4.4.0.Final/ >>> * >>> http://download.jboss.org/jbosstools/neon/staging/updates/coretests/4.4.0.Final/ >>> >>> Target platforms: >>> * >>> http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.60.0.Final-SNAPSHOT >>> * >>> http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.60.0.Final-SNAPSHOT >>> >>> Discovery sites: >>> * >>> http://download.jboss.org/jbosstools/neon/staging/updates/discovery.central/4.4.0.Final/ >>> * >>> http://download.jboss.org/jbosstools/neon/staging/updates/discovery.earlyaccess/4.4.0.Final/ >>> >>> Build folders (for build logs & update site zips): >>> * http://download.jboss.org/jbosstools/neon/staging/builds/ >>> >>> _______________________________________________ >>> jbosstools-dev mailing list >>> jbosstools-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> >> >> -- >> Nick Boldt :: JBoss by Red Hat >> Productization Lead :: JBoss Tools & Dev Studio >> http://nick.divbyzero.com >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > > /max > http://about.me/maxandersen -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com From alkazako at redhat.com Mon Jun 6 11:58:40 2016 From: alkazako at redhat.com (Alexey Kazakov) Date: Mon, 6 Jun 2016 11:58:40 -0400 Subject: [jbosstools-dev] 4.4.x branches have been moved to 4.4.0.x so that master can be used for 4.4.1.* work In-Reply-To: References: Message-ID: <57559DB0.9070203@redhat.com> I renamed jbosstools-integration-tests. Thanks. On 06/06/2016 11:38 AM, Nick Boldt wrote: > The remaining branches have been renamed too, for build, build-ci, > build-sites, maven-plugins, dl.jb.org, discovery, versionwatch, > devdoc, and the devstudio-* projects too. > > I did not rename the jbosstools-integration-tests repo, which still > has a 4.4.x branch. > > On Mon, Jun 6, 2016 at 2:47 AM, Xavier Coulon wrote: >> Thanks Nick. >> >> Best regards, >> Xavier >>> On 04 Jun 2016, at 00:50, Nick Boldt wrote: >>> >>> Max and Alexey have decided that to avoid confusion, the 4.4.x >>> branches should be renamed to 4.4.0.x, so that master branch can be >>> used for 4.4.1.* work. >>> >>> This way those who don't have triage, sprint planning, N&N, doc, >>> blogs, videos, and other non-code work to do during the end of Sprint >>> 115 can continue to do stuff for 4.4.1 in the master branch. >>> >>> This change has been done for all the main component projects (base, >>> server, openshift, ...) and will be done for the build-related and >>> devstudio repos shortly. >>> >>> Nick >>> >>> -- >>> Nick Boldt :: JBoss by Red Hat >>> Productization Lead :: JBoss Tools & Dev Studio >>> http://nick.divbyzero.com >>> _______________________________________________ >>> jbosstools-dev mailing list >>> jbosstools-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > From nboldt at redhat.com Tue Jun 7 09:09:56 2016 From: nboldt at redhat.com (Nick Boldt) Date: Tue, 7 Jun 2016 09:09:56 -0400 Subject: [jbosstools-dev] ACTION REQUIRED: Prepare projects in master branch for 4.4.1 / parent pom = 4.4.1.Alpha1-SNAPSHOT Message-ID: New parent pom available for use in master branch. Please move up to it. Task JIRA created for this future milestone include (future sprint 116): JBDS : https://issues.jboss.org/browse/JBDS-3930 JBoss Tools : https://issues.jboss.org/browse/JBIDE-22552 Aerogear : https://issues.jboss.org/browse/JBIDE-22553 Central Discovery : https://issues.jboss.org/browse/JBIDE-22554 VPE : https://issues.jboss.org/browse/JBIDE-22555 Integration Tests : https://issues.jboss.org/browse/JBIDE-22556 Server : https://issues.jboss.org/browse/JBIDE-22558 Hibernate : https://issues.jboss.org/browse/JBIDE-22559 Base : https://issues.jboss.org/browse/JBIDE-22560 OpenShift : https://issues.jboss.org/browse/JBIDE-22561 Playground : https://issues.jboss.org/browse/JBIDE-22562 JavaEE : https://issues.jboss.org/browse/JBIDE-22563 JST : https://issues.jboss.org/browse/JBIDE-22564 Forge : https://issues.jboss.org/browse/JBIDE-22565 BrowserSim : https://issues.jboss.org/browse/JBIDE-22566 Webservices : https://issues.jboss.org/browse/JBIDE-22567 Arquillian : https://issues.jboss.org/browse/JBIDE-22568 Freemarker : https://issues.jboss.org/browse/JBIDE-22569 Central : https://issues.jboss.org/browse/JBIDE-22570 LiveReload : https://issues.jboss.org/browse/JBIDE-22571 build, build-sites, build-ci, maven-plugins, dl.jb.org, devdoc, versionwatch: https://issues.jboss.org/browse/JBIDE-22557 -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com From mmalina at redhat.com Tue Jun 7 10:04:16 2016 From: mmalina at redhat.com (Martin Malina) Date: Tue, 7 Jun 2016 16:04:16 +0200 Subject: [jbosstools-dev] Docker connections in Docker Tooling - request for feedback Message-ID: <629334CF-7EFD-4679-8AEF-3F136416A1F2@redhat.com> Hi all, We are looking into ways to improve the Docker Tooling UI in Eclipse and would like to ask for help. Xavier and I discussed one scenario which is currently quite confusing, it is described here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=495600 In short, this is the use case: 1. Start CDK 2. Connect to Docker 3. Stop CDK 4. Start CDK 5. Connect to Docker - here I was failing for a long time until Xavier told me I needed to click this "Enable Connection" button, to make the connection work again. This issue was previously discussed here: https://issues.jboss.org/browse/JBDS-3739 We would appreciate if any of you had any suggestions how to improve this. Thanks Martin -- Martin Malina JBoss QA Engineer Red Hat Czech s.r.o. Purkynova 99 612 45 Brno, Czech Republic Tel.: +420 532 294 265 From alkazako at redhat.com Tue Jun 7 12:29:17 2016 From: alkazako at redhat.com (Alexey Kazakov) Date: Tue, 7 Jun 2016 12:29:17 -0400 Subject: [jbosstools-dev] Docker connections in Docker Tooling - request for feedback In-Reply-To: <629334CF-7EFD-4679-8AEF-3F136416A1F2@redhat.com> References: <629334CF-7EFD-4679-8AEF-3F136416A1F2@redhat.com> Message-ID: <5756F65D.4060000@redhat.com> What if you make a docker connection always expandable and try to enable the connection when you are trying to expand it? On 06/07/2016 10:04 AM, Martin Malina wrote: > Hi all, > > We are looking into ways to improve the Docker Tooling UI in Eclipse and would like to ask for help. > > Xavier and I discussed one scenario which is currently quite confusing, it is described here: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=495600 > > In short, this is the use case: > 1. Start CDK > 2. Connect to Docker > 3. Stop CDK > 4. Start CDK > 5. Connect to Docker > - here I was failing for a long time until Xavier told me I needed to click this "Enable Connection" button, to make the connection work again. > This issue was previously discussed here: https://issues.jboss.org/browse/JBDS-3739 > > We would appreciate if any of you had any suggestions how to improve this. > > Thanks > Martin > > -- > Martin Malina > JBoss QA Engineer > Red Hat Czech s.r.o. > Purkynova 99 > 612 45 Brno, Czech Republic > > Tel.: +420 532 294 265 > > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev From manderse at redhat.com Wed Jun 8 02:58:50 2016 From: manderse at redhat.com (manderse at redhat.com) Date: Wed, 8 Jun 2016 02:58:50 -0400 Subject: [jbosstools-dev] ACTION REQUIRED: 1 issue with no component Message-ID: <201606080658.u586wojV004342@int-mx09.intmail.prod.int.phx2.redhat.com> This email is the result of a query to locate stalled/invalid jiras. Please fix them. Thanks! * No component for JBDS-3934 https://issues.jboss.org/browse/JBDS-3934 Summary: Uninstall process results in odd things Assignee: None set. Component: None set - please fix. Problem: No component - please assign this issue to one or more components. Last Update: 3:14:58.857614 ---------------------------- Query used: https://issues.jboss.org/issues/?jql=filter%3D%27ds_lint_nocomponent%27 From mmalina at redhat.com Wed Jun 8 08:03:48 2016 From: mmalina at redhat.com (Martin Malina) Date: Wed, 8 Jun 2016 14:03:48 +0200 Subject: [jbosstools-dev] Docker connections in Docker Tooling - request for feedback In-Reply-To: <5756F65D.4060000@redhat.com> References: <629334CF-7EFD-4679-8AEF-3F136416A1F2@redhat.com> <5756F65D.4060000@redhat.com> Message-ID: <0751A0D6-0AE7-4239-98E7-EC773CF536E0@redhat.com> Thanks for the suggestion. Yes, it's not a bad idea I think. I do understand why they came up with the disabled state - when you have Docker images view open, the view will keep being refreshed periodically, so disabling the connection when the docker daemon is down makes some sense. But yes, perhaps it could still be expandable in the Docker Explorer and expanding would enable the connection. I will suggest this in the BZ. -Martin > On 7. 6. 2016, at 18:29, Alexey Kazakov wrote: > > What if you make a docker connection always expandable and try to enable > the connection when you are trying to expand it? > > On 06/07/2016 10:04 AM, Martin Malina wrote: >> Hi all, >> >> We are looking into ways to improve the Docker Tooling UI in Eclipse and would like to ask for help. >> >> Xavier and I discussed one scenario which is currently quite confusing, it is described here: >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=495600 >> >> In short, this is the use case: >> 1. Start CDK >> 2. Connect to Docker >> 3. Stop CDK >> 4. Start CDK >> 5. Connect to Docker >> - here I was failing for a long time until Xavier told me I needed to click this "Enable Connection" button, to make the connection work again. >> This issue was previously discussed here: https://issues.jboss.org/browse/JBDS-3739 >> >> We would appreciate if any of you had any suggestions how to improve this. >> >> Thanks >> Martin >> >> -- >> Martin Malina >> JBoss QA Engineer >> Red Hat Czech s.r.o. >> Purkynova 99 >> 612 45 Brno, Czech Republic >> >> Tel.: +420 532 294 265 >> >> >> >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev From manderse at redhat.com Wed Jun 8 08:53:48 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Wed, 08 Jun 2016 14:53:48 +0200 Subject: [jbosstools-dev] ACTION REQUIRED: Code Freeze for Sprint 115 :: prepare for this week's staging build In-Reply-To: <57558349.4060204@redhat.com> References: <574EE2F7.4060607@redhat.com> <4A159D21-4812-4417-BD5B-CD3AE49DB3FD@redhat.com> <57558349.4060204@redhat.com> Message-ID: On 6 Jun 2016, at 16:06, Alexey Kazakov wrote: > On 06/06/2016 06:32 AM, Max Rydahl Andersen wrote: >> On 1 Jun 2016, at 17:26, Jean-Francois Maury wrote: >> >>> https://issues.jboss.org/browse/JBIDE-22446 >>> >>> it is not in current sprint because we decided to be clean and not >>> to add >>> issues after the sprint is started? >> >> This does not make sense - the GA release was part of this sprint >> scope. >> >> I've marked this for 4.4.0.Final with respin-a label so we can keep >> track of >> what we've found of issues. > > Max, there is another issue [1] (linked to this one) for releasing and > including openshift-restclient-java into devstudio 10.0.0.GA > That issue was resolved before our codefreeze. > The issues is mentioned by Jeff above [2] is actually about some > automated detection/test if we include some snapshot artefacts instead > of released versions. > This detection/test itself is not a blocker for GA and it wasn't > planed for this sprint. So I'm going to add some clarification to the > jira and move it to backlog. > > [1] https://issues.jboss.org/browse/JBIDE-22444 > [2] https://issues.jboss.org/browse/JBIDE-22446 okay, great! sorry for misunderstanding the jiras/context. /max > > Thanks. > >> >> /max >> >>> >>> Jeff >>> >>> On Wed, Jun 1, 2016 at 3:28 PM, Alexey Kazakov >>> wrote: >>> >>>> >>>> >>>> On 06/01/2016 03:17 AM, Jean-Francois Maury wrote: >>>> >>>> Hello, >>>> >>>> just as a remainder. We are still building with a SNAPSHOT version >>>> of the >>>> Openshift REST Java Client. When do we think this will be fixed ? >>>> >>>> >>>> Do we have it in JIRA? I can't find it in the current sprint. >>>> >>>> Thanks. >>>> >>>> >>>> >>>> Jeff >>>> >>>> On Tue, May 31, 2016 at 11:17 PM, Nick Boldt >>>> wrote: >>>> >>>>> * Target platform will be updated ASAP to move to *Neon.0.RC2*. >>>>> Watch >>>>> for email updates. >>>>> >>>>> * Task JIRAs will be sent out tomorrow, and you will *create a >>>>> branch & >>>>> update your root poms* to use the latest parent pom. >>>>> >>>>> * Code freeze for all projects' jbosstools-4.4.x branches will >>>>> start *Thursday >>>>> at 2pm PST / 5pm EST / 11pm CST*. >>>>> >>>>> (We're back to the old way of branching and updating root & parent >>>>> poms. >>>>> Did you enjoy the lightweight approach? Tell us!) >>>>> >>>>> * *build will run Thursday night* and be copied to /staging/ on >>>>> Friday >>>>> morning EST. >>>>> >>>>> * *From Fri until the end of the sprint, you should *NOT* push >>>>> anything >>>>> into the jbosstools-4.4.x stable branch unless it's a blocker fix >>>>> approved >>>>> by Alexey* >>>>> >>>>> ** *master branch is open for new work once you've created your >>>>> jbosstools-4.4.x branch. >>>>> >>>>> ---- >>>>> >>>>> Looking ahead... >>>>> >>>>> We will be moving from Neon.0.RC2 to RC4 next week as soon as the >>>>> *RC4 >>>>> bits are available, starting on Jun 8 or 9*. >>>>> >>>>> There will be a *respin on Jun 10* to move up to RC4. This will >>>>> hopefully the LAST build before *GA on June 14.* >>>>> >>>>> I hope to go rock climbing at a place call Bon Echo the weekend of >>>>> June >>>>> 11-12. So... please, if you need to cause/find/fix blockers, >>>>> please do so >>>>> before Jun 8 so they can be fixed at the same time as the TP >>>>> update on Jun >>>>> 9 -- thanks! >>>>> >>>>> -- >>>>> Nick Boldt :: JBoss by Red Hat >>>>> Productization Lead :: JBoss Tools & Dev Studio >>>>> http://nick.divbyzero.com >>>>> >>>>> >>>>> >>>>> -- >>>>> Nick Boldt :: JBoss by Red Hat >>>>> Productization Lead :: JBoss Tools & Dev Studio >>>>> http://nick.divbyzero.com >>>>> >>>>> _______________________________________________ >>>>> jbosstools-dev mailing list >>>>> jbosstools-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> jbosstools-dev mailing >>>> listjbosstools-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/jbosstools-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> jbosstools-dev mailing list >>>> jbosstools-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>>> >> >> >>> _______________________________________________ >>> jbosstools-dev mailing list >>> jbosstools-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> >> >> /max >> http://about.me/maxandersen /max http://about.me/maxandersen From jmaury at redhat.com Wed Jun 8 17:04:24 2016 From: jmaury at redhat.com (Jean-Francois Maury) Date: Wed, 8 Jun 2016 23:04:24 +0200 Subject: [jbosstools-dev] Docker connections in Docker Tooling - request for feedback In-Reply-To: <0751A0D6-0AE7-4239-98E7-EC773CF536E0@redhat.com> References: <629334CF-7EFD-4679-8AEF-3F136416A1F2@redhat.com> <5756F65D.4060000@redhat.com> <0751A0D6-0AE7-4239-98E7-EC773CF536E0@redhat.com> Message-ID: I would propose another option: when the refresh detects that the docker daemon is not reachable, it does not stop refreshing but rather switch to a failed state and increase the refresh timer (following a kind of fibonnacci or exponentioal factor). If the user expand and connection is in failed state, then we should reset the timer and try to fetch data. WDYT ? Jeff On Wed, Jun 8, 2016 at 2:03 PM, Martin Malina wrote: > Thanks for the suggestion. Yes, it's not a bad idea I think. I do > understand why they came up with the disabled state - when you have Docker > images view open, the view will keep being refreshed periodically, so > disabling the connection when the docker daemon is down makes some sense. > But yes, perhaps it could still be expandable in the Docker Explorer and > expanding would enable the connection. I will suggest this in the BZ. > > -Martin > > > > On 7. 6. 2016, at 18:29, Alexey Kazakov wrote: > > > > What if you make a docker connection always expandable and try to enable > > the connection when you are trying to expand it? > > > > On 06/07/2016 10:04 AM, Martin Malina wrote: > >> Hi all, > >> > >> We are looking into ways to improve the Docker Tooling UI in Eclipse > and would like to ask for help. > >> > >> Xavier and I discussed one scenario which is currently quite confusing, > it is described here: > >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=495600 > >> > >> In short, this is the use case: > >> 1. Start CDK > >> 2. Connect to Docker > >> 3. Stop CDK > >> 4. Start CDK > >> 5. Connect to Docker > >> - here I was failing for a long time until Xavier told me I needed to > click this "Enable Connection" button, to make the connection work again. > >> This issue was previously discussed here: > https://issues.jboss.org/browse/JBDS-3739 > >> > >> We would appreciate if any of you had any suggestions how to improve > this. > >> > >> Thanks > >> Martin > >> > >> -- > >> Martin Malina > >> JBoss QA Engineer > >> Red Hat Czech s.r.o. > >> Purkynova 99 > >> 612 45 Brno, Czech Republic > >> > >> Tel.: +420 532 294 265 > >> > >> > >> > >> > >> _______________________________________________ > >> jbosstools-dev mailing list > >> jbosstools-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > > _______________________________________________ > > jbosstools-dev mailing list > > jbosstools-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160608/ff412253/attachment.html From manderse at redhat.com Thu Jun 9 02:53:11 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Thu, 09 Jun 2016 08:53:11 +0200 Subject: [jbosstools-dev] Docker connections in Docker Tooling - request for feedback In-Reply-To: References: <629334CF-7EFD-4679-8AEF-3F136416A1F2@redhat.com> <5756F65D.4060000@redhat.com> <0751A0D6-0AE7-4239-98E7-EC773CF536E0@redhat.com> Message-ID: or just make it even simpler - if connection failed add a marker on the connection but don't empty the model. When clicking Refresh it will try again and if connection succeeds it goes back to refreshing regularly. No need for a second "Enable Connection" option in that IMO ? /max > I would propose another option: > when the refresh detects that the docker daemon is not reachable, it > does > not stop refreshing but rather switch to a failed state and increase > the > refresh timer (following a kind of fibonnacci or exponentioal factor). > If > the user expand and connection is in failed state, then we should > reset the > timer and try to fetch data. > > WDYT ? > Jeff > > On Wed, Jun 8, 2016 at 2:03 PM, Martin Malina > wrote: > >> Thanks for the suggestion. Yes, it's not a bad idea I think. I do >> understand why they came up with the disabled state - when you have >> Docker >> images view open, the view will keep being refreshed periodically, so >> disabling the connection when the docker daemon is down makes some >> sense. >> But yes, perhaps it could still be expandable in the Docker Explorer >> and >> expanding would enable the connection. I will suggest this in the BZ. >> >> -Martin >> >> >>> On 7. 6. 2016, at 18:29, Alexey Kazakov wrote: >>> >>> What if you make a docker connection always expandable and try to >>> enable >>> the connection when you are trying to expand it? >>> >>> On 06/07/2016 10:04 AM, Martin Malina wrote: >>>> Hi all, >>>> >>>> We are looking into ways to improve the Docker Tooling UI in >>>> Eclipse >> and would like to ask for help. >>>> >>>> Xavier and I discussed one scenario which is currently quite >>>> confusing, >> it is described here: >>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=495600 >>>> >>>> In short, this is the use case: >>>> 1. Start CDK >>>> 2. Connect to Docker >>>> 3. Stop CDK >>>> 4. Start CDK >>>> 5. Connect to Docker >>>> - here I was failing for a long time until Xavier told me I needed >>>> to >> click this "Enable Connection" button, to make the connection work >> again. >>>> This issue was previously discussed here: >> https://issues.jboss.org/browse/JBDS-3739 >>>> >>>> We would appreciate if any of you had any suggestions how to >>>> improve >> this. >>>> >>>> Thanks >>>> Martin >>>> >>>> -- >>>> Martin Malina >>>> JBoss QA Engineer >>>> Red Hat Czech s.r.o. >>>> Purkynova 99 >>>> 612 45 Brno, Czech Republic >>>> >>>> Tel.: +420 532 294 265 >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> jbosstools-dev mailing list >>>> jbosstools-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>> >>> _______________________________________________ >>> jbosstools-dev mailing list >>> jbosstools-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev /max http://about.me/maxandersen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160609/5b4e3a19/attachment.html From mmalina at redhat.com Thu Jun 9 04:53:50 2016 From: mmalina at redhat.com (Martin Malina) Date: Thu, 9 Jun 2016 10:53:50 +0200 Subject: [jbosstools-dev] Docker connections in Docker Tooling - request for feedback In-Reply-To: References: <629334CF-7EFD-4679-8AEF-3F136416A1F2@redhat.com> <5756F65D.4060000@redhat.com> <0751A0D6-0AE7-4239-98E7-EC773CF536E0@redhat.com> Message-ID: <83E47CFC-69C6-45B5-B73F-8C6BE57454B1@redhat.com> Thanks for the suggestions. I added it to the bugzilla [1]. If you had more suggestions, you may add it directly there (or I will do it if you just reply here) so that whoever starts working on that BZ has all the suggestions handy. Thanks, Martin [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=495600 -- Martin Malina JBoss QA Engineer Red Hat Czech s.r.o. Purkynova 99 612 45 Brno, Czech Republic Tel.: +420 532 294 265 > On 9. 6. 2016, at 8:53, Max Rydahl Andersen wrote: > > or just make it even simpler - if connection failed add a marker on the connection but don't empty the model. > When clicking Refresh it will try again and if connection succeeds it goes back to refreshing regularly. > > No need for a second "Enable Connection" option in that IMO ? > > /max > > > I would propose another option: > when the refresh detects that the docker daemon is not reachable, it does not stop refreshing but rather switch to a failed state and increase the refresh timer (following a kind of fibonnacci or exponentioal factor). If the user expand and connection is in failed state, then we should reset the timer and try to fetch data. > > WDYT ? > Jeff > > On Wed, Jun 8, 2016 at 2:03 PM, Martin Malina > wrote: > Thanks for the suggestion. Yes, it's not a bad idea I think. I do understand why they came up with the disabled state - when you have Docker images view open, the view will keep being refreshed periodically, so disabling the connection when the docker daemon is down makes some sense. But yes, perhaps it could still be expandable in the Docker Explorer and expanding would enable the connection. I will suggest this in the BZ. > > -Martin > > > > On 7. 6. 2016, at 18:29, Alexey Kazakov > wrote: > > > > What if you make a docker connection always expandable and try to enable > > the connection when you are trying to expand it? > > > > On 06/07/2016 10:04 AM, Martin Malina wrote: > >> Hi all, > >> > >> We are looking into ways to improve the Docker Tooling UI in Eclipse and would like to ask for help. > >> > >> Xavier and I discussed one scenario which is currently quite confusing, it is described here: > >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=495600 > >> > >> In short, this is the use case: > >> 1. Start CDK > >> 2. Connect to Docker > >> 3. Stop CDK > >> 4. Start CDK > >> 5. Connect to Docker > >> - here I was failing for a long time until Xavier told me I needed to click this "Enable Connection" button, to make the connection work again. > >> This issue was previously discussed here: https://issues.jboss.org/browse/JBDS-3739 > >> > >> We would appreciate if any of you had any suggestions how to improve this. > >> > >> Thanks > >> Martin > >> > >> -- > >> Martin Malina > >> JBoss QA Engineer > >> Red Hat Czech s.r.o. > >> Purkynova 99 > >> 612 45 Brno, Czech Republic > >> > >> Tel.: +420 532 294 265 > >> > >> > >> > >> > >> _______________________________________________ > >> jbosstools-dev mailing list > >> jbosstools-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > > _______________________________________________ > > jbosstools-dev mailing list > > jbosstools-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > > > /max > http://about.me/maxandersen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160609/e2f60028/attachment-0001.html From nboldt at redhat.com Thu Jun 9 12:28:05 2016 From: nboldt at redhat.com (Nick Boldt) Date: Thu, 9 Jun 2016 12:28:05 -0400 Subject: [jbosstools-dev] ACTION REQUIRED: Target Platform 4.60.0.Final-SNAPSHOT (JBT 4.4.0.Final / devstudio 10.0.0.GA) has been upversioned to Neon.0.RC4 Message-ID: Due to the urgent nature of this change, I've skipped the usual 48 waiting period and have just applied the changes needed to move from RC2+ to RC4a. ACTION REQUIRED: *please verify your component works with the updated target platform* as the devstudio build will spin tonight so that I can push it to QE and Denis can spin up the devsuite installer tomorrow. Changes: https://github.com/jbosstools/jbosstools-target-platforms/commits/4.60.x Note that the biggest change here is that *Jetty moves from 9.3.5 to 9.3.9.* There are also new versions of Docker Tools, RSE, WTP, Eclipse, etc. See diffs below for more details. gif diff: https://github.com/jbosstools/jbosstools-target-platforms/compare/e6fa09e...4.60.x p2diffs: http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevStudio_Master/job/jbosstools-target-platform--pull-request/36/ JIRA: https://issues.jboss.org/browse/JBIDE-22367 You can use the following to build & test the target-platform locally against your component(s). Build target-platform: $ cd /path/to/jbosstools-target-platforms/jbosstools/multiple $ git fetch origin 4.60.x && git checkout FETCH_HEAD $ mvn clean install Then, to test the new "multiple" target platform against your component's build: $ cd /path/to/your/jbosstools-component $ mvn clean verify -Dtpc.version=4.60.0.Final-SNAPSHOT -Dtpc.targetKind=multiple -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160609/dadb0e56/attachment.html From alkazako at redhat.com Fri Jun 10 13:44:52 2016 From: alkazako at redhat.com (Alexey Kazakov) Date: Fri, 10 Jun 2016 13:44:52 -0400 Subject: [jbosstools-dev] Memory Leak in Docker Containers View In-Reply-To: <1592696271.21662157.1465577781515.JavaMail.zimbra@redhat.com> References: <40BA6A78-9641-49AE-A195-44B1E66F4621@redhat.com> <448E7EFE-B1F5-4B47-9DA3-A61D4D7F6346@redhat.com> <575AD93E.3030609@redhat.com> <2146227611.21625920.1465571994966.JavaMail.zimbra@redhat.com> <575ADD1B.5020401@redhat.com> <1354374417.21656639.1465576731932.JavaMail.zimbra@redhat.com> <575AEE42.8050208@redhat.com> <1592696271.21662157.1465577781515.JavaMail.zimbra@redhat.com> Message-ID: <575AFC94.5010405@redhat.com> Moving to jbosstools-dev. OK. This memory leak seems to be bad. Please continue to work on proper bug fix and update for the Linux/Docker Tools for Neon but I'm afraid we don't have time to change anything in our Target Platform for devstudio 10 GA / JBoss Tools 4.4.0.Final at this point. Thanks. On 06/10/2016 12:56 PM, Jeff Johnston wrote: > Should be Neon only as status icons were added for Neon M1 milestone. There > may be other image leaks in Mars, but they are minor and no errors have shown > in our testing or customer usage. > > -- Jeff J. > > ----- Original Message ----- >> Is this bug in Neon branch only? What about Mars releases? >> >> >> On 06/10/2016 12:38 PM, Jeff Johnston wrote: >>> It appears that the issue I found has been around since Aug 2015 (Neon M1). >>> I have a fix >>> and there appears to be another possible leak in the DockerExplorerView >>> which I >>> am pushing a fix for currently. >>> >>> I noticed the memory leak the other day and during my testing I saw that >>> images >>> were being left behind to the point that the Eclipse MAT tool took notice >>> over a >>> short period and flagged it as a suspected memory leak. Docker Containers >>> get refreshed every 15 seconds so Views >>> that show them (Docker Containers View and Docker Explorer View) that use >>> icons need >>> to dispose of them properly. For the Docker Containers View, all >>> containers were being >>> given a new image each refresh period. The Explorer View isn't much of a >>> problem because >>> it is node-based and doesn't always show the full list of Containers. A >>> short list of Containers >>> will slow down the leak as will closing the View. >>> >>> My intention was to do a quick rebuild of the stable-5.0 branch and save it >>> as RC4a repo. If desired, >>> I can do a point release, but this requires more changes to all features >>> and pom files to renumber >>> them. Let me know if a point release is required. >>> >>> I will continue with the task of building an RC4a repo that will be saved >>> in the Linux Tools download >>> area. Neon users will have to use the updates-nightly-neon repo which will >>> have >>> the fix (same git branch is used to create the RC4a repo). >>> >>> -- Jeff J. >>> >>> ----- Original Message ----- >>>> When did it happen? How long do you have it in Docker Tools. >>>> >>>> Have you already fixed it? Released the updated 2.0.1? >>>> >>>> On 06/10/2016 11:19 AM, Jeff Johnston wrote: >>>>> This issue was introduced with a change to adding status icons in the >>>>> Containers View. It wasn't noticed because it requires a long time to >>>>> show (small image icons not being disposed of). >>>>> >>>>> -- Jeff J. >>>>> >>>>> ----- Original Message ----- >>>>>> We will conceder to include any updated in respin-b besides branding >>>>>> only if we have to fix some very bad issues. Real blocker. >>>>>> Is this issue is old or some new regression? >>>>>> >>>>>> On 06/10/2016 10:57 AM, Xavier Coulon wrote: >>>>>>> From my understanding, Jeff noticed the issue after letting Eclipse >>>>>>> run >>>>>>> all night long, but I don't remember if Eclipse was then unusable or >>>>>>> crashed. >>>>>>> Anyway, it could be serious enough it users have the Docker tooling >>>>>>> views >>>>>>> open in their workspace. >>>>>>> >>>>>>> Best regards, >>>>>>> Xavier >>>>>>>> On 10 Jun 2016, at 12:37, Alexey Kazakov wrote: >>>>>>>> >>>>>>>> >>>>>>>> How bad is that leak? >>>>>>>> >>>>>>>> >>>>>>>>> On Jun 10, 2016, at 4:33 AM, Xavier Coulon >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Fred, Alexey, >>>>>>>>> >>>>>>>>> Jeff J. found a memory leak in the Docker tooling. It's too late for >>>>>>>>> Neon.0 RC4/Final, but he proposes that we cut a Linux Tools 5.0.1 / >>>>>>>>> Docker Tooling 2.0.1 to address this specific issue. >>>>>>>>> Is this something that can be included in the upcoming "respin-b" >>>>>>>>> build >>>>>>>>> along with the branding updates ? I understand that Alexey initially >>>>>>>>> said that this ultimate build would not include any other bug fix, >>>>>>>>> but >>>>>>>>> nonetheless, I'm asking the question ;-) >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> /Xavier >>>>>>>>> >>>>>>>>>> Hi Xavier, >>>>>>>>>> >>>>>>>>>> Jeff here. I found a memory leak in the Docker Containers View. I >>>>>>>>>> believe it is fixed with my gerrit patch. If JBoss wants, I can >>>>>>>>>> create >>>>>>>>>> a >>>>>>>>>> special repo for them to use to remove this bug. The fix is too >>>>>>>>>> late >>>>>>>>>> for >>>>>>>>>> Neon, but we can cut a point release if necessary or wait until 5.1 >>>>>>>>>> and >>>>>>>>>> fix it in the updates-nightly-neon. >>>>>>>>>> >>>>>>>>>> The problem was with the images used for status in the Table. They >>>>>>>>>> were >>>>>>>>>> constantly being created via createImage() but never stored any >>>>>>>>>> where >>>>>>>>>> and >>>>>>>>>> never disposed. I simply created 3 images for status and return one >>>>>>>>>> of >>>>>>>>>> 3 >>>>>>>>>> for each table entry, then dispose of them in the Containers View >>>>>>>>>> dispose >>>>>>>>>> method. >>>>>>>>>> >>>>>>>>>> -- Jeff J. >> From nboldt at redhat.com Fri Jun 10 14:40:54 2016 From: nboldt at redhat.com (Nick Boldt) Date: Fri, 10 Jun 2016 14:40:54 -0400 Subject: [jbosstools-dev] No respin-a today; hope to have something on Monday or Tuesday Message-ID: Due to build issues last night and today brought on by branching & updating master to 4.4.1.Alpha1 (and having those bits "leak" into the 4.4.0.x builds), respin-a for 10.0.0.GA & 4.4.0.Final will not be ready in time today. I plan to start the process up again Sunday night (assuming I survive my climbing trip to Bon Echo) and will hopefully have something QE can use on Monday or Tuesday. Apologies, but too much change too fast at the last minute (target platform move to RC4, master updates to Alpha1, time lost to discussion and vetting of branding changes) have conspired to break the build. With the saddest of trombones, Nick -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160610/bb5d2825/attachment.html From jjohnstn at redhat.com Fri Jun 10 14:35:40 2016 From: jjohnstn at redhat.com (Jeff Johnston) Date: Fri, 10 Jun 2016 14:35:40 -0400 (EDT) Subject: [jbosstools-dev] Memory Leak in Docker Containers View In-Reply-To: <575AFC94.5010405@redhat.com> References: <575AD93E.3030609@redhat.com> <2146227611.21625920.1465571994966.JavaMail.zimbra@redhat.com> <575ADD1B.5020401@redhat.com> <1354374417.21656639.1465576731932.JavaMail.zimbra@redhat.com> <575AEE42.8050208@redhat.com> <1592696271.21662157.1465577781515.JavaMail.zimbra@redhat.com> <575AFC94.5010405@redhat.com> Message-ID: <939602854.21686748.1465583740694.JavaMail.zimbra@redhat.com> I have just made a build available with the patch in: http:/download.eclipse.org/linuxtools/update-neon-docker-rc4a -- Jeff J. ----- Original Message ----- > Moving to jbosstools-dev. > > OK. This memory leak seems to be bad. Please continue to work on proper > bug fix and update for the Linux/Docker Tools for Neon but I'm afraid we > don't have time to change anything in our Target Platform for devstudio > 10 GA / JBoss Tools 4.4.0.Final at this point. > > Thanks. > > On 06/10/2016 12:56 PM, Jeff Johnston wrote: > > Should be Neon only as status icons were added for Neon M1 milestone. > > There > > may be other image leaks in Mars, but they are minor and no errors have > > shown > > in our testing or customer usage. > > > > -- Jeff J. > > > > ----- Original Message ----- > >> Is this bug in Neon branch only? What about Mars releases? > >> > >> > >> On 06/10/2016 12:38 PM, Jeff Johnston wrote: > >>> It appears that the issue I found has been around since Aug 2015 (Neon > >>> M1). > >>> I have a fix > >>> and there appears to be another possible leak in the DockerExplorerView > >>> which I > >>> am pushing a fix for currently. > >>> > >>> I noticed the memory leak the other day and during my testing I saw that > >>> images > >>> were being left behind to the point that the Eclipse MAT tool took notice > >>> over a > >>> short period and flagged it as a suspected memory leak. Docker > >>> Containers > >>> get refreshed every 15 seconds so Views > >>> that show them (Docker Containers View and Docker Explorer View) that use > >>> icons need > >>> to dispose of them properly. For the Docker Containers View, all > >>> containers were being > >>> given a new image each refresh period. The Explorer View isn't much of a > >>> problem because > >>> it is node-based and doesn't always show the full list of Containers. A > >>> short list of Containers > >>> will slow down the leak as will closing the View. > >>> > >>> My intention was to do a quick rebuild of the stable-5.0 branch and save > >>> it > >>> as RC4a repo. If desired, > >>> I can do a point release, but this requires more changes to all features > >>> and pom files to renumber > >>> them. Let me know if a point release is required. > >>> > >>> I will continue with the task of building an RC4a repo that will be saved > >>> in the Linux Tools download > >>> area. Neon users will have to use the updates-nightly-neon repo which > >>> will > >>> have > >>> the fix (same git branch is used to create the RC4a repo). > >>> > >>> -- Jeff J. > >>> > >>> ----- Original Message ----- > >>>> When did it happen? How long do you have it in Docker Tools. > >>>> > >>>> Have you already fixed it? Released the updated 2.0.1? > >>>> > >>>> On 06/10/2016 11:19 AM, Jeff Johnston wrote: > >>>>> This issue was introduced with a change to adding status icons in the > >>>>> Containers View. It wasn't noticed because it requires a long time to > >>>>> show (small image icons not being disposed of). > >>>>> > >>>>> -- Jeff J. > >>>>> > >>>>> ----- Original Message ----- > >>>>>> We will conceder to include any updated in respin-b besides branding > >>>>>> only if we have to fix some very bad issues. Real blocker. > >>>>>> Is this issue is old or some new regression? > >>>>>> > >>>>>> On 06/10/2016 10:57 AM, Xavier Coulon wrote: > >>>>>>> From my understanding, Jeff noticed the issue after letting > >>>>>>> Eclipse > >>>>>>> run > >>>>>>> all night long, but I don't remember if Eclipse was then unusable > >>>>>>> or > >>>>>>> crashed. > >>>>>>> Anyway, it could be serious enough it users have the Docker tooling > >>>>>>> views > >>>>>>> open in their workspace. > >>>>>>> > >>>>>>> Best regards, > >>>>>>> Xavier > >>>>>>>> On 10 Jun 2016, at 12:37, Alexey Kazakov > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> How bad is that leak? > >>>>>>>> > >>>>>>>> > >>>>>>>>> On Jun 10, 2016, at 4:33 AM, Xavier Coulon > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> Fred, Alexey, > >>>>>>>>> > >>>>>>>>> Jeff J. found a memory leak in the Docker tooling. It's too late > >>>>>>>>> for > >>>>>>>>> Neon.0 RC4/Final, but he proposes that we cut a Linux Tools 5.0.1 / > >>>>>>>>> Docker Tooling 2.0.1 to address this specific issue. > >>>>>>>>> Is this something that can be included in the upcoming "respin-b" > >>>>>>>>> build > >>>>>>>>> along with the branding updates ? I understand that Alexey > >>>>>>>>> initially > >>>>>>>>> said that this ultimate build would not include any other bug fix, > >>>>>>>>> but > >>>>>>>>> nonetheless, I'm asking the question ;-) > >>>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> /Xavier > >>>>>>>>> > >>>>>>>>>> Hi Xavier, > >>>>>>>>>> > >>>>>>>>>> Jeff here. I found a memory leak in the Docker Containers View. > >>>>>>>>>> I > >>>>>>>>>> believe it is fixed with my gerrit patch. If JBoss wants, I can > >>>>>>>>>> create > >>>>>>>>>> a > >>>>>>>>>> special repo for them to use to remove this bug. The fix is too > >>>>>>>>>> late > >>>>>>>>>> for > >>>>>>>>>> Neon, but we can cut a point release if necessary or wait until > >>>>>>>>>> 5.1 > >>>>>>>>>> and > >>>>>>>>>> fix it in the updates-nightly-neon. > >>>>>>>>>> > >>>>>>>>>> The problem was with the images used for status in the Table. > >>>>>>>>>> They > >>>>>>>>>> were > >>>>>>>>>> constantly being created via createImage() but never stored any > >>>>>>>>>> where > >>>>>>>>>> and > >>>>>>>>>> never disposed. I simply created 3 images for status and return > >>>>>>>>>> one > >>>>>>>>>> of > >>>>>>>>>> 3 > >>>>>>>>>> for each table entry, then dispose of them in the Containers View > >>>>>>>>>> dispose > >>>>>>>>>> method. > >>>>>>>>>> > >>>>>>>>>> -- Jeff J. > >> > > From nboldt at redhat.com Fri Jun 10 15:08:40 2016 From: nboldt at redhat.com (Nick Boldt) Date: Fri, 10 Jun 2016 15:08:40 -0400 Subject: [jbosstools-dev] Memory Leak in Docker Containers View In-Reply-To: <939602854.21686748.1465583740694.JavaMail.zimbra@redhat.com> References: <575AD93E.3030609@redhat.com> <2146227611.21625920.1465571994966.JavaMail.zimbra@redhat.com> <575ADD1B.5020401@redhat.com> <1354374417.21656639.1465576731932.JavaMail.zimbra@redhat.com> <575AEE42.8050208@redhat.com> <1592696271.21662157.1465577781515.JavaMail.zimbra@redhat.com> <575AFC94.5010405@redhat.com> <939602854.21686748.1465583740694.JavaMail.zimbra@redhat.com> Message-ID: Please clarify: is this a blocker for devstudio 10.0.0.GA? Or something to pick up in a later sprint / release? Given we've slipped respin-a to Monday, and still have to rebrand everything, we probably have time to contain a small TP change like this. IFF it's a blocker. On Fri, Jun 10, 2016 at 2:35 PM, Jeff Johnston wrote: > I have just made a build available with the patch in: > > http:/download.eclipse.org/linuxtools/update-neon-docker-rc4a > > -- Jeff J. > > ----- Original Message ----- > > Moving to jbosstools-dev. > > > > OK. This memory leak seems to be bad. Please continue to work on proper > > bug fix and update for the Linux/Docker Tools for Neon but I'm afraid we > > don't have time to change anything in our Target Platform for devstudio > > 10 GA / JBoss Tools 4.4.0.Final at this point. > > > > Thanks. > > > > On 06/10/2016 12:56 PM, Jeff Johnston wrote: > > > Should be Neon only as status icons were added for Neon M1 milestone. > > > There > > > may be other image leaks in Mars, but they are minor and no errors have > > > shown > > > in our testing or customer usage. > > > > > > -- Jeff J. > > > > > > ----- Original Message ----- > > >> Is this bug in Neon branch only? What about Mars releases? > > >> > > >> > > >> On 06/10/2016 12:38 PM, Jeff Johnston wrote: > > >>> It appears that the issue I found has been around since Aug 2015 > (Neon > > >>> M1). > > >>> I have a fix > > >>> and there appears to be another possible leak in the > DockerExplorerView > > >>> which I > > >>> am pushing a fix for currently. > > >>> > > >>> I noticed the memory leak the other day and during my testing I saw > that > > >>> images > > >>> were being left behind to the point that the Eclipse MAT tool took > notice > > >>> over a > > >>> short period and flagged it as a suspected memory leak. Docker > > >>> Containers > > >>> get refreshed every 15 seconds so Views > > >>> that show them (Docker Containers View and Docker Explorer View) > that use > > >>> icons need > > >>> to dispose of them properly. For the Docker Containers View, all > > >>> containers were being > > >>> given a new image each refresh period. The Explorer View isn't much > of a > > >>> problem because > > >>> it is node-based and doesn't always show the full list of > Containers. A > > >>> short list of Containers > > >>> will slow down the leak as will closing the View. > > >>> > > >>> My intention was to do a quick rebuild of the stable-5.0 branch and > save > > >>> it > > >>> as RC4a repo. If desired, > > >>> I can do a point release, but this requires more changes to all > features > > >>> and pom files to renumber > > >>> them. Let me know if a point release is required. > > >>> > > >>> I will continue with the task of building an RC4a repo that will be > saved > > >>> in the Linux Tools download > > >>> area. Neon users will have to use the updates-nightly-neon repo > which > > >>> will > > >>> have > > >>> the fix (same git branch is used to create the RC4a repo). > > >>> > > >>> -- Jeff J. > > >>> > > >>> ----- Original Message ----- > > >>>> When did it happen? How long do you have it in Docker Tools. > > >>>> > > >>>> Have you already fixed it? Released the updated 2.0.1? > > >>>> > > >>>> On 06/10/2016 11:19 AM, Jeff Johnston wrote: > > >>>>> This issue was introduced with a change to adding status icons in > the > > >>>>> Containers View. It wasn't noticed because it requires a long > time to > > >>>>> show (small image icons not being disposed of). > > >>>>> > > >>>>> -- Jeff J. > > >>>>> > > >>>>> ----- Original Message ----- > > >>>>>> We will conceder to include any updated in respin-b besides > branding > > >>>>>> only if we have to fix some very bad issues. Real blocker. > > >>>>>> Is this issue is old or some new regression? > > >>>>>> > > >>>>>> On 06/10/2016 10:57 AM, Xavier Coulon wrote: > > >>>>>>> From my understanding, Jeff noticed the issue after letting > > >>>>>>> Eclipse > > >>>>>>> run > > >>>>>>> all night long, but I don't remember if Eclipse was then > unusable > > >>>>>>> or > > >>>>>>> crashed. > > >>>>>>> Anyway, it could be serious enough it users have the Docker > tooling > > >>>>>>> views > > >>>>>>> open in their workspace. > > >>>>>>> > > >>>>>>> Best regards, > > >>>>>>> Xavier > > >>>>>>>> On 10 Jun 2016, at 12:37, Alexey Kazakov > > >>>>>>>> wrote: > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> How bad is that leak? > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> On Jun 10, 2016, at 4:33 AM, Xavier Coulon > > > >>>>>>>>> wrote: > > >>>>>>>>> > > >>>>>>>>> Fred, Alexey, > > >>>>>>>>> > > >>>>>>>>> Jeff J. found a memory leak in the Docker tooling. It's too > late > > >>>>>>>>> for > > >>>>>>>>> Neon.0 RC4/Final, but he proposes that we cut a Linux Tools > 5.0.1 / > > >>>>>>>>> Docker Tooling 2.0.1 to address this specific issue. > > >>>>>>>>> Is this something that can be included in the upcoming > "respin-b" > > >>>>>>>>> build > > >>>>>>>>> along with the branding updates ? I understand that Alexey > > >>>>>>>>> initially > > >>>>>>>>> said that this ultimate build would not include any other bug > fix, > > >>>>>>>>> but > > >>>>>>>>> nonetheless, I'm asking the question ;-) > > >>>>>>>>> > > >>>>>>>>> Best regards, > > >>>>>>>>> /Xavier > > >>>>>>>>> > > >>>>>>>>>> Hi Xavier, > > >>>>>>>>>> > > >>>>>>>>>> Jeff here. I found a memory leak in the Docker Containers > View. > > >>>>>>>>>> I > > >>>>>>>>>> believe it is fixed with my gerrit patch. If JBoss wants, I > can > > >>>>>>>>>> create > > >>>>>>>>>> a > > >>>>>>>>>> special repo for them to use to remove this bug. The fix is > too > > >>>>>>>>>> late > > >>>>>>>>>> for > > >>>>>>>>>> Neon, but we can cut a point release if necessary or wait > until > > >>>>>>>>>> 5.1 > > >>>>>>>>>> and > > >>>>>>>>>> fix it in the updates-nightly-neon. > > >>>>>>>>>> > > >>>>>>>>>> The problem was with the images used for status in the Table. > > >>>>>>>>>> They > > >>>>>>>>>> were > > >>>>>>>>>> constantly being created via createImage() but never stored > any > > >>>>>>>>>> where > > >>>>>>>>>> and > > >>>>>>>>>> never disposed. I simply created 3 images for status and > return > > >>>>>>>>>> one > > >>>>>>>>>> of > > >>>>>>>>>> 3 > > >>>>>>>>>> for each table entry, then dispose of them in the Containers > View > > >>>>>>>>>> dispose > > >>>>>>>>>> method. > > >>>>>>>>>> > > >>>>>>>>>> -- Jeff J. > > >> > > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160610/42f5abe1/attachment-0001.html From jjohnstn at redhat.com Fri Jun 10 15:41:36 2016 From: jjohnstn at redhat.com (Jeff Johnston) Date: Fri, 10 Jun 2016 15:41:36 -0400 (EDT) Subject: [jbosstools-dev] Memory Leak in Docker Containers View In-Reply-To: References: <575ADD1B.5020401@redhat.com> <1354374417.21656639.1465576731932.JavaMail.zimbra@redhat.com> <575AEE42.8050208@redhat.com> <1592696271.21662157.1465577781515.JavaMail.zimbra@redhat.com> <575AFC94.5010405@redhat.com> <939602854.21686748.1465583740694.JavaMail.zimbra@redhat.com> Message-ID: <898979842.21700059.1465587696028.JavaMail.zimbra@redhat.com> I can't make the call that is a blocker. The problem has not been reported by users, even though it has been around since Neon M1. It only occurs if Eclipse is left up for a long period of time and the Docker Containers View is also in the tab list for the editor Window. However, when it occurs, Eclipse has to be restarted. I am trying to get the patch into a Neon rebuild if one occurs. Otherwise, I will point users to the updates-nightly-neon site. -- Jeff J. ----- Original Message ----- > Please clarify: is this a blocker for devstudio 10.0.0.GA? Or something to > pick up in a later sprint / release? > > Given we've slipped respin-a to Monday, and still have to rebrand > everything, we probably have time to contain a small TP change like this. > IFF it's a blocker. > > On Fri, Jun 10, 2016 at 2:35 PM, Jeff Johnston wrote: > > > I have just made a build available with the patch in: > > > > http:/download.eclipse.org/linuxtools/update-neon-docker-rc4a > > > > -- Jeff J. > > > > ----- Original Message ----- > > > Moving to jbosstools-dev. > > > > > > OK. This memory leak seems to be bad. Please continue to work on proper > > > bug fix and update for the Linux/Docker Tools for Neon but I'm afraid we > > > don't have time to change anything in our Target Platform for devstudio > > > 10 GA / JBoss Tools 4.4.0.Final at this point. > > > > > > Thanks. > > > > > > On 06/10/2016 12:56 PM, Jeff Johnston wrote: > > > > Should be Neon only as status icons were added for Neon M1 milestone. > > > > There > > > > may be other image leaks in Mars, but they are minor and no errors have > > > > shown > > > > in our testing or customer usage. > > > > > > > > -- Jeff J. > > > > > > > > ----- Original Message ----- > > > >> Is this bug in Neon branch only? What about Mars releases? > > > >> > > > >> > > > >> On 06/10/2016 12:38 PM, Jeff Johnston wrote: > > > >>> It appears that the issue I found has been around since Aug 2015 > > (Neon > > > >>> M1). > > > >>> I have a fix > > > >>> and there appears to be another possible leak in the > > DockerExplorerView > > > >>> which I > > > >>> am pushing a fix for currently. > > > >>> > > > >>> I noticed the memory leak the other day and during my testing I saw > > that > > > >>> images > > > >>> were being left behind to the point that the Eclipse MAT tool took > > notice > > > >>> over a > > > >>> short period and flagged it as a suspected memory leak. Docker > > > >>> Containers > > > >>> get refreshed every 15 seconds so Views > > > >>> that show them (Docker Containers View and Docker Explorer View) > > that use > > > >>> icons need > > > >>> to dispose of them properly. For the Docker Containers View, all > > > >>> containers were being > > > >>> given a new image each refresh period. The Explorer View isn't much > > of a > > > >>> problem because > > > >>> it is node-based and doesn't always show the full list of > > Containers. A > > > >>> short list of Containers > > > >>> will slow down the leak as will closing the View. > > > >>> > > > >>> My intention was to do a quick rebuild of the stable-5.0 branch and > > save > > > >>> it > > > >>> as RC4a repo. If desired, > > > >>> I can do a point release, but this requires more changes to all > > features > > > >>> and pom files to renumber > > > >>> them. Let me know if a point release is required. > > > >>> > > > >>> I will continue with the task of building an RC4a repo that will be > > saved > > > >>> in the Linux Tools download > > > >>> area. Neon users will have to use the updates-nightly-neon repo > > which > > > >>> will > > > >>> have > > > >>> the fix (same git branch is used to create the RC4a repo). > > > >>> > > > >>> -- Jeff J. > > > >>> > > > >>> ----- Original Message ----- > > > >>>> When did it happen? How long do you have it in Docker Tools. > > > >>>> > > > >>>> Have you already fixed it? Released the updated 2.0.1? > > > >>>> > > > >>>> On 06/10/2016 11:19 AM, Jeff Johnston wrote: > > > >>>>> This issue was introduced with a change to adding status icons in > > the > > > >>>>> Containers View. It wasn't noticed because it requires a long > > time to > > > >>>>> show (small image icons not being disposed of). > > > >>>>> > > > >>>>> -- Jeff J. > > > >>>>> > > > >>>>> ----- Original Message ----- > > > >>>>>> We will conceder to include any updated in respin-b besides > > branding > > > >>>>>> only if we have to fix some very bad issues. Real blocker. > > > >>>>>> Is this issue is old or some new regression? > > > >>>>>> > > > >>>>>> On 06/10/2016 10:57 AM, Xavier Coulon wrote: > > > >>>>>>> From my understanding, Jeff noticed the issue after letting > > > >>>>>>> Eclipse > > > >>>>>>> run > > > >>>>>>> all night long, but I don't remember if Eclipse was then > > unusable > > > >>>>>>> or > > > >>>>>>> crashed. > > > >>>>>>> Anyway, it could be serious enough it users have the Docker > > tooling > > > >>>>>>> views > > > >>>>>>> open in their workspace. > > > >>>>>>> > > > >>>>>>> Best regards, > > > >>>>>>> Xavier > > > >>>>>>>> On 10 Jun 2016, at 12:37, Alexey Kazakov > > > >>>>>>>> wrote: > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> How bad is that leak? > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>>> On Jun 10, 2016, at 4:33 AM, Xavier Coulon > > > > > >>>>>>>>> wrote: > > > >>>>>>>>> > > > >>>>>>>>> Fred, Alexey, > > > >>>>>>>>> > > > >>>>>>>>> Jeff J. found a memory leak in the Docker tooling. It's too > > late > > > >>>>>>>>> for > > > >>>>>>>>> Neon.0 RC4/Final, but he proposes that we cut a Linux Tools > > 5.0.1 / > > > >>>>>>>>> Docker Tooling 2.0.1 to address this specific issue. > > > >>>>>>>>> Is this something that can be included in the upcoming > > "respin-b" > > > >>>>>>>>> build > > > >>>>>>>>> along with the branding updates ? I understand that Alexey > > > >>>>>>>>> initially > > > >>>>>>>>> said that this ultimate build would not include any other bug > > fix, > > > >>>>>>>>> but > > > >>>>>>>>> nonetheless, I'm asking the question ;-) > > > >>>>>>>>> > > > >>>>>>>>> Best regards, > > > >>>>>>>>> /Xavier > > > >>>>>>>>> > > > >>>>>>>>>> Hi Xavier, > > > >>>>>>>>>> > > > >>>>>>>>>> Jeff here. I found a memory leak in the Docker Containers > > View. > > > >>>>>>>>>> I > > > >>>>>>>>>> believe it is fixed with my gerrit patch. If JBoss wants, I > > can > > > >>>>>>>>>> create > > > >>>>>>>>>> a > > > >>>>>>>>>> special repo for them to use to remove this bug. The fix is > > too > > > >>>>>>>>>> late > > > >>>>>>>>>> for > > > >>>>>>>>>> Neon, but we can cut a point release if necessary or wait > > until > > > >>>>>>>>>> 5.1 > > > >>>>>>>>>> and > > > >>>>>>>>>> fix it in the updates-nightly-neon. > > > >>>>>>>>>> > > > >>>>>>>>>> The problem was with the images used for status in the Table. > > > >>>>>>>>>> They > > > >>>>>>>>>> were > > > >>>>>>>>>> constantly being created via createImage() but never stored > > any > > > >>>>>>>>>> where > > > >>>>>>>>>> and > > > >>>>>>>>>> never disposed. I simply created 3 images for status and > > return > > > >>>>>>>>>> one > > > >>>>>>>>>> of > > > >>>>>>>>>> 3 > > > >>>>>>>>>> for each table entry, then dispose of them in the Containers > > View > > > >>>>>>>>>> dispose > > > >>>>>>>>>> method. > > > >>>>>>>>>> > > > >>>>>>>>>> -- Jeff J. > > > >> > > > > > > > > _______________________________________________ > > jbosstools-dev mailing list > > jbosstools-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > > > > -- > Nick Boldt :: JBoss by Red Hat > Productization Lead :: JBoss Tools & Dev Studio > http://nick.divbyzero.com > From alkazako at redhat.com Fri Jun 10 15:43:48 2016 From: alkazako at redhat.com (Alexey Kazakov) Date: Fri, 10 Jun 2016 15:43:48 -0400 Subject: [jbosstools-dev] Memory Leak in Docker Containers View In-Reply-To: References: <575AD93E.3030609@redhat.com> <2146227611.21625920.1465571994966.JavaMail.zimbra@redhat.com> <575ADD1B.5020401@redhat.com> <1354374417.21656639.1465576731932.JavaMail.zimbra@redhat.com> <575AEE42.8050208@redhat.com> <1592696271.21662157.1465577781515.JavaMail.zimbra@redhat.com> <575AFC94.5010405@redhat.com> <939602854.21686748.1465583740694.JavaMail.zimbra@redhat.com> Message-ID: <575B1874.70906@redhat.com> My main concern is that we don't have time to fix anything if there is something broken in that new docker. So IMO this issues is not critical enough to introduce even bigger risk for this release. This is a bad issue but not a blocker in the current circumstances. Jeff, where we can see the code difference for the docker tooling? Do you have a gerrit change, a PR or something? On 06/10/2016 03:08 PM, Nick Boldt wrote: > Please clarify: is this a blocker for devstudio 10.0.0.GA > ? Or something to pick up in a later sprint / release? > > Given we've slipped respin-a to Monday, and still have to rebrand > everything, we probably have time to contain a small TP change like > this. IFF it's a blocker. > > On Fri, Jun 10, 2016 at 2:35 PM, Jeff Johnston > wrote: > > I have just made a build available with the patch in: > > http:/download.eclipse.org/linuxtools/update-neon-docker-rc4a > > > -- Jeff J. > > ----- Original Message ----- > > Moving to jbosstools-dev. > > > > OK. This memory leak seems to be bad. Please continue to work on > proper > > bug fix and update for the Linux/Docker Tools for Neon but I'm > afraid we > > don't have time to change anything in our Target Platform for > devstudio > > 10 GA / JBoss Tools 4.4.0.Final at this point. > > > > Thanks. > > > > On 06/10/2016 12:56 PM, Jeff Johnston wrote: > > > Should be Neon only as status icons were added for Neon M1 > milestone. > > > There > > > may be other image leaks in Mars, but they are minor and no > errors have > > > shown > > > in our testing or customer usage. > > > > > > -- Jeff J. > > > > > > ----- Original Message ----- > > >> Is this bug in Neon branch only? What about Mars releases? > > >> > > >> > > >> On 06/10/2016 12:38 PM, Jeff Johnston wrote: > > >>> It appears that the issue I found has been around since Aug > 2015 (Neon > > >>> M1). > > >>> I have a fix > > >>> and there appears to be another possible leak in the > DockerExplorerView > > >>> which I > > >>> am pushing a fix for currently. > > >>> > > >>> I noticed the memory leak the other day and during my > testing I saw that > > >>> images > > >>> were being left behind to the point that the Eclipse MAT > tool took notice > > >>> over a > > >>> short period and flagged it as a suspected memory leak. Docker > > >>> Containers > > >>> get refreshed every 15 seconds so Views > > >>> that show them (Docker Containers View and Docker Explorer > View) that use > > >>> icons need > > >>> to dispose of them properly. For the Docker Containers > View, all > > >>> containers were being > > >>> given a new image each refresh period. The Explorer View > isn't much of a > > >>> problem because > > >>> it is node-based and doesn't always show the full list of > Containers. A > > >>> short list of Containers > > >>> will slow down the leak as will closing the View. > > >>> > > >>> My intention was to do a quick rebuild of the stable-5.0 > branch and save > > >>> it > > >>> as RC4a repo. If desired, > > >>> I can do a point release, but this requires more changes to > all features > > >>> and pom files to renumber > > >>> them. Let me know if a point release is required. > > >>> > > >>> I will continue with the task of building an RC4a repo that > will be saved > > >>> in the Linux Tools download > > >>> area. Neon users will have to use the updates-nightly-neon > repo which > > >>> will > > >>> have > > >>> the fix (same git branch is used to create the RC4a repo). > > >>> > > >>> -- Jeff J. > > >>> > > >>> ----- Original Message ----- > > >>>> When did it happen? How long do you have it in Docker Tools. > > >>>> > > >>>> Have you already fixed it? Released the updated 2.0.1? > > >>>> > > >>>> On 06/10/2016 11:19 AM, Jeff Johnston wrote: > > >>>>> This issue was introduced with a change to adding status > icons in the > > >>>>> Containers View. It wasn't noticed because it requires a > long time to > > >>>>> show (small image icons not being disposed of). > > >>>>> > > >>>>> -- Jeff J. > > >>>>> > > >>>>> ----- Original Message ----- > > >>>>>> We will conceder to include any updated in respin-b > besides branding > > >>>>>> only if we have to fix some very bad issues. Real blocker. > > >>>>>> Is this issue is old or some new regression? > > >>>>>> > > >>>>>> On 06/10/2016 10:57 AM, Xavier Coulon wrote: > > >>>>>>> From my understanding, Jeff noticed the issue after > letting > > >>>>>>> Eclipse > > >>>>>>> run > > >>>>>>> all night long, but I don't remember if Eclipse was > then unusable > > >>>>>>> or > > >>>>>>> crashed. > > >>>>>>> Anyway, it could be serious enough it users have the > Docker tooling > > >>>>>>> views > > >>>>>>> open in their workspace. > > >>>>>>> > > >>>>>>> Best regards, > > >>>>>>> Xavier > > >>>>>>>> On 10 Jun 2016, at 12:37, Alexey Kazakov > > > > >>>>>>>> wrote: > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> How bad is that leak? > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> On Jun 10, 2016, at 4:33 AM, Xavier Coulon > > > > >>>>>>>>> wrote: > > >>>>>>>>> > > >>>>>>>>> Fred, Alexey, > > >>>>>>>>> > > >>>>>>>>> Jeff J. found a memory leak in the Docker tooling. > It's too late > > >>>>>>>>> for > > >>>>>>>>> Neon.0 RC4/Final, but he proposes that we cut a Linux > Tools 5.0.1 / > > >>>>>>>>> Docker Tooling 2.0.1 to address this specific issue. > > >>>>>>>>> Is this something that can be included in the upcoming > "respin-b" > > >>>>>>>>> build > > >>>>>>>>> along with the branding updates ? I understand that Alexey > > >>>>>>>>> initially > > >>>>>>>>> said that this ultimate build would not include any > other bug fix, > > >>>>>>>>> but > > >>>>>>>>> nonetheless, I'm asking the question ;-) > > >>>>>>>>> > > >>>>>>>>> Best regards, > > >>>>>>>>> /Xavier > > >>>>>>>>> > > >>>>>>>>>> Hi Xavier, > > >>>>>>>>>> > > >>>>>>>>>> Jeff here. I found a memory leak in the Docker > Containers View. > > >>>>>>>>>> I > > >>>>>>>>>> believe it is fixed with my gerrit patch. If JBoss > wants, I can > > >>>>>>>>>> create > > >>>>>>>>>> a > > >>>>>>>>>> special repo for them to use to remove this bug. The > fix is too > > >>>>>>>>>> late > > >>>>>>>>>> for > > >>>>>>>>>> Neon, but we can cut a point release if necessary or > wait until > > >>>>>>>>>> 5.1 > > >>>>>>>>>> and > > >>>>>>>>>> fix it in the updates-nightly-neon. > > >>>>>>>>>> > > >>>>>>>>>> The problem was with the images used for status in > the Table. > > >>>>>>>>>> They > > >>>>>>>>>> were > > >>>>>>>>>> constantly being created via createImage() but never > stored any > > >>>>>>>>>> where > > >>>>>>>>>> and > > >>>>>>>>>> never disposed. I simply created 3 images for status > and return > > >>>>>>>>>> one > > >>>>>>>>>> of > > >>>>>>>>>> 3 > > >>>>>>>>>> for each table entry, then dispose of them in the > Containers View > > >>>>>>>>>> dispose > > >>>>>>>>>> method. > > >>>>>>>>>> > > >>>>>>>>>> -- Jeff J. > > >> > > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > > > -- > Nick Boldt :: JBoss by Red Hat > Productization Lead :: JBoss Tools & Dev Studio > http://nick.divbyzero.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160610/7dc856f7/attachment-0001.html From jjohnstn at redhat.com Fri Jun 10 15:50:17 2016 From: jjohnstn at redhat.com (Jeff Johnston) Date: Fri, 10 Jun 2016 15:50:17 -0400 (EDT) Subject: [jbosstools-dev] Memory Leak in Docker Containers View In-Reply-To: <575B1874.70906@redhat.com> References: <1354374417.21656639.1465576731932.JavaMail.zimbra@redhat.com> <575AEE42.8050208@redhat.com> <1592696271.21662157.1465577781515.JavaMail.zimbra@redhat.com> <575AFC94.5010405@redhat.com> <939602854.21686748.1465583740694.JavaMail.zimbra@redhat.com> <575B1874.70906@redhat.com> Message-ID: <1652038439.21701104.1465588216991.JavaMail.zimbra@redhat.com> The gerrit changes are the following: https://git.eclipse.org/r/#/c/75077/ https://git.eclipse.org/r/#/c/75088/ The first change is the one for Docker Containers View. The second contains a fix for Docker Explorer View and some actions. I understand your argument below. As mentioned, no user has seen it yet. You have the fix ready if someone reports it and it will be in the next sprint. -- Jeff J. ----- Original Message ----- > My main concern is that we don't have time to fix anything if there is > something broken in that new docker. So IMO this issues is not critical > enough to introduce even bigger risk for this release. > This is a bad issue but not a blocker in the current circumstances. > > Jeff, where we can see the code difference for the docker tooling? Do > you have a gerrit change, a PR or something? > > On 06/10/2016 03:08 PM, Nick Boldt wrote: > > Please clarify: is this a blocker for devstudio 10.0.0.GA > > ? Or something to pick up in a later sprint / release? > > > > Given we've slipped respin-a to Monday, and still have to rebrand > > everything, we probably have time to contain a small TP change like > > this. IFF it's a blocker. > > > > On Fri, Jun 10, 2016 at 2:35 PM, Jeff Johnston > > wrote: > > > > I have just made a build available with the patch in: > > > > http:/download.eclipse.org/linuxtools/update-neon-docker-rc4a > > > > > > -- Jeff J. > > > > ----- Original Message ----- > > > Moving to jbosstools-dev. > > > > > > OK. This memory leak seems to be bad. Please continue to work on > > proper > > > bug fix and update for the Linux/Docker Tools for Neon but I'm > > afraid we > > > don't have time to change anything in our Target Platform for > > devstudio > > > 10 GA / JBoss Tools 4.4.0.Final at this point. > > > > > > Thanks. > > > > > > On 06/10/2016 12:56 PM, Jeff Johnston wrote: > > > > Should be Neon only as status icons were added for Neon M1 > > milestone. > > > > There > > > > may be other image leaks in Mars, but they are minor and no > > errors have > > > > shown > > > > in our testing or customer usage. > > > > > > > > -- Jeff J. > > > > > > > > ----- Original Message ----- > > > >> Is this bug in Neon branch only? What about Mars releases? > > > >> > > > >> > > > >> On 06/10/2016 12:38 PM, Jeff Johnston wrote: > > > >>> It appears that the issue I found has been around since Aug > > 2015 (Neon > > > >>> M1). > > > >>> I have a fix > > > >>> and there appears to be another possible leak in the > > DockerExplorerView > > > >>> which I > > > >>> am pushing a fix for currently. > > > >>> > > > >>> I noticed the memory leak the other day and during my > > testing I saw that > > > >>> images > > > >>> were being left behind to the point that the Eclipse MAT > > tool took notice > > > >>> over a > > > >>> short period and flagged it as a suspected memory leak. Docker > > > >>> Containers > > > >>> get refreshed every 15 seconds so Views > > > >>> that show them (Docker Containers View and Docker Explorer > > View) that use > > > >>> icons need > > > >>> to dispose of them properly. For the Docker Containers > > View, all > > > >>> containers were being > > > >>> given a new image each refresh period. The Explorer View > > isn't much of a > > > >>> problem because > > > >>> it is node-based and doesn't always show the full list of > > Containers. A > > > >>> short list of Containers > > > >>> will slow down the leak as will closing the View. > > > >>> > > > >>> My intention was to do a quick rebuild of the stable-5.0 > > branch and save > > > >>> it > > > >>> as RC4a repo. If desired, > > > >>> I can do a point release, but this requires more changes to > > all features > > > >>> and pom files to renumber > > > >>> them. Let me know if a point release is required. > > > >>> > > > >>> I will continue with the task of building an RC4a repo that > > will be saved > > > >>> in the Linux Tools download > > > >>> area. Neon users will have to use the updates-nightly-neon > > repo which > > > >>> will > > > >>> have > > > >>> the fix (same git branch is used to create the RC4a repo). > > > >>> > > > >>> -- Jeff J. > > > >>> > > > >>> ----- Original Message ----- > > > >>>> When did it happen? How long do you have it in Docker Tools. > > > >>>> > > > >>>> Have you already fixed it? Released the updated 2.0.1? > > > >>>> > > > >>>> On 06/10/2016 11:19 AM, Jeff Johnston wrote: > > > >>>>> This issue was introduced with a change to adding status > > icons in the > > > >>>>> Containers View. It wasn't noticed because it requires a > > long time to > > > >>>>> show (small image icons not being disposed of). > > > >>>>> > > > >>>>> -- Jeff J. > > > >>>>> > > > >>>>> ----- Original Message ----- > > > >>>>>> We will conceder to include any updated in respin-b > > besides branding > > > >>>>>> only if we have to fix some very bad issues. Real blocker. > > > >>>>>> Is this issue is old or some new regression? > > > >>>>>> > > > >>>>>> On 06/10/2016 10:57 AM, Xavier Coulon wrote: > > > >>>>>>> From my understanding, Jeff noticed the issue after > > letting > > > >>>>>>> Eclipse > > > >>>>>>> run > > > >>>>>>> all night long, but I don't remember if Eclipse was > > then unusable > > > >>>>>>> or > > > >>>>>>> crashed. > > > >>>>>>> Anyway, it could be serious enough it users have the > > Docker tooling > > > >>>>>>> views > > > >>>>>>> open in their workspace. > > > >>>>>>> > > > >>>>>>> Best regards, > > > >>>>>>> Xavier > > > >>>>>>>> On 10 Jun 2016, at 12:37, Alexey Kazakov > > > > > > >>>>>>>> wrote: > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> How bad is that leak? > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>>> On Jun 10, 2016, at 4:33 AM, Xavier Coulon > > > > > > >>>>>>>>> wrote: > > > >>>>>>>>> > > > >>>>>>>>> Fred, Alexey, > > > >>>>>>>>> > > > >>>>>>>>> Jeff J. found a memory leak in the Docker tooling. > > It's too late > > > >>>>>>>>> for > > > >>>>>>>>> Neon.0 RC4/Final, but he proposes that we cut a Linux > > Tools 5.0.1 / > > > >>>>>>>>> Docker Tooling 2.0.1 to address this specific issue. > > > >>>>>>>>> Is this something that can be included in the upcoming > > "respin-b" > > > >>>>>>>>> build > > > >>>>>>>>> along with the branding updates ? I understand that Alexey > > > >>>>>>>>> initially > > > >>>>>>>>> said that this ultimate build would not include any > > other bug fix, > > > >>>>>>>>> but > > > >>>>>>>>> nonetheless, I'm asking the question ;-) > > > >>>>>>>>> > > > >>>>>>>>> Best regards, > > > >>>>>>>>> /Xavier > > > >>>>>>>>> > > > >>>>>>>>>> Hi Xavier, > > > >>>>>>>>>> > > > >>>>>>>>>> Jeff here. I found a memory leak in the Docker > > Containers View. > > > >>>>>>>>>> I > > > >>>>>>>>>> believe it is fixed with my gerrit patch. If JBoss > > wants, I can > > > >>>>>>>>>> create > > > >>>>>>>>>> a > > > >>>>>>>>>> special repo for them to use to remove this bug. The > > fix is too > > > >>>>>>>>>> late > > > >>>>>>>>>> for > > > >>>>>>>>>> Neon, but we can cut a point release if necessary or > > wait until > > > >>>>>>>>>> 5.1 > > > >>>>>>>>>> and > > > >>>>>>>>>> fix it in the updates-nightly-neon. > > > >>>>>>>>>> > > > >>>>>>>>>> The problem was with the images used for status in > > the Table. > > > >>>>>>>>>> They > > > >>>>>>>>>> were > > > >>>>>>>>>> constantly being created via createImage() but never > > stored any > > > >>>>>>>>>> where > > > >>>>>>>>>> and > > > >>>>>>>>>> never disposed. I simply created 3 images for status > > and return > > > >>>>>>>>>> one > > > >>>>>>>>>> of > > > >>>>>>>>>> 3 > > > >>>>>>>>>> for each table entry, then dispose of them in the > > Containers View > > > >>>>>>>>>> dispose > > > >>>>>>>>>> method. > > > >>>>>>>>>> > > > >>>>>>>>>> -- Jeff J. > > > >> > > > > > > > > _______________________________________________ > > jbosstools-dev mailing list > > jbosstools-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > > > > > > > > -- > > Nick Boldt :: JBoss by Red Hat > > Productization Lead :: JBoss Tools & Dev Studio > > http://nick.divbyzero.com > > From aer-bot at ctrlflow.com Sun Jun 12 23:30:00 2016 From: aer-bot at ctrlflow.com (Automated Error Reporting Bot) Date: Mon, 13 Jun 2016 03:30:00 +0000 (UTC) Subject: [jbosstools-dev] [aeri] Weekly JBoss Tools Error Reports Digest Message-ID: <234456925.3.1465788600723.JavaMail.ec2-user@aeri-rh> An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160613/3f87b5b0/attachment-0001.html From xcoulon at redhat.com Mon Jun 13 03:15:25 2016 From: xcoulon at redhat.com (Xavier Coulon) Date: Mon, 13 Jun 2016 09:15:25 +0200 Subject: [jbosstools-dev] Memory Leak in Docker Containers View In-Reply-To: <1652038439.21701104.1465588216991.JavaMail.zimbra@redhat.com> References: <1354374417.21656639.1465576731932.JavaMail.zimbra@redhat.com> <575AEE42.8050208@redhat.com> <1592696271.21662157.1465577781515.JavaMail.zimbra@redhat.com> <575AFC94.5010405@redhat.com> <939602854.21686748.1465583740694.JavaMail.zimbra@redhat.com> <575B1874.70906@redhat.com> <1652038439.21701104.1465588216991.JavaMail.zimbra@redhat.com> Message-ID: <12095954-E732-48CF-9A7A-DEF2459956AF@redhat.com> Thanks a lot, Jeff ! Best regards, Xavier > On 10 Jun 2016, at 21:50, Jeff Johnston wrote: > > The gerrit changes are the following: > > https://git.eclipse.org/r/#/c/75077/ > https://git.eclipse.org/r/#/c/75088/ > > The first change is the one for Docker Containers View. The second contains > a fix for Docker Explorer View and some actions. > > I understand your argument below. As mentioned, no user has seen it yet. > You have the fix ready if someone reports it and it will be in the next > sprint. > > -- Jeff J. > > ----- Original Message ----- >> My main concern is that we don't have time to fix anything if there is >> something broken in that new docker. So IMO this issues is not critical >> enough to introduce even bigger risk for this release. >> This is a bad issue but not a blocker in the current circumstances. >> >> Jeff, where we can see the code difference for the docker tooling? Do >> you have a gerrit change, a PR or something? >> >> On 06/10/2016 03:08 PM, Nick Boldt wrote: >>> Please clarify: is this a blocker for devstudio 10.0.0.GA >>> ? Or something to pick up in a later sprint / release? >>> >>> Given we've slipped respin-a to Monday, and still have to rebrand >>> everything, we probably have time to contain a small TP change like >>> this. IFF it's a blocker. >>> >>> On Fri, Jun 10, 2016 at 2:35 PM, Jeff Johnston >> > wrote: >>> >>> I have just made a build available with the patch in: >>> >>> http:/download.eclipse.org/linuxtools/update-neon-docker-rc4a >>> >>> >>> -- Jeff J. >>> >>> ----- Original Message ----- >>>> Moving to jbosstools-dev. >>>> >>>> OK. This memory leak seems to be bad. Please continue to work on >>> proper >>>> bug fix and update for the Linux/Docker Tools for Neon but I'm >>> afraid we >>>> don't have time to change anything in our Target Platform for >>> devstudio >>>> 10 GA / JBoss Tools 4.4.0.Final at this point. >>>> >>>> Thanks. >>>> >>>> On 06/10/2016 12:56 PM, Jeff Johnston wrote: >>>>> Should be Neon only as status icons were added for Neon M1 >>> milestone. >>>>> There >>>>> may be other image leaks in Mars, but they are minor and no >>> errors have >>>>> shown >>>>> in our testing or customer usage. >>>>> >>>>> -- Jeff J. >>>>> >>>>> ----- Original Message ----- >>>>>> Is this bug in Neon branch only? What about Mars releases? >>>>>> >>>>>> >>>>>> On 06/10/2016 12:38 PM, Jeff Johnston wrote: >>>>>>> It appears that the issue I found has been around since Aug >>> 2015 (Neon >>>>>>> M1). >>>>>>> I have a fix >>>>>>> and there appears to be another possible leak in the >>> DockerExplorerView >>>>>>> which I >>>>>>> am pushing a fix for currently. >>>>>>> >>>>>>> I noticed the memory leak the other day and during my >>> testing I saw that >>>>>>> images >>>>>>> were being left behind to the point that the Eclipse MAT >>> tool took notice >>>>>>> over a >>>>>>> short period and flagged it as a suspected memory leak. Docker >>>>>>> Containers >>>>>>> get refreshed every 15 seconds so Views >>>>>>> that show them (Docker Containers View and Docker Explorer >>> View) that use >>>>>>> icons need >>>>>>> to dispose of them properly. For the Docker Containers >>> View, all >>>>>>> containers were being >>>>>>> given a new image each refresh period. The Explorer View >>> isn't much of a >>>>>>> problem because >>>>>>> it is node-based and doesn't always show the full list of >>> Containers. A >>>>>>> short list of Containers >>>>>>> will slow down the leak as will closing the View. >>>>>>> >>>>>>> My intention was to do a quick rebuild of the stable-5.0 >>> branch and save >>>>>>> it >>>>>>> as RC4a repo. If desired, >>>>>>> I can do a point release, but this requires more changes to >>> all features >>>>>>> and pom files to renumber >>>>>>> them. Let me know if a point release is required. >>>>>>> >>>>>>> I will continue with the task of building an RC4a repo that >>> will be saved >>>>>>> in the Linux Tools download >>>>>>> area. Neon users will have to use the updates-nightly-neon >>> repo which >>>>>>> will >>>>>>> have >>>>>>> the fix (same git branch is used to create the RC4a repo). >>>>>>> >>>>>>> -- Jeff J. >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> When did it happen? How long do you have it in Docker Tools. >>>>>>>> >>>>>>>> Have you already fixed it? Released the updated 2.0.1? >>>>>>>> >>>>>>>> On 06/10/2016 11:19 AM, Jeff Johnston wrote: >>>>>>>>> This issue was introduced with a change to adding status >>> icons in the >>>>>>>>> Containers View. It wasn't noticed because it requires a >>> long time to >>>>>>>>> show (small image icons not being disposed of). >>>>>>>>> >>>>>>>>> -- Jeff J. >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>>> We will conceder to include any updated in respin-b >>> besides branding >>>>>>>>>> only if we have to fix some very bad issues. Real blocker. >>>>>>>>>> Is this issue is old or some new regression? >>>>>>>>>> >>>>>>>>>> On 06/10/2016 10:57 AM, Xavier Coulon wrote: >>>>>>>>>>> From my understanding, Jeff noticed the issue after >>> letting >>>>>>>>>>> Eclipse >>>>>>>>>>> run >>>>>>>>>>> all night long, but I don't remember if Eclipse was >>> then unusable >>>>>>>>>>> or >>>>>>>>>>> crashed. >>>>>>>>>>> Anyway, it could be serious enough it users have the >>> Docker tooling >>>>>>>>>>> views >>>>>>>>>>> open in their workspace. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Xavier >>>>>>>>>>>> On 10 Jun 2016, at 12:37, Alexey Kazakov >>> > >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> How bad is that leak? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Jun 10, 2016, at 4:33 AM, Xavier Coulon >>> > >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Fred, Alexey, >>>>>>>>>>>>> >>>>>>>>>>>>> Jeff J. found a memory leak in the Docker tooling. >>> It's too late >>>>>>>>>>>>> for >>>>>>>>>>>>> Neon.0 RC4/Final, but he proposes that we cut a Linux >>> Tools 5.0.1 / >>>>>>>>>>>>> Docker Tooling 2.0.1 to address this specific issue. >>>>>>>>>>>>> Is this something that can be included in the upcoming >>> "respin-b" >>>>>>>>>>>>> build >>>>>>>>>>>>> along with the branding updates ? I understand that Alexey >>>>>>>>>>>>> initially >>>>>>>>>>>>> said that this ultimate build would not include any >>> other bug fix, >>>>>>>>>>>>> but >>>>>>>>>>>>> nonetheless, I'm asking the question ;-) >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> /Xavier >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Xavier, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jeff here. I found a memory leak in the Docker >>> Containers View. >>>>>>>>>>>>>> I >>>>>>>>>>>>>> believe it is fixed with my gerrit patch. If JBoss >>> wants, I can >>>>>>>>>>>>>> create >>>>>>>>>>>>>> a >>>>>>>>>>>>>> special repo for them to use to remove this bug. The >>> fix is too >>>>>>>>>>>>>> late >>>>>>>>>>>>>> for >>>>>>>>>>>>>> Neon, but we can cut a point release if necessary or >>> wait until >>>>>>>>>>>>>> 5.1 >>>>>>>>>>>>>> and >>>>>>>>>>>>>> fix it in the updates-nightly-neon. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The problem was with the images used for status in >>> the Table. >>>>>>>>>>>>>> They >>>>>>>>>>>>>> were >>>>>>>>>>>>>> constantly being created via createImage() but never >>> stored any >>>>>>>>>>>>>> where >>>>>>>>>>>>>> and >>>>>>>>>>>>>> never disposed. I simply created 3 images for status >>> and return >>>>>>>>>>>>>> one >>>>>>>>>>>>>> of >>>>>>>>>>>>>> 3 >>>>>>>>>>>>>> for each table entry, then dispose of them in the >>> Containers View >>>>>>>>>>>>>> dispose >>>>>>>>>>>>>> method. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- Jeff J. >>>>>> >>>> >>>> >>> _______________________________________________ >>> jbosstools-dev mailing list >>> jbosstools-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>> >>> >>> >>> >>> -- >>> Nick Boldt :: JBoss by Red Hat >>> Productization Lead :: JBoss Tools & Dev Studio >>> http://nick.divbyzero.com >> >> > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev From xcoulon at redhat.com Mon Jun 13 09:47:55 2016 From: xcoulon at redhat.com (Xavier Coulon) Date: Mon, 13 Jun 2016 15:47:55 +0200 Subject: [jbosstools-dev] Memory Leak in Docker Containers View In-Reply-To: <1652038439.21701104.1465588216991.JavaMail.zimbra@redhat.com> References: <1354374417.21656639.1465576731932.JavaMail.zimbra@redhat.com> <575AEE42.8050208@redhat.com> <1592696271.21662157.1465577781515.JavaMail.zimbra@redhat.com> <575AFC94.5010405@redhat.com> <939602854.21686748.1465583740694.JavaMail.zimbra@redhat.com> <575B1874.70906@redhat.com> <1652038439.21701104.1465588216991.JavaMail.zimbra@redhat.com> Message-ID: <38067D5A-963E-4AB0-A755-EFAFB6EE77C6@redhat.com> Jeff, To clarify: since Linux Tools 5.0.0.RC4/Docker tooling 2.0.0.RC4 were already released, are these fixes going to be included in Docker tooling 2.0.0.Final or do we need to make a 2.0.1 release ? Best regards, Xavier > On 10 Jun 2016, at 21:50, Jeff Johnston wrote: > > The gerrit changes are the following: > > https://git.eclipse.org/r/#/c/75077/ > https://git.eclipse.org/r/#/c/75088/ > > The first change is the one for Docker Containers View. The second contains > a fix for Docker Explorer View and some actions. > > I understand your argument below. As mentioned, no user has seen it yet. > You have the fix ready if someone reports it and it will be in the next > sprint. > > -- Jeff J. > > ----- Original Message ----- >> My main concern is that we don't have time to fix anything if there is >> something broken in that new docker. So IMO this issues is not critical >> enough to introduce even bigger risk for this release. >> This is a bad issue but not a blocker in the current circumstances. >> >> Jeff, where we can see the code difference for the docker tooling? Do >> you have a gerrit change, a PR or something? >> >> On 06/10/2016 03:08 PM, Nick Boldt wrote: >>> Please clarify: is this a blocker for devstudio 10.0.0.GA >>> ? Or something to pick up in a later sprint / release? >>> >>> Given we've slipped respin-a to Monday, and still have to rebrand >>> everything, we probably have time to contain a small TP change like >>> this. IFF it's a blocker. >>> >>> On Fri, Jun 10, 2016 at 2:35 PM, Jeff Johnston >> > wrote: >>> >>> I have just made a build available with the patch in: >>> >>> http:/download.eclipse.org/linuxtools/update-neon-docker-rc4a >>> >>> >>> -- Jeff J. >>> >>> ----- Original Message ----- >>>> Moving to jbosstools-dev. >>>> >>>> OK. This memory leak seems to be bad. Please continue to work on >>> proper >>>> bug fix and update for the Linux/Docker Tools for Neon but I'm >>> afraid we >>>> don't have time to change anything in our Target Platform for >>> devstudio >>>> 10 GA / JBoss Tools 4.4.0.Final at this point. >>>> >>>> Thanks. >>>> >>>> On 06/10/2016 12:56 PM, Jeff Johnston wrote: >>>>> Should be Neon only as status icons were added for Neon M1 >>> milestone. >>>>> There >>>>> may be other image leaks in Mars, but they are minor and no >>> errors have >>>>> shown >>>>> in our testing or customer usage. >>>>> >>>>> -- Jeff J. >>>>> >>>>> ----- Original Message ----- >>>>>> Is this bug in Neon branch only? What about Mars releases? >>>>>> >>>>>> >>>>>> On 06/10/2016 12:38 PM, Jeff Johnston wrote: >>>>>>> It appears that the issue I found has been around since Aug >>> 2015 (Neon >>>>>>> M1). >>>>>>> I have a fix >>>>>>> and there appears to be another possible leak in the >>> DockerExplorerView >>>>>>> which I >>>>>>> am pushing a fix for currently. >>>>>>> >>>>>>> I noticed the memory leak the other day and during my >>> testing I saw that >>>>>>> images >>>>>>> were being left behind to the point that the Eclipse MAT >>> tool took notice >>>>>>> over a >>>>>>> short period and flagged it as a suspected memory leak. Docker >>>>>>> Containers >>>>>>> get refreshed every 15 seconds so Views >>>>>>> that show them (Docker Containers View and Docker Explorer >>> View) that use >>>>>>> icons need >>>>>>> to dispose of them properly. For the Docker Containers >>> View, all >>>>>>> containers were being >>>>>>> given a new image each refresh period. The Explorer View >>> isn't much of a >>>>>>> problem because >>>>>>> it is node-based and doesn't always show the full list of >>> Containers. A >>>>>>> short list of Containers >>>>>>> will slow down the leak as will closing the View. >>>>>>> >>>>>>> My intention was to do a quick rebuild of the stable-5.0 >>> branch and save >>>>>>> it >>>>>>> as RC4a repo. If desired, >>>>>>> I can do a point release, but this requires more changes to >>> all features >>>>>>> and pom files to renumber >>>>>>> them. Let me know if a point release is required. >>>>>>> >>>>>>> I will continue with the task of building an RC4a repo that >>> will be saved >>>>>>> in the Linux Tools download >>>>>>> area. Neon users will have to use the updates-nightly-neon >>> repo which >>>>>>> will >>>>>>> have >>>>>>> the fix (same git branch is used to create the RC4a repo). >>>>>>> >>>>>>> -- Jeff J. >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> When did it happen? How long do you have it in Docker Tools. >>>>>>>> >>>>>>>> Have you already fixed it? Released the updated 2.0.1? >>>>>>>> >>>>>>>> On 06/10/2016 11:19 AM, Jeff Johnston wrote: >>>>>>>>> This issue was introduced with a change to adding status >>> icons in the >>>>>>>>> Containers View. It wasn't noticed because it requires a >>> long time to >>>>>>>>> show (small image icons not being disposed of). >>>>>>>>> >>>>>>>>> -- Jeff J. >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>>> We will conceder to include any updated in respin-b >>> besides branding >>>>>>>>>> only if we have to fix some very bad issues. Real blocker. >>>>>>>>>> Is this issue is old or some new regression? >>>>>>>>>> >>>>>>>>>> On 06/10/2016 10:57 AM, Xavier Coulon wrote: >>>>>>>>>>> From my understanding, Jeff noticed the issue after >>> letting >>>>>>>>>>> Eclipse >>>>>>>>>>> run >>>>>>>>>>> all night long, but I don't remember if Eclipse was >>> then unusable >>>>>>>>>>> or >>>>>>>>>>> crashed. >>>>>>>>>>> Anyway, it could be serious enough it users have the >>> Docker tooling >>>>>>>>>>> views >>>>>>>>>>> open in their workspace. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Xavier >>>>>>>>>>>> On 10 Jun 2016, at 12:37, Alexey Kazakov >>> > >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> How bad is that leak? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Jun 10, 2016, at 4:33 AM, Xavier Coulon >>> > >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Fred, Alexey, >>>>>>>>>>>>> >>>>>>>>>>>>> Jeff J. found a memory leak in the Docker tooling. >>> It's too late >>>>>>>>>>>>> for >>>>>>>>>>>>> Neon.0 RC4/Final, but he proposes that we cut a Linux >>> Tools 5.0.1 / >>>>>>>>>>>>> Docker Tooling 2.0.1 to address this specific issue. >>>>>>>>>>>>> Is this something that can be included in the upcoming >>> "respin-b" >>>>>>>>>>>>> build >>>>>>>>>>>>> along with the branding updates ? I understand that Alexey >>>>>>>>>>>>> initially >>>>>>>>>>>>> said that this ultimate build would not include any >>> other bug fix, >>>>>>>>>>>>> but >>>>>>>>>>>>> nonetheless, I'm asking the question ;-) >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> /Xavier >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Xavier, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jeff here. I found a memory leak in the Docker >>> Containers View. >>>>>>>>>>>>>> I >>>>>>>>>>>>>> believe it is fixed with my gerrit patch. If JBoss >>> wants, I can >>>>>>>>>>>>>> create >>>>>>>>>>>>>> a >>>>>>>>>>>>>> special repo for them to use to remove this bug. The >>> fix is too >>>>>>>>>>>>>> late >>>>>>>>>>>>>> for >>>>>>>>>>>>>> Neon, but we can cut a point release if necessary or >>> wait until >>>>>>>>>>>>>> 5.1 >>>>>>>>>>>>>> and >>>>>>>>>>>>>> fix it in the updates-nightly-neon. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The problem was with the images used for status in >>> the Table. >>>>>>>>>>>>>> They >>>>>>>>>>>>>> were >>>>>>>>>>>>>> constantly being created via createImage() but never >>> stored any >>>>>>>>>>>>>> where >>>>>>>>>>>>>> and >>>>>>>>>>>>>> never disposed. I simply created 3 images for status >>> and return >>>>>>>>>>>>>> one >>>>>>>>>>>>>> of >>>>>>>>>>>>>> 3 >>>>>>>>>>>>>> for each table entry, then dispose of them in the >>> Containers View >>>>>>>>>>>>>> dispose >>>>>>>>>>>>>> method. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- Jeff J. >>>>>> >>>> >>>> >>> _______________________________________________ >>> jbosstools-dev mailing list >>> jbosstools-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>> >>> >>> >>> >>> -- >>> Nick Boldt :: JBoss by Red Hat >>> Productization Lead :: JBoss Tools & Dev Studio >>> http://nick.divbyzero.com >> >> > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev From jjohnstn at redhat.com Mon Jun 13 12:00:55 2016 From: jjohnstn at redhat.com (Jeff Johnston) Date: Mon, 13 Jun 2016 12:00:55 -0400 (EDT) Subject: [jbosstools-dev] Memory Leak in Docker Containers View In-Reply-To: <38067D5A-963E-4AB0-A755-EFAFB6EE77C6@redhat.com> References: <1592696271.21662157.1465577781515.JavaMail.zimbra@redhat.com> <575AFC94.5010405@redhat.com> <939602854.21686748.1465583740694.JavaMail.zimbra@redhat.com> <575B1874.70906@redhat.com> <1652038439.21701104.1465588216991.JavaMail.zimbra@redhat.com> <38067D5A-963E-4AB0-A755-EFAFB6EE77C6@redhat.com> Message-ID: <1522580708.22058243.1465833655982.JavaMail.zimbra@redhat.com> Normally, RC4 becomes the final release. Eclipse does not like rebulding unless it is critical. The bug in question is not critical because it doesn't show itself for a long time of usage. That said, I have been given permission to update if Neon rebuilds for another critical issue. I have created a 5.0.0 RC4a and Docker 2.0.0 RC4a repo with fix and updated the aggregation specs. If Neon rebuilds for any reason, it will get our RC4a. If not, the fix already exists in updates-docker-nightly-neon. If we decide to, we can cut a 2.0.1 docker release but only after Neon is officially released. JBoss and other users can at any time use the 2.0.0 RC4a repo which contains the fix if they don't want to update from the nightly site. -- Jeff J. ----- Original Message ----- > Jeff, > > To clarify: since Linux Tools 5.0.0.RC4/Docker tooling 2.0.0.RC4 were already > released, are these fixes going to be included in Docker tooling 2.0.0.Final > or do we need to make a 2.0.1 release ? > > Best regards, > Xavier > > > On 10 Jun 2016, at 21:50, Jeff Johnston wrote: > > > > The gerrit changes are the following: > > > > https://git.eclipse.org/r/#/c/75077/ > > https://git.eclipse.org/r/#/c/75088/ > > > > The first change is the one for Docker Containers View. The second > > contains > > a fix for Docker Explorer View and some actions. > > > > I understand your argument below. As mentioned, no user has seen it yet. > > You have the fix ready if someone reports it and it will be in the next > > sprint. > > > > -- Jeff J. > > > > ----- Original Message ----- > >> My main concern is that we don't have time to fix anything if there is > >> something broken in that new docker. So IMO this issues is not critical > >> enough to introduce even bigger risk for this release. > >> This is a bad issue but not a blocker in the current circumstances. > >> > >> Jeff, where we can see the code difference for the docker tooling? Do > >> you have a gerrit change, a PR or something? > >> > >> On 06/10/2016 03:08 PM, Nick Boldt wrote: > >>> Please clarify: is this a blocker for devstudio 10.0.0.GA > >>> ? Or something to pick up in a later sprint / release? > >>> > >>> Given we've slipped respin-a to Monday, and still have to rebrand > >>> everything, we probably have time to contain a small TP change like > >>> this. IFF it's a blocker. > >>> > >>> On Fri, Jun 10, 2016 at 2:35 PM, Jeff Johnston >>> > wrote: > >>> > >>> I have just made a build available with the patch in: > >>> > >>> http:/download.eclipse.org/linuxtools/update-neon-docker-rc4a > >>> > >>> > >>> -- Jeff J. > >>> > >>> ----- Original Message ----- > >>>> Moving to jbosstools-dev. > >>>> > >>>> OK. This memory leak seems to be bad. Please continue to work on > >>> proper > >>>> bug fix and update for the Linux/Docker Tools for Neon but I'm > >>> afraid we > >>>> don't have time to change anything in our Target Platform for > >>> devstudio > >>>> 10 GA / JBoss Tools 4.4.0.Final at this point. > >>>> > >>>> Thanks. > >>>> > >>>> On 06/10/2016 12:56 PM, Jeff Johnston wrote: > >>>>> Should be Neon only as status icons were added for Neon M1 > >>> milestone. > >>>>> There > >>>>> may be other image leaks in Mars, but they are minor and no > >>> errors have > >>>>> shown > >>>>> in our testing or customer usage. > >>>>> > >>>>> -- Jeff J. > >>>>> > >>>>> ----- Original Message ----- > >>>>>> Is this bug in Neon branch only? What about Mars releases? > >>>>>> > >>>>>> > >>>>>> On 06/10/2016 12:38 PM, Jeff Johnston wrote: > >>>>>>> It appears that the issue I found has been around since Aug > >>> 2015 (Neon > >>>>>>> M1). > >>>>>>> I have a fix > >>>>>>> and there appears to be another possible leak in the > >>> DockerExplorerView > >>>>>>> which I > >>>>>>> am pushing a fix for currently. > >>>>>>> > >>>>>>> I noticed the memory leak the other day and during my > >>> testing I saw that > >>>>>>> images > >>>>>>> were being left behind to the point that the Eclipse MAT > >>> tool took notice > >>>>>>> over a > >>>>>>> short period and flagged it as a suspected memory leak. Docker > >>>>>>> Containers > >>>>>>> get refreshed every 15 seconds so Views > >>>>>>> that show them (Docker Containers View and Docker Explorer > >>> View) that use > >>>>>>> icons need > >>>>>>> to dispose of them properly. For the Docker Containers > >>> View, all > >>>>>>> containers were being > >>>>>>> given a new image each refresh period. The Explorer View > >>> isn't much of a > >>>>>>> problem because > >>>>>>> it is node-based and doesn't always show the full list of > >>> Containers. A > >>>>>>> short list of Containers > >>>>>>> will slow down the leak as will closing the View. > >>>>>>> > >>>>>>> My intention was to do a quick rebuild of the stable-5.0 > >>> branch and save > >>>>>>> it > >>>>>>> as RC4a repo. If desired, > >>>>>>> I can do a point release, but this requires more changes to > >>> all features > >>>>>>> and pom files to renumber > >>>>>>> them. Let me know if a point release is required. > >>>>>>> > >>>>>>> I will continue with the task of building an RC4a repo that > >>> will be saved > >>>>>>> in the Linux Tools download > >>>>>>> area. Neon users will have to use the updates-nightly-neon > >>> repo which > >>>>>>> will > >>>>>>> have > >>>>>>> the fix (same git branch is used to create the RC4a repo). > >>>>>>> > >>>>>>> -- Jeff J. > >>>>>>> > >>>>>>> ----- Original Message ----- > >>>>>>>> When did it happen? How long do you have it in Docker Tools. > >>>>>>>> > >>>>>>>> Have you already fixed it? Released the updated 2.0.1? > >>>>>>>> > >>>>>>>> On 06/10/2016 11:19 AM, Jeff Johnston wrote: > >>>>>>>>> This issue was introduced with a change to adding status > >>> icons in the > >>>>>>>>> Containers View. It wasn't noticed because it requires a > >>> long time to > >>>>>>>>> show (small image icons not being disposed of). > >>>>>>>>> > >>>>>>>>> -- Jeff J. > >>>>>>>>> > >>>>>>>>> ----- Original Message ----- > >>>>>>>>>> We will conceder to include any updated in respin-b > >>> besides branding > >>>>>>>>>> only if we have to fix some very bad issues. Real blocker. > >>>>>>>>>> Is this issue is old or some new regression? > >>>>>>>>>> > >>>>>>>>>> On 06/10/2016 10:57 AM, Xavier Coulon wrote: > >>>>>>>>>>> From my understanding, Jeff noticed the issue after > >>> letting > >>>>>>>>>>> Eclipse > >>>>>>>>>>> run > >>>>>>>>>>> all night long, but I don't remember if Eclipse was > >>> then unusable > >>>>>>>>>>> or > >>>>>>>>>>> crashed. > >>>>>>>>>>> Anyway, it could be serious enough it users have the > >>> Docker tooling > >>>>>>>>>>> views > >>>>>>>>>>> open in their workspace. > >>>>>>>>>>> > >>>>>>>>>>> Best regards, > >>>>>>>>>>> Xavier > >>>>>>>>>>>> On 10 Jun 2016, at 12:37, Alexey Kazakov > >>> > > >>>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> How bad is that leak? > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> On Jun 10, 2016, at 4:33 AM, Xavier Coulon > >>> > > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> Fred, Alexey, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Jeff J. found a memory leak in the Docker tooling. > >>> It's too late > >>>>>>>>>>>>> for > >>>>>>>>>>>>> Neon.0 RC4/Final, but he proposes that we cut a Linux > >>> Tools 5.0.1 / > >>>>>>>>>>>>> Docker Tooling 2.0.1 to address this specific issue. > >>>>>>>>>>>>> Is this something that can be included in the upcoming > >>> "respin-b" > >>>>>>>>>>>>> build > >>>>>>>>>>>>> along with the branding updates ? I understand that Alexey > >>>>>>>>>>>>> initially > >>>>>>>>>>>>> said that this ultimate build would not include any > >>> other bug fix, > >>>>>>>>>>>>> but > >>>>>>>>>>>>> nonetheless, I'm asking the question ;-) > >>>>>>>>>>>>> > >>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>> /Xavier > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi Xavier, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Jeff here. I found a memory leak in the Docker > >>> Containers View. > >>>>>>>>>>>>>> I > >>>>>>>>>>>>>> believe it is fixed with my gerrit patch. If JBoss > >>> wants, I can > >>>>>>>>>>>>>> create > >>>>>>>>>>>>>> a > >>>>>>>>>>>>>> special repo for them to use to remove this bug. The > >>> fix is too > >>>>>>>>>>>>>> late > >>>>>>>>>>>>>> for > >>>>>>>>>>>>>> Neon, but we can cut a point release if necessary or > >>> wait until > >>>>>>>>>>>>>> 5.1 > >>>>>>>>>>>>>> and > >>>>>>>>>>>>>> fix it in the updates-nightly-neon. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The problem was with the images used for status in > >>> the Table. > >>>>>>>>>>>>>> They > >>>>>>>>>>>>>> were > >>>>>>>>>>>>>> constantly being created via createImage() but never > >>> stored any > >>>>>>>>>>>>>> where > >>>>>>>>>>>>>> and > >>>>>>>>>>>>>> never disposed. I simply created 3 images for status > >>> and return > >>>>>>>>>>>>>> one > >>>>>>>>>>>>>> of > >>>>>>>>>>>>>> 3 > >>>>>>>>>>>>>> for each table entry, then dispose of them in the > >>> Containers View > >>>>>>>>>>>>>> dispose > >>>>>>>>>>>>>> method. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -- Jeff J. > >>>>>> > >>>> > >>>> > >>> _______________________________________________ > >>> jbosstools-dev mailing list > >>> jbosstools-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > >>> > >>> > >>> > >>> > >>> -- > >>> Nick Boldt :: JBoss by Red Hat > >>> Productization Lead :: JBoss Tools & Dev Studio > >>> http://nick.divbyzero.com > >> > >> > > _______________________________________________ > > jbosstools-dev mailing list > > jbosstools-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > From nickboldt at gmail.com Mon Jun 13 13:03:53 2016 From: nickboldt at gmail.com (Nick Boldt) Date: Mon, 13 Jun 2016 13:03:53 -0400 Subject: [jbosstools-dev] Eclipse Neon.0.RC4b respin today Message-ID: Eclipse Neon.0.RC4 will be respun today. This only affects Integration Stack (new BPMN2 modeler) afaiu. We could chose to change our target platform today as well to pick up the Docker Tooling fix, if we want. @alexey, please advise. ---------- Forwarded message ---------- From: David M Williams Date: Mon, Jun 13, 2016 at 12:07 PM Subject: [cross-project-issues-dev] Respin of SimRel Repository required To: cross-project-issues-dev at eclipse.org Extended team, I am beginning a re-spin of the Sim. Release repository. Two major changes: SOA-BPN2 modeler removed and Window Builder removed. The former removed because they didn't finish the normal release requirements. The later was removed because it has not been tested with the Neon candidate release. (It did recently, after RC4, get a build which "removed one line of code" which prevented it from running on Neon ... but, our goal is not for projects to "join at the last minute" but to be part of the train for many milestones so it can be adequately tested). It is my understanding both projects plan to "rejoin the train" in the September release. A minor change: Linux Tools found a major memory leak which would normally not be "respin worthy", but I told them if we had to respin for other reasons they could include a fix for that. The EPP packages will need to be rebuilt of course -- first because they always are if the repository changes, but more so this time because Window Builder was included in two EPP packages and of course will have to be removed from those packages. I will update this list once both steps are complete. Thanks, _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev at 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 -- Nick Boldt :: Productization Lead :: JBoss Tools & Dev Studio :: Red Hat, Inc. http://nick.divbyzero.com From alkazako at redhat.com Mon Jun 13 13:58:51 2016 From: alkazako at redhat.com (Alexey Kazakov) Date: Mon, 13 Jun 2016 13:58:51 -0400 Subject: [jbosstools-dev] Eclipse Neon.0.RC4b respin today In-Reply-To: References: Message-ID: <575EF45B.6030200@redhat.com> No, we are not planning to change our target platform for JBoss Tools 4.4.0.Final / devstudio 10.0.0.GA after this respin-a. Thanks. On 06/13/2016 01:03 PM, Nick Boldt wrote: > Eclipse Neon.0.RC4 will be respun today. > > This only affects Integration Stack (new BPMN2 modeler) afaiu. > > We could chose to change our target platform today as well to pick up > the Docker Tooling fix, if we want. > > @alexey, please advise. > > > ---------- Forwarded message ---------- > From: David M Williams > Date: Mon, Jun 13, 2016 at 12:07 PM > Subject: [cross-project-issues-dev] Respin of SimRel Repository required > To: cross-project-issues-dev at eclipse.org > > > Extended team, > > I am beginning a re-spin of the Sim. Release repository. > > Two major changes: SOA-BPN2 modeler removed and Window Builder removed. > > The former removed because they didn't finish the normal release > requirements. The later was removed because it has not been tested > with the Neon candidate release. (It did recently, after RC4, get a > build which "removed one line of code" which prevented it from running > on Neon ... but, our goal is not for projects to "join at the last > minute" but to be part of the train for many milestones so it can be > adequately tested). > > It is my understanding both projects plan to "rejoin the train" in the > September release. > > A minor change: Linux Tools found a major memory leak which would > normally not be "respin worthy", but I told them if we had to respin > for other reasons they could include a fix for that. > > The EPP packages will need to be rebuilt of course -- first because > they always are if the repository changes, but more so this time > because Window Builder was included in two EPP packages and of course > will have to be removed from those packages. > > I will update this list once both steps are complete. > > Thanks, > > > > > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev at 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 > > From psrna at redhat.com Mon Jun 13 14:11:55 2016 From: psrna at redhat.com (Pavol Srna) Date: Mon, 13 Jun 2016 20:11:55 +0200 Subject: [jbosstools-dev] Eclipse Neon.0.RC4b respin today In-Reply-To: <575EF45B.6030200@redhat.com> References: <575EF45B.6030200@redhat.com> Message-ID: Hi All, we are changing the TP for JBT respin-a build anyway. Why don't we build respin-a on the latest neon RC4 if possible? -Pavol. On Mon, Jun 13, 2016 at 7:58 PM, Alexey Kazakov wrote: > No, we are not planning to change our target platform for JBoss Tools > 4.4.0.Final / devstudio 10.0.0.GA after this respin-a. > > Thanks. > > On 06/13/2016 01:03 PM, Nick Boldt wrote: > > Eclipse Neon.0.RC4 will be respun today. > > > > This only affects Integration Stack (new BPMN2 modeler) afaiu. > > > > We could chose to change our target platform today as well to pick up > > the Docker Tooling fix, if we want. > > > > @alexey, please advise. > > > > > > ---------- Forwarded message ---------- > > From: David M Williams > > Date: Mon, Jun 13, 2016 at 12:07 PM > > Subject: [cross-project-issues-dev] Respin of SimRel Repository required > > To: cross-project-issues-dev at eclipse.org > > > > > > Extended team, > > > > I am beginning a re-spin of the Sim. Release repository. > > > > Two major changes: SOA-BPN2 modeler removed and Window Builder removed. > > > > The former removed because they didn't finish the normal release > > requirements. The later was removed because it has not been tested > > with the Neon candidate release. (It did recently, after RC4, get a > > build which "removed one line of code" which prevented it from running > > on Neon ... but, our goal is not for projects to "join at the last > > minute" but to be part of the train for many milestones so it can be > > adequately tested). > > > > It is my understanding both projects plan to "rejoin the train" in the > > September release. > > > > A minor change: Linux Tools found a major memory leak which would > > normally not be "respin worthy", but I told them if we had to respin > > for other reasons they could include a fix for that. > > > > The EPP packages will need to be rebuilt of course -- first because > > they always are if the repository changes, but more so this time > > because Window Builder was included in two EPP packages and of course > > will have to be removed from those packages. > > > > I will update this list once both steps are complete. > > > > Thanks, > > > > > > > > > > _______________________________________________ > > cross-project-issues-dev mailing list > > cross-project-issues-dev at 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 > > > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160613/b0a4e0e5/attachment.html From alkazako at redhat.com Mon Jun 13 14:20:42 2016 From: alkazako at redhat.com (Alexey Kazakov) Date: Mon, 13 Jun 2016 14:20:42 -0400 Subject: [jbosstools-dev] Eclipse Neon.0.RC4b respin today In-Reply-To: References: <575EF45B.6030200@redhat.com> Message-ID: <575EF97A.5040300@redhat.com> We do build respin-a on the latest RC4. The Docker tooling fix Nick is talking about is not a part of RC4. On 06/13/2016 02:11 PM, Pavol Srna wrote: > Hi All, > > we are changing the TP for JBT respin-a build anyway. > Why don't we build respin-a on the latest neon RC4 if possible? > > -Pavol. > > On Mon, Jun 13, 2016 at 7:58 PM, Alexey Kazakov > wrote: > > No, we are not planning to change our target platform for JBoss Tools > 4.4.0.Final / devstudio 10.0.0.GA after this > respin-a. > > Thanks. > > On 06/13/2016 01:03 PM, Nick Boldt wrote: > > Eclipse Neon.0.RC4 will be respun today. > > > > This only affects Integration Stack (new BPMN2 modeler) afaiu. > > > > We could chose to change our target platform today as well to > pick up > > the Docker Tooling fix, if we want. > > > > @alexey, please advise. > > > > > > ---------- Forwarded message ---------- > > From: David M Williams > > > Date: Mon, Jun 13, 2016 at 12:07 PM > > Subject: [cross-project-issues-dev] Respin of SimRel Repository > required > > To: cross-project-issues-dev at eclipse.org > > > > > > > Extended team, > > > > I am beginning a re-spin of the Sim. Release repository. > > > > Two major changes: SOA-BPN2 modeler removed and Window Builder > removed. > > > > The former removed because they didn't finish the normal release > > requirements. The later was removed because it has not been tested > > with the Neon candidate release. (It did recently, after RC4, get a > > build which "removed one line of code" which prevented it from > running > > on Neon ... but, our goal is not for projects to "join at the last > > minute" but to be part of the train for many milestones so it can be > > adequately tested). > > > > It is my understanding both projects plan to "rejoin the train" > in the > > September release. > > > > A minor change: Linux Tools found a major memory leak which would > > normally not be "respin worthy", but I told them if we had to respin > > for other reasons they could include a fix for that. > > > > The EPP packages will need to be rebuilt of course -- first because > > they always are if the repository changes, but more so this time > > because Window Builder was included in two EPP packages and of > course > > will have to be removed from those packages. > > > > I will update this list once both steps are complete. > > > > Thanks, > > > > > > > > > > _______________________________________________ > > cross-project-issues-dev mailing list > > cross-project-issues-dev at 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 > > > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160613/5c53c91d/attachment-0001.html From ldimaggi at redhat.com Mon Jun 13 14:24:43 2016 From: ldimaggi at redhat.com (Leonard Dimaggio) Date: Mon, 13 Jun 2016 14:24:43 -0400 Subject: [jbosstools-dev] Eclipse Neon.0.RC4b respin today In-Reply-To: References: <575EF45B.6030200@redhat.com> Message-ID: Where - in which JIRAs - are we altering the TP in respin-a? https://issues.jboss.org/issues/?filter=12327576 Thanks!, Len On Mon, Jun 13, 2016 at 2:11 PM, Pavol Srna wrote: > Hi All, > > we are changing the TP for JBT respin-a build anyway. > Why don't we build respin-a on the latest neon RC4 if possible? > > -Pavol. > > On Mon, Jun 13, 2016 at 7:58 PM, Alexey Kazakov > wrote: > >> No, we are not planning to change our target platform for JBoss Tools >> 4.4.0.Final / devstudio 10.0.0.GA after this respin-a. >> >> Thanks. >> >> On 06/13/2016 01:03 PM, Nick Boldt wrote: >> > Eclipse Neon.0.RC4 will be respun today. >> > >> > This only affects Integration Stack (new BPMN2 modeler) afaiu. >> > >> > We could chose to change our target platform today as well to pick up >> > the Docker Tooling fix, if we want. >> > >> > @alexey, please advise. >> > >> > >> > ---------- Forwarded message ---------- >> > From: David M Williams >> > Date: Mon, Jun 13, 2016 at 12:07 PM >> > Subject: [cross-project-issues-dev] Respin of SimRel Repository required >> > To: cross-project-issues-dev at eclipse.org >> > >> > >> > Extended team, >> > >> > I am beginning a re-spin of the Sim. Release repository. >> > >> > Two major changes: SOA-BPN2 modeler removed and Window Builder removed. >> > >> > The former removed because they didn't finish the normal release >> > requirements. The later was removed because it has not been tested >> > with the Neon candidate release. (It did recently, after RC4, get a >> > build which "removed one line of code" which prevented it from running >> > on Neon ... but, our goal is not for projects to "join at the last >> > minute" but to be part of the train for many milestones so it can be >> > adequately tested). >> > >> > It is my understanding both projects plan to "rejoin the train" in the >> > September release. >> > >> > A minor change: Linux Tools found a major memory leak which would >> > normally not be "respin worthy", but I told them if we had to respin >> > for other reasons they could include a fix for that. >> > >> > The EPP packages will need to be rebuilt of course -- first because >> > they always are if the repository changes, but more so this time >> > because Window Builder was included in two EPP packages and of course >> > will have to be removed from those packages. >> > >> > I will update this list once both steps are complete. >> > >> > Thanks, >> > >> > >> > >> > >> > _______________________________________________ >> > cross-project-issues-dev mailing list >> > cross-project-issues-dev at 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 >> > >> > >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > -- Len DiMaggio (ldimaggi at redhat.com) JBoss by Red Hat 314 Littleton Road Westford, MA 01886 USA tel: 978.392.3179 cell: 781.472.9912 http://www.redhat.com http://community.jboss.org/people/ldimaggio -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160613/57ed8f95/attachment.html From psrna at redhat.com Mon Jun 13 14:32:22 2016 From: psrna at redhat.com (Pavol Srna) Date: Mon, 13 Jun 2016 20:32:22 +0200 Subject: [jbosstools-dev] Eclipse Neon.0.RC4b respin today In-Reply-To: References: <575EF45B.6030200@redhat.com> Message-ID: Hi Len, I don't have the specific jira, but it was the plan on last PM meeting. 4.4.0.Final is RC2, 4.4.0.Final respin-a is RC4. -Pavol On Mon, Jun 13, 2016 at 8:24 PM, Leonard Dimaggio wrote: > Where - in which JIRAs - are we altering the TP in respin-a? > > https://issues.jboss.org/issues/?filter=12327576 > > Thanks!, > Len > > > On Mon, Jun 13, 2016 at 2:11 PM, Pavol Srna wrote: > >> Hi All, >> >> we are changing the TP for JBT respin-a build anyway. >> Why don't we build respin-a on the latest neon RC4 if possible? >> >> -Pavol. >> >> On Mon, Jun 13, 2016 at 7:58 PM, Alexey Kazakov >> wrote: >> >>> No, we are not planning to change our target platform for JBoss Tools >>> 4.4.0.Final / devstudio 10.0.0.GA after this respin-a. >>> >>> Thanks. >>> >>> On 06/13/2016 01:03 PM, Nick Boldt wrote: >>> > Eclipse Neon.0.RC4 will be respun today. >>> > >>> > This only affects Integration Stack (new BPMN2 modeler) afaiu. >>> > >>> > We could chose to change our target platform today as well to pick up >>> > the Docker Tooling fix, if we want. >>> > >>> > @alexey, please advise. >>> > >>> > >>> > ---------- Forwarded message ---------- >>> > From: David M Williams >>> > Date: Mon, Jun 13, 2016 at 12:07 PM >>> > Subject: [cross-project-issues-dev] Respin of SimRel Repository >>> required >>> > To: cross-project-issues-dev at eclipse.org >>> > >>> > >>> > Extended team, >>> > >>> > I am beginning a re-spin of the Sim. Release repository. >>> > >>> > Two major changes: SOA-BPN2 modeler removed and Window Builder removed. >>> > >>> > The former removed because they didn't finish the normal release >>> > requirements. The later was removed because it has not been tested >>> > with the Neon candidate release. (It did recently, after RC4, get a >>> > build which "removed one line of code" which prevented it from running >>> > on Neon ... but, our goal is not for projects to "join at the last >>> > minute" but to be part of the train for many milestones so it can be >>> > adequately tested). >>> > >>> > It is my understanding both projects plan to "rejoin the train" in the >>> > September release. >>> > >>> > A minor change: Linux Tools found a major memory leak which would >>> > normally not be "respin worthy", but I told them if we had to respin >>> > for other reasons they could include a fix for that. >>> > >>> > The EPP packages will need to be rebuilt of course -- first because >>> > they always are if the repository changes, but more so this time >>> > because Window Builder was included in two EPP packages and of course >>> > will have to be removed from those packages. >>> > >>> > I will update this list once both steps are complete. >>> > >>> > Thanks, >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > cross-project-issues-dev mailing list >>> > cross-project-issues-dev at 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 >>> > >>> > >>> >>> _______________________________________________ >>> jbosstools-dev mailing list >>> jbosstools-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>> >> >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> > > > > -- > Len DiMaggio (ldimaggi at redhat.com) > JBoss by Red Hat > 314 Littleton Road > Westford, MA 01886 USA > tel: 978.392.3179 > cell: 781.472.9912 > http://www.redhat.com > http://community.jboss.org/people/ldimaggio > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160613/f8272d46/attachment.html From psrna at redhat.com Mon Jun 13 14:33:23 2016 From: psrna at redhat.com (Pavol Srna) Date: Mon, 13 Jun 2016 20:33:23 +0200 Subject: [jbosstools-dev] Eclipse Neon.0.RC4b respin today In-Reply-To: <575EF97A.5040300@redhat.com> References: <575EF45B.6030200@redhat.com> <575EF97A.5040300@redhat.com> Message-ID: OK, thanks for clarification. On Mon, Jun 13, 2016 at 8:20 PM, Alexey Kazakov wrote: > We do build respin-a on the latest RC4. > > The Docker tooling fix Nick is talking about is not a part of RC4. > > > On 06/13/2016 02:11 PM, Pavol Srna wrote: > > Hi All, > > we are changing the TP for JBT respin-a build anyway. > Why don't we build respin-a on the latest neon RC4 if possible? > > -Pavol. > > On Mon, Jun 13, 2016 at 7:58 PM, Alexey Kazakov < > alkazako at redhat.com> wrote: > >> No, we are not planning to change our target platform for JBoss Tools >> 4.4.0.Final / devstudio 10.0.0.GA after this respin-a. >> >> Thanks. >> >> On 06/13/2016 01:03 PM, Nick Boldt wrote: >> > Eclipse Neon.0.RC4 will be respun today. >> > >> > This only affects Integration Stack (new BPMN2 modeler) afaiu. >> > >> > We could chose to change our target platform today as well to pick up >> > the Docker Tooling fix, if we want. >> > >> > @alexey, please advise. >> > >> > >> > ---------- Forwarded message ---------- >> > From: David M Williams < >> david_williams at us.ibm.com> >> > Date: Mon, Jun 13, 2016 at 12:07 PM >> > Subject: [cross-project-issues-dev] Respin of SimRel Repository required >> > To: cross-project-issues-dev at eclipse.org >> > >> > >> > Extended team, >> > >> > I am beginning a re-spin of the Sim. Release repository. >> > >> > Two major changes: SOA-BPN2 modeler removed and Window Builder removed. >> > >> > The former removed because they didn't finish the normal release >> > requirements. The later was removed because it has not been tested >> > with the Neon candidate release. (It did recently, after RC4, get a >> > build which "removed one line of code" which prevented it from running >> > on Neon ... but, our goal is not for projects to "join at the last >> > minute" but to be part of the train for many milestones so it can be >> > adequately tested). >> > >> > It is my understanding both projects plan to "rejoin the train" in the >> > September release. >> > >> > A minor change: Linux Tools found a major memory leak which would >> > normally not be "respin worthy", but I told them if we had to respin >> > for other reasons they could include a fix for that. >> > >> > The EPP packages will need to be rebuilt of course -- first because >> > they always are if the repository changes, but more so this time >> > because Window Builder was included in two EPP packages and of course >> > will have to be removed from those packages. >> > >> > I will update this list once both steps are complete. >> > >> > Thanks, >> > >> > >> > >> > >> > _______________________________________________ >> > cross-project-issues-dev mailing list >> > cross-project-issues-dev at 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 >> > >> > >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160613/c6d639d2/attachment-0001.html From nboldt at redhat.com Mon Jun 13 15:15:23 2016 From: nboldt at redhat.com (nboldt at redhat.com) Date: Mon, 13 Jun 2016 15:15:23 -0400 Subject: [jbosstools-dev] JBoss Tools Core 4.4.0.Final-a bits available for QE testing Message-ID: <201606131915.u5DJFNMV013506@dev01.mw.lab.eng.bos.redhat.com> These are not FINAL bits, but preliminary results for QE & community testing. Not for redistribution to customers or end users. Note that there is an issue installing the Integration Stack content -- currently, everything except Teiid Designer can be installed, prompting remediation. Update site: http://download.jboss.org/jbosstools/neon/staging/updates/ New + noteworthy (subject to change): * https://github.com/jbosstools/jbosstools-website/tree/master/documentation/whatsnew * http://tools.jboss.org/documentation/whatsnew/ Schedule: https://issues.jboss.org/projects/JBIDE?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page -- Additional update sites: * http://download.jboss.org/jbosstools/neon/staging/updates/core/4.4.0.Final-a/ * http://download.jboss.org/jbosstools/neon/staging/updates/coretests/4.4.0.Final-a/ Target platforms: * http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.60.0.Final-SNAPSHOT * http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.60.0.Final-SNAPSHOT Discovery sites: * http://download.jboss.org/jbosstools/neon/staging/updates/discovery.central/4.4.0.Final-a/ * http://download.jboss.org/jbosstools/neon/staging/updates/discovery.earlyaccess/4.4.0.Final-a/ Build folders (for build logs & update site zips): * http://download.jboss.org/jbosstools/neon/staging/builds/ -- Changes prompting this respin-a are: https://issues.jboss.org/issues/?jql=labels%20in%20%28%22respin-a%22%29%20and%20%28%28project%20in%20%28%22JBDS%22%29%20and%20fixversion%20in%20%28%2210.0.0.GA%22%29%29%20or%20%28project%20in%20%28%22JBIDE%22%2C%22TOOLSDOC%22%29%20and%20fixversion%20in%20%28%224.4.0.Final%22%29%29%29 To compare the upcoming version of Central (4.4.0.Final-a) against an older version, add lines similar to these your eclipse.ini file after the -vmargs line for the appropriate version & URLs: -Djboss.discovery.directory.url=http://download.jboss.org/jbosstools/neon/staging/updates/discovery.central/4.4.0.Final-a/jbosstools-directory.xml -Djboss.discovery.site.url=http://download.jboss.org/jbosstools/neon/staging/updates/ -Djboss.discovery.earlyaccess.site.url=http://download.jboss.org/jbosstools/neon/staging/updates/discovery.earlyaccess/4.4.0.Final-a/ -Djboss.discovery.earlyaccess.list.url=http://download.jboss.org/jbosstools/neon/staging/updates/discovery.earlyaccess/4.4.0.Final-a/jbosstools-earlyaccess.properties From alkazako at redhat.com Mon Jun 13 17:42:48 2016 From: alkazako at redhat.com (Alexey Kazakov) Date: Mon, 13 Jun 2016 17:42:48 -0400 Subject: [jbosstools-dev] Eclipse Neon.0.RC4b respin today In-Reply-To: <575EF97A.5040300@redhat.com> References: <575EF45B.6030200@redhat.com> <575EF97A.5040300@redhat.com> Message-ID: <575F28D8.4020305@redhat.com> It turned out that Eclipse is going to include the fixed Docker tools in their Neon RC4 respin-b. After discussion with Nick and Len we decided to include to update our TP as well. So, devstudio 10.0.0.GA respin-b we are building for that branding stuff will include the updated Neon RC4-b (the only difference for us is the updated Docker Tools with that memory leak fix). Thanks. On 06/13/2016 02:20 PM, Alexey Kazakov wrote: > We do build respin-a on the latest RC4. > > The Docker tooling fix Nick is talking about is not a part of RC4. > > On 06/13/2016 02:11 PM, Pavol Srna wrote: >> Hi All, >> >> we are changing the TP for JBT respin-a build anyway. >> Why don't we build respin-a on the latest neon RC4 if possible? >> >> -Pavol. >> >> On Mon, Jun 13, 2016 at 7:58 PM, Alexey Kazakov >> wrote: >> >> No, we are not planning to change our target platform for JBoss Tools >> 4.4.0.Final / devstudio 10.0.0.GA after this >> respin-a. >> >> Thanks. >> >> On 06/13/2016 01:03 PM, Nick Boldt wrote: >> > Eclipse Neon.0.RC4 will be respun today. >> > >> > This only affects Integration Stack (new BPMN2 modeler) afaiu. >> > >> > We could chose to change our target platform today as well to >> pick up >> > the Docker Tooling fix, if we want. >> > >> > @alexey, please advise. >> > >> > >> > ---------- Forwarded message ---------- >> > From: David M Williams >> > Date: Mon, Jun 13, 2016 at 12:07 PM >> > Subject: [cross-project-issues-dev] Respin of SimRel Repository >> required >> > To: cross-project-issues-dev at eclipse.org >> >> > >> > >> > Extended team, >> > >> > I am beginning a re-spin of the Sim. Release repository. >> > >> > Two major changes: SOA-BPN2 modeler removed and Window Builder >> removed. >> > >> > The former removed because they didn't finish the normal release >> > requirements. The later was removed because it has not been tested >> > with the Neon candidate release. (It did recently, after RC4, get a >> > build which "removed one line of code" which prevented it from >> running >> > on Neon ... but, our goal is not for projects to "join at the last >> > minute" but to be part of the train for many milestones so it >> can be >> > adequately tested). >> > >> > It is my understanding both projects plan to "rejoin the train" >> in the >> > September release. >> > >> > A minor change: Linux Tools found a major memory leak which would >> > normally not be "respin worthy", but I told them if we had to >> respin >> > for other reasons they could include a fix for that. >> > >> > The EPP packages will need to be rebuilt of course -- first because >> > they always are if the repository changes, but more so this time >> > because Window Builder was included in two EPP packages and of >> course >> > will have to be removed from those packages. >> > >> > I will update this list once both steps are complete. >> > >> > Thanks, >> > >> > >> > >> > >> > _______________________________________________ >> > cross-project-issues-dev mailing list >> > cross-project-issues-dev at 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 >> > >> > >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> >> > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160613/49df8214/attachment.html From nboldt at redhat.com Mon Jun 13 18:00:55 2016 From: nboldt at redhat.com (Nick Boldt) Date: Mon, 13 Jun 2016 18:00:55 -0400 Subject: [jbosstools-dev] Eclipse Neon.0.RC4b respin today In-Reply-To: <575F28D8.4020305@redhat.com> References: <575EF45B.6030200@redhat.com> <575EF97A.5040300@redhat.com> <575F28D8.4020305@redhat.com> Message-ID: Target Platform 4.60.0.Final (not SNAPSHOT) is now building [1] and I'll publish it to nexus tonight then update the parent pom and job configs to use the non-SNAPSHOT version. [1] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevStudio_Master/job/jbosstoolstargetplatforms-matrix/ >=558 We fast-tracked this change (rather than announcing it & waiting for review) due to the obviously compressed timeline and need to have it done TONIGHT. On Mon, Jun 13, 2016 at 5:42 PM, Alexey Kazakov wrote: > It turned out that Eclipse is going to include the fixed Docker tools in > their Neon RC4 respin-b. > After discussion with Nick and Len we decided to include to update our TP as > well. > > So, devstudio 10.0.0.GA respin-b we are building for that branding stuff > will include the updated Neon RC4-b (the only difference for us is the > updated Docker Tools with that memory leak fix). > > Thanks. > > > On 06/13/2016 02:20 PM, Alexey Kazakov wrote: > > We do build respin-a on the latest RC4. > > The Docker tooling fix Nick is talking about is not a part of RC4. > > On 06/13/2016 02:11 PM, Pavol Srna wrote: > > Hi All, > > we are changing the TP for JBT respin-a build anyway. > Why don't we build respin-a on the latest neon RC4 if possible? > > -Pavol. > > On Mon, Jun 13, 2016 at 7:58 PM, Alexey Kazakov wrote: >> >> No, we are not planning to change our target platform for JBoss Tools >> 4.4.0.Final / devstudio 10.0.0.GA after this respin-a. >> >> Thanks. >> >> On 06/13/2016 01:03 PM, Nick Boldt wrote: >> > Eclipse Neon.0.RC4 will be respun today. >> > >> > This only affects Integration Stack (new BPMN2 modeler) afaiu. >> > >> > We could chose to change our target platform today as well to pick up >> > the Docker Tooling fix, if we want. >> > >> > @alexey, please advise. >> > >> > >> > ---------- Forwarded message ---------- >> > From: David M Williams >> > Date: Mon, Jun 13, 2016 at 12:07 PM >> > Subject: [cross-project-issues-dev] Respin of SimRel Repository required >> > To: cross-project-issues-dev at eclipse.org >> > >> > >> > Extended team, >> > >> > I am beginning a re-spin of the Sim. Release repository. >> > >> > Two major changes: SOA-BPN2 modeler removed and Window Builder removed. >> > >> > The former removed because they didn't finish the normal release >> > requirements. The later was removed because it has not been tested >> > with the Neon candidate release. (It did recently, after RC4, get a >> > build which "removed one line of code" which prevented it from running >> > on Neon ... but, our goal is not for projects to "join at the last >> > minute" but to be part of the train for many milestones so it can be >> > adequately tested). >> > >> > It is my understanding both projects plan to "rejoin the train" in the >> > September release. >> > >> > A minor change: Linux Tools found a major memory leak which would >> > normally not be "respin worthy", but I told them if we had to respin >> > for other reasons they could include a fix for that. >> > >> > The EPP packages will need to be rebuilt of course -- first because >> > they always are if the repository changes, but more so this time >> > because Window Builder was included in two EPP packages and of course >> > will have to be removed from those packages. >> > >> > I will update this list once both steps are complete. >> > >> > Thanks, >> > >> > >> > >> > >> > _______________________________________________ >> > cross-project-issues-dev mailing list >> > cross-project-issues-dev at 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 >> > >> > >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com From nboldt at redhat.com Mon Jun 13 18:03:45 2016 From: nboldt at redhat.com (Nick Boldt) Date: Mon, 13 Jun 2016 18:03:45 -0400 Subject: [jbosstools-dev] Memory Leak in Docker Containers View In-Reply-To: <1522580708.22058243.1465833655982.JavaMail.zimbra@redhat.com> References: <1592696271.21662157.1465577781515.JavaMail.zimbra@redhat.com> <575AFC94.5010405@redhat.com> <939602854.21686748.1465583740694.JavaMail.zimbra@redhat.com> <575B1874.70906@redhat.com> <1652038439.21701104.1465588216991.JavaMail.zimbra@redhat.com> <38067D5A-963E-4AB0-A755-EFAFB6EE77C6@redhat.com> <1522580708.22058243.1465833655982.JavaMail.zimbra@redhat.com> Message-ID: ICYMI, this is now being included in both Neon.0.RC4b and the 4.60.0.Final target platform to be used with JBT 4.4.0.Final and devstudio 10.0.0.GA. On Mon, Jun 13, 2016 at 12:00 PM, Jeff Johnston wrote: > Normally, RC4 becomes the final release. Eclipse does not like rebulding unless it is > critical. The bug in question is not critical because it doesn't show itself for a long > time of usage. That said, I have been given permission to update if Neon rebuilds for another > critical issue. I have created a 5.0.0 RC4a and Docker 2.0.0 RC4a repo with fix and > updated the aggregation specs. If Neon rebuilds for any reason, it will get > our RC4a. If not, the fix already exists in updates-docker-nightly-neon. If we decide to, > we can cut a 2.0.1 docker release but only after Neon is officially released. > > JBoss and other users can at any time use the 2.0.0 RC4a repo which contains the fix if they > don't want to update from the nightly site. > > -- Jeff J. > > ----- Original Message ----- >> Jeff, >> >> To clarify: since Linux Tools 5.0.0.RC4/Docker tooling 2.0.0.RC4 were already >> released, are these fixes going to be included in Docker tooling 2.0.0.Final >> or do we need to make a 2.0.1 release ? >> >> Best regards, >> Xavier >> >> > On 10 Jun 2016, at 21:50, Jeff Johnston wrote: >> > >> > The gerrit changes are the following: >> > >> > https://git.eclipse.org/r/#/c/75077/ >> > https://git.eclipse.org/r/#/c/75088/ >> > >> > The first change is the one for Docker Containers View. The second >> > contains >> > a fix for Docker Explorer View and some actions. >> > >> > I understand your argument below. As mentioned, no user has seen it yet. >> > You have the fix ready if someone reports it and it will be in the next >> > sprint. >> > >> > -- Jeff J. >> > >> > ----- Original Message ----- >> >> My main concern is that we don't have time to fix anything if there is >> >> something broken in that new docker. So IMO this issues is not critical >> >> enough to introduce even bigger risk for this release. >> >> This is a bad issue but not a blocker in the current circumstances. >> >> >> >> Jeff, where we can see the code difference for the docker tooling? Do >> >> you have a gerrit change, a PR or something? >> >> >> >> On 06/10/2016 03:08 PM, Nick Boldt wrote: >> >>> Please clarify: is this a blocker for devstudio 10.0.0.GA >> >>> ? Or something to pick up in a later sprint / release? >> >>> >> >>> Given we've slipped respin-a to Monday, and still have to rebrand >> >>> everything, we probably have time to contain a small TP change like >> >>> this. IFF it's a blocker. >> >>> >> >>> On Fri, Jun 10, 2016 at 2:35 PM, Jeff Johnston > >>> > wrote: >> >>> >> >>> I have just made a build available with the patch in: >> >>> >> >>> http:/download.eclipse.org/linuxtools/update-neon-docker-rc4a >> >>> >> >>> >> >>> -- Jeff J. >> >>> >> >>> ----- Original Message ----- >> >>>> Moving to jbosstools-dev. >> >>>> >> >>>> OK. This memory leak seems to be bad. Please continue to work on >> >>> proper >> >>>> bug fix and update for the Linux/Docker Tools for Neon but I'm >> >>> afraid we >> >>>> don't have time to change anything in our Target Platform for >> >>> devstudio >> >>>> 10 GA / JBoss Tools 4.4.0.Final at this point. >> >>>> >> >>>> Thanks. >> >>>> >> >>>> On 06/10/2016 12:56 PM, Jeff Johnston wrote: >> >>>>> Should be Neon only as status icons were added for Neon M1 >> >>> milestone. >> >>>>> There >> >>>>> may be other image leaks in Mars, but they are minor and no >> >>> errors have >> >>>>> shown >> >>>>> in our testing or customer usage. >> >>>>> >> >>>>> -- Jeff J. >> >>>>> >> >>>>> ----- Original Message ----- >> >>>>>> Is this bug in Neon branch only? What about Mars releases? >> >>>>>> >> >>>>>> >> >>>>>> On 06/10/2016 12:38 PM, Jeff Johnston wrote: >> >>>>>>> It appears that the issue I found has been around since Aug >> >>> 2015 (Neon >> >>>>>>> M1). >> >>>>>>> I have a fix >> >>>>>>> and there appears to be another possible leak in the >> >>> DockerExplorerView >> >>>>>>> which I >> >>>>>>> am pushing a fix for currently. >> >>>>>>> >> >>>>>>> I noticed the memory leak the other day and during my >> >>> testing I saw that >> >>>>>>> images >> >>>>>>> were being left behind to the point that the Eclipse MAT >> >>> tool took notice >> >>>>>>> over a >> >>>>>>> short period and flagged it as a suspected memory leak. Docker >> >>>>>>> Containers >> >>>>>>> get refreshed every 15 seconds so Views >> >>>>>>> that show them (Docker Containers View and Docker Explorer >> >>> View) that use >> >>>>>>> icons need >> >>>>>>> to dispose of them properly. For the Docker Containers >> >>> View, all >> >>>>>>> containers were being >> >>>>>>> given a new image each refresh period. The Explorer View >> >>> isn't much of a >> >>>>>>> problem because >> >>>>>>> it is node-based and doesn't always show the full list of >> >>> Containers. A >> >>>>>>> short list of Containers >> >>>>>>> will slow down the leak as will closing the View. >> >>>>>>> >> >>>>>>> My intention was to do a quick rebuild of the stable-5.0 >> >>> branch and save >> >>>>>>> it >> >>>>>>> as RC4a repo. If desired, >> >>>>>>> I can do a point release, but this requires more changes to >> >>> all features >> >>>>>>> and pom files to renumber >> >>>>>>> them. Let me know if a point release is required. >> >>>>>>> >> >>>>>>> I will continue with the task of building an RC4a repo that >> >>> will be saved >> >>>>>>> in the Linux Tools download >> >>>>>>> area. Neon users will have to use the updates-nightly-neon >> >>> repo which >> >>>>>>> will >> >>>>>>> have >> >>>>>>> the fix (same git branch is used to create the RC4a repo). >> >>>>>>> >> >>>>>>> -- Jeff J. >> >>>>>>> >> >>>>>>> ----- Original Message ----- >> >>>>>>>> When did it happen? How long do you have it in Docker Tools. >> >>>>>>>> >> >>>>>>>> Have you already fixed it? Released the updated 2.0.1? >> >>>>>>>> >> >>>>>>>> On 06/10/2016 11:19 AM, Jeff Johnston wrote: >> >>>>>>>>> This issue was introduced with a change to adding status >> >>> icons in the >> >>>>>>>>> Containers View. It wasn't noticed because it requires a >> >>> long time to >> >>>>>>>>> show (small image icons not being disposed of). >> >>>>>>>>> >> >>>>>>>>> -- Jeff J. >> >>>>>>>>> >> >>>>>>>>> ----- Original Message ----- >> >>>>>>>>>> We will conceder to include any updated in respin-b >> >>> besides branding >> >>>>>>>>>> only if we have to fix some very bad issues. Real blocker. >> >>>>>>>>>> Is this issue is old or some new regression? >> >>>>>>>>>> >> >>>>>>>>>> On 06/10/2016 10:57 AM, Xavier Coulon wrote: >> >>>>>>>>>>> From my understanding, Jeff noticed the issue after >> >>> letting >> >>>>>>>>>>> Eclipse >> >>>>>>>>>>> run >> >>>>>>>>>>> all night long, but I don't remember if Eclipse was >> >>> then unusable >> >>>>>>>>>>> or >> >>>>>>>>>>> crashed. >> >>>>>>>>>>> Anyway, it could be serious enough it users have the >> >>> Docker tooling >> >>>>>>>>>>> views >> >>>>>>>>>>> open in their workspace. >> >>>>>>>>>>> >> >>>>>>>>>>> Best regards, >> >>>>>>>>>>> Xavier >> >>>>>>>>>>>> On 10 Jun 2016, at 12:37, Alexey Kazakov >> >>> > >> >>>>>>>>>>>> wrote: >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> How bad is that leak? >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>>> On Jun 10, 2016, at 4:33 AM, Xavier Coulon >> >>> > >> >>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Fred, Alexey, >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Jeff J. found a memory leak in the Docker tooling. >> >>> It's too late >> >>>>>>>>>>>>> for >> >>>>>>>>>>>>> Neon.0 RC4/Final, but he proposes that we cut a Linux >> >>> Tools 5.0.1 / >> >>>>>>>>>>>>> Docker Tooling 2.0.1 to address this specific issue. >> >>>>>>>>>>>>> Is this something that can be included in the upcoming >> >>> "respin-b" >> >>>>>>>>>>>>> build >> >>>>>>>>>>>>> along with the branding updates ? I understand that Alexey >> >>>>>>>>>>>>> initially >> >>>>>>>>>>>>> said that this ultimate build would not include any >> >>> other bug fix, >> >>>>>>>>>>>>> but >> >>>>>>>>>>>>> nonetheless, I'm asking the question ;-) >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Best regards, >> >>>>>>>>>>>>> /Xavier >> >>>>>>>>>>>>> >> >>>>>>>>>>>>>> Hi Xavier, >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Jeff here. I found a memory leak in the Docker >> >>> Containers View. >> >>>>>>>>>>>>>> I >> >>>>>>>>>>>>>> believe it is fixed with my gerrit patch. If JBoss >> >>> wants, I can >> >>>>>>>>>>>>>> create >> >>>>>>>>>>>>>> a >> >>>>>>>>>>>>>> special repo for them to use to remove this bug. The >> >>> fix is too >> >>>>>>>>>>>>>> late >> >>>>>>>>>>>>>> for >> >>>>>>>>>>>>>> Neon, but we can cut a point release if necessary or >> >>> wait until >> >>>>>>>>>>>>>> 5.1 >> >>>>>>>>>>>>>> and >> >>>>>>>>>>>>>> fix it in the updates-nightly-neon. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> The problem was with the images used for status in >> >>> the Table. >> >>>>>>>>>>>>>> They >> >>>>>>>>>>>>>> were >> >>>>>>>>>>>>>> constantly being created via createImage() but never >> >>> stored any >> >>>>>>>>>>>>>> where >> >>>>>>>>>>>>>> and >> >>>>>>>>>>>>>> never disposed. I simply created 3 images for status >> >>> and return >> >>>>>>>>>>>>>> one >> >>>>>>>>>>>>>> of >> >>>>>>>>>>>>>> 3 >> >>>>>>>>>>>>>> for each table entry, then dispose of them in the >> >>> Containers View >> >>>>>>>>>>>>>> dispose >> >>>>>>>>>>>>>> method. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> -- Jeff J. >> >>>>>> >> >>>> >> >>>> >> >>> _______________________________________________ >> >>> jbosstools-dev mailing list >> >>> jbosstools-dev at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Nick Boldt :: JBoss by Red Hat >> >>> Productization Lead :: JBoss Tools & Dev Studio >> >>> http://nick.divbyzero.com >> >> >> >> >> > _______________________________________________ >> > jbosstools-dev mailing list >> > jbosstools-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> >> > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com From xcoulon at redhat.com Tue Jun 14 04:08:05 2016 From: xcoulon at redhat.com (Xavier Coulon) Date: Tue, 14 Jun 2016 10:08:05 +0200 Subject: [jbosstools-dev] Memory Leak in Docker Containers View In-Reply-To: References: <1592696271.21662157.1465577781515.JavaMail.zimbra@redhat.com> <575AFC94.5010405@redhat.com> <939602854.21686748.1465583740694.JavaMail.zimbra@redhat.com> <575B1874.70906@redhat.com> <1652038439.21701104.1465588216991.JavaMail.zimbra@redhat.com> <38067D5A-963E-4AB0-A755-EFAFB6EE77C6@redhat.com> <1522580708.22058243.1465833655982.JavaMail.zimbra@redhat.com> Message-ID: <7E9FFCDD-7B05-4474-BF7C-299A4D3EFA91@redhat.com> ok, thanks for the update, Nick and Jeff ! Best regards, Xavier > On 14 Jun 2016, at 00:03, Nick Boldt wrote: > > ICYMI, this is now being included in both Neon.0.RC4b and the > 4.60.0.Final target platform to be used with JBT 4.4.0.Final and > devstudio 10.0.0.GA. > > On Mon, Jun 13, 2016 at 12:00 PM, Jeff Johnston wrote: >> Normally, RC4 becomes the final release. Eclipse does not like rebulding unless it is >> critical. The bug in question is not critical because it doesn't show itself for a long >> time of usage. That said, I have been given permission to update if Neon rebuilds for another >> critical issue. I have created a 5.0.0 RC4a and Docker 2.0.0 RC4a repo with fix and >> updated the aggregation specs. If Neon rebuilds for any reason, it will get >> our RC4a. If not, the fix already exists in updates-docker-nightly-neon. If we decide to, >> we can cut a 2.0.1 docker release but only after Neon is officially released. >> >> JBoss and other users can at any time use the 2.0.0 RC4a repo which contains the fix if they >> don't want to update from the nightly site. >> >> -- Jeff J. >> >> ----- Original Message ----- >>> Jeff, >>> >>> To clarify: since Linux Tools 5.0.0.RC4/Docker tooling 2.0.0.RC4 were already >>> released, are these fixes going to be included in Docker tooling 2.0.0.Final >>> or do we need to make a 2.0.1 release ? >>> >>> Best regards, >>> Xavier >>> >>>> On 10 Jun 2016, at 21:50, Jeff Johnston wrote: >>>> >>>> The gerrit changes are the following: >>>> >>>> https://git.eclipse.org/r/#/c/75077/ >>>> https://git.eclipse.org/r/#/c/75088/ >>>> >>>> The first change is the one for Docker Containers View. The second >>>> contains >>>> a fix for Docker Explorer View and some actions. >>>> >>>> I understand your argument below. As mentioned, no user has seen it yet. >>>> You have the fix ready if someone reports it and it will be in the next >>>> sprint. >>>> >>>> -- Jeff J. >>>> >>>> ----- Original Message ----- >>>>> My main concern is that we don't have time to fix anything if there is >>>>> something broken in that new docker. So IMO this issues is not critical >>>>> enough to introduce even bigger risk for this release. >>>>> This is a bad issue but not a blocker in the current circumstances. >>>>> >>>>> Jeff, where we can see the code difference for the docker tooling? Do >>>>> you have a gerrit change, a PR or something? >>>>> >>>>> On 06/10/2016 03:08 PM, Nick Boldt wrote: >>>>>> Please clarify: is this a blocker for devstudio 10.0.0.GA >>>>>> ? Or something to pick up in a later sprint / release? >>>>>> >>>>>> Given we've slipped respin-a to Monday, and still have to rebrand >>>>>> everything, we probably have time to contain a small TP change like >>>>>> this. IFF it's a blocker. >>>>>> >>>>>> On Fri, Jun 10, 2016 at 2:35 PM, Jeff Johnston >>>>> > wrote: >>>>>> >>>>>> I have just made a build available with the patch in: >>>>>> >>>>>> http:/download.eclipse.org/linuxtools/update-neon-docker-rc4a >>>>>> >>>>>> >>>>>> -- Jeff J. >>>>>> >>>>>> ----- Original Message ----- >>>>>>> Moving to jbosstools-dev. >>>>>>> >>>>>>> OK. This memory leak seems to be bad. Please continue to work on >>>>>> proper >>>>>>> bug fix and update for the Linux/Docker Tools for Neon but I'm >>>>>> afraid we >>>>>>> don't have time to change anything in our Target Platform for >>>>>> devstudio >>>>>>> 10 GA / JBoss Tools 4.4.0.Final at this point. >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> On 06/10/2016 12:56 PM, Jeff Johnston wrote: >>>>>>>> Should be Neon only as status icons were added for Neon M1 >>>>>> milestone. >>>>>>>> There >>>>>>>> may be other image leaks in Mars, but they are minor and no >>>>>> errors have >>>>>>>> shown >>>>>>>> in our testing or customer usage. >>>>>>>> >>>>>>>> -- Jeff J. >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>>> Is this bug in Neon branch only? What about Mars releases? >>>>>>>>> >>>>>>>>> >>>>>>>>> On 06/10/2016 12:38 PM, Jeff Johnston wrote: >>>>>>>>>> It appears that the issue I found has been around since Aug >>>>>> 2015 (Neon >>>>>>>>>> M1). >>>>>>>>>> I have a fix >>>>>>>>>> and there appears to be another possible leak in the >>>>>> DockerExplorerView >>>>>>>>>> which I >>>>>>>>>> am pushing a fix for currently. >>>>>>>>>> >>>>>>>>>> I noticed the memory leak the other day and during my >>>>>> testing I saw that >>>>>>>>>> images >>>>>>>>>> were being left behind to the point that the Eclipse MAT >>>>>> tool took notice >>>>>>>>>> over a >>>>>>>>>> short period and flagged it as a suspected memory leak. Docker >>>>>>>>>> Containers >>>>>>>>>> get refreshed every 15 seconds so Views >>>>>>>>>> that show them (Docker Containers View and Docker Explorer >>>>>> View) that use >>>>>>>>>> icons need >>>>>>>>>> to dispose of them properly. For the Docker Containers >>>>>> View, all >>>>>>>>>> containers were being >>>>>>>>>> given a new image each refresh period. The Explorer View >>>>>> isn't much of a >>>>>>>>>> problem because >>>>>>>>>> it is node-based and doesn't always show the full list of >>>>>> Containers. A >>>>>>>>>> short list of Containers >>>>>>>>>> will slow down the leak as will closing the View. >>>>>>>>>> >>>>>>>>>> My intention was to do a quick rebuild of the stable-5.0 >>>>>> branch and save >>>>>>>>>> it >>>>>>>>>> as RC4a repo. If desired, >>>>>>>>>> I can do a point release, but this requires more changes to >>>>>> all features >>>>>>>>>> and pom files to renumber >>>>>>>>>> them. Let me know if a point release is required. >>>>>>>>>> >>>>>>>>>> I will continue with the task of building an RC4a repo that >>>>>> will be saved >>>>>>>>>> in the Linux Tools download >>>>>>>>>> area. Neon users will have to use the updates-nightly-neon >>>>>> repo which >>>>>>>>>> will >>>>>>>>>> have >>>>>>>>>> the fix (same git branch is used to create the RC4a repo). >>>>>>>>>> >>>>>>>>>> -- Jeff J. >>>>>>>>>> >>>>>>>>>> ----- Original Message ----- >>>>>>>>>>> When did it happen? How long do you have it in Docker Tools. >>>>>>>>>>> >>>>>>>>>>> Have you already fixed it? Released the updated 2.0.1? >>>>>>>>>>> >>>>>>>>>>> On 06/10/2016 11:19 AM, Jeff Johnston wrote: >>>>>>>>>>>> This issue was introduced with a change to adding status >>>>>> icons in the >>>>>>>>>>>> Containers View. It wasn't noticed because it requires a >>>>>> long time to >>>>>>>>>>>> show (small image icons not being disposed of). >>>>>>>>>>>> >>>>>>>>>>>> -- Jeff J. >>>>>>>>>>>> >>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>> We will conceder to include any updated in respin-b >>>>>> besides branding >>>>>>>>>>>>> only if we have to fix some very bad issues. Real blocker. >>>>>>>>>>>>> Is this issue is old or some new regression? >>>>>>>>>>>>> >>>>>>>>>>>>> On 06/10/2016 10:57 AM, Xavier Coulon wrote: >>>>>>>>>>>>>> From my understanding, Jeff noticed the issue after >>>>>> letting >>>>>>>>>>>>>> Eclipse >>>>>>>>>>>>>> run >>>>>>>>>>>>>> all night long, but I don't remember if Eclipse was >>>>>> then unusable >>>>>>>>>>>>>> or >>>>>>>>>>>>>> crashed. >>>>>>>>>>>>>> Anyway, it could be serious enough it users have the >>>>>> Docker tooling >>>>>>>>>>>>>> views >>>>>>>>>>>>>> open in their workspace. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Xavier >>>>>>>>>>>>>>> On 10 Jun 2016, at 12:37, Alexey Kazakov >>>>>> > >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> How bad is that leak? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Jun 10, 2016, at 4:33 AM, Xavier Coulon >>>>>> > >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Fred, Alexey, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Jeff J. found a memory leak in the Docker tooling. >>>>>> It's too late >>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>> Neon.0 RC4/Final, but he proposes that we cut a Linux >>>>>> Tools 5.0.1 / >>>>>>>>>>>>>>>> Docker Tooling 2.0.1 to address this specific issue. >>>>>>>>>>>>>>>> Is this something that can be included in the upcoming >>>>>> "respin-b" >>>>>>>>>>>>>>>> build >>>>>>>>>>>>>>>> along with the branding updates ? I understand that Alexey >>>>>>>>>>>>>>>> initially >>>>>>>>>>>>>>>> said that this ultimate build would not include any >>>>>> other bug fix, >>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>> nonetheless, I'm asking the question ;-) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>> /Xavier >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Xavier, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Jeff here. I found a memory leak in the Docker >>>>>> Containers View. >>>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>> believe it is fixed with my gerrit patch. If JBoss >>>>>> wants, I can >>>>>>>>>>>>>>>>> create >>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>> special repo for them to use to remove this bug. The >>>>>> fix is too >>>>>>>>>>>>>>>>> late >>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>> Neon, but we can cut a point release if necessary or >>>>>> wait until >>>>>>>>>>>>>>>>> 5.1 >>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> fix it in the updates-nightly-neon. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The problem was with the images used for status in >>>>>> the Table. >>>>>>>>>>>>>>>>> They >>>>>>>>>>>>>>>>> were >>>>>>>>>>>>>>>>> constantly being created via createImage() but never >>>>>> stored any >>>>>>>>>>>>>>>>> where >>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> never disposed. I simply created 3 images for status >>>>>> and return >>>>>>>>>>>>>>>>> one >>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>> 3 >>>>>>>>>>>>>>>>> for each table entry, then dispose of them in the >>>>>> Containers View >>>>>>>>>>>>>>>>> dispose >>>>>>>>>>>>>>>>> method. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- Jeff J. >>>>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> jbosstools-dev mailing list >>>>>> jbosstools-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nick Boldt :: JBoss by Red Hat >>>>>> Productization Lead :: JBoss Tools & Dev Studio >>>>>> http://nick.divbyzero.com >>>>> >>>>> >>>> _______________________________________________ >>>> jbosstools-dev mailing list >>>> jbosstools-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>> >>> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > > -- > Nick Boldt :: JBoss by Red Hat > Productization Lead :: JBoss Tools & Dev Studio > http://nick.divbyzero.com From nboldt at redhat.com Wed Jun 15 23:36:25 2016 From: nboldt at redhat.com (nboldt at redhat.com) Date: Wed, 15 Jun 2016 23:36:25 -0400 Subject: [jbosstools-dev] JBoss Tools Core 4.4.0.Final-b bits available for QE testing Message-ID: <201606160336.u5G3aPg4009341@dev01.mw.lab.eng.bos.redhat.com> These are not FINAL bits, but preliminary results for QE & community testing. Not for redistribution to customers or end users. Note that there is an issue installing the Integration Stack content -- currently, everything except Teiid Designer can be installed, prompting remediation. Update site: http://download.jboss.org/jbosstools/neon/staging/updates/ New + noteworthy (subject to change): * https://github.com/jbosstools/jbosstools-website/tree/master/documentation/whatsnew * http://tools.jboss.org/documentation/whatsnew/ Schedule: https://issues.jboss.org/projects/JBIDE?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page -- Additional update sites: * http://download.jboss.org/jbosstools/neon/staging/updates/core/4.4.0.Final-b/ * http://download.jboss.org/jbosstools/neon/staging/updates/coretests/4.4.0.Final-b/ Target platforms: * http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.60.0.Final * http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.60.0.Final Discovery sites: * http://download.jboss.org/jbosstools/neon/staging/updates/discovery.central/4.4.0.Final-b/ * http://download.jboss.org/jbosstools/neon/staging/updates/discovery.earlyaccess/4.4.0.Final-b/ Build folders (for build logs & update site zips): * http://download.jboss.org/jbosstools/neon/staging/builds/ -- Changes prompting this respin-b are: https://issues.jboss.org/issues/?jql=labels%20in%20%28%22respin-b%22%29%20and%20%28%28project%20in%20%28%22JBDS%22%29%20and%20fixversion%20in%20%28%2210.0.0.GA%22%29%29%20or%20%28project%20in%20%28%22JBIDE%22%2C%22TOOLSDOC%22%29%20and%20fixversion%20in%20%28%224.4.0.Final%22%29%29%29 To compare the upcoming version of Central (4.4.0.Final-b) against an older version, add lines similar to these your eclipse.ini file after the -vmargs line for the appropriate version & URLs: -Djboss.discovery.directory.url=http://download.jboss.org/jbosstools/neon/staging/updates/discovery.central/4.4.0.Final-b/jbosstools-directory.xml -Djboss.discovery.site.url=http://download.jboss.org/jbosstools/neon/staging/updates/ -Djboss.discovery.earlyaccess.site.url=http://download.jboss.org/jbosstools/neon/staging/updates/discovery.earlyaccess/4.4.0.Final-b/ -Djboss.discovery.earlyaccess.list.url=http://download.jboss.org/jbosstools/neon/staging/updates/discovery.earlyaccess/4.4.0.Final-b/jbosstools-earlyaccess.properties From nboldt at redhat.com Thu Jun 16 16:04:55 2016 From: nboldt at redhat.com (Nick Boldt) Date: Thu, 16 Jun 2016 16:04:55 -0400 Subject: [jbosstools-dev] 4.60.0.Final TP issue - two different versions of org.eclipse.egit.ui.smartimport Message-ID: Forwarding to larger audience. Since generally no one tries to install the whole TP concurrently, and since p2 remediation will allow users to install just the latest egit.ui.smartimport, I don't think this is a blocker. But it speaks to a problem with our new automated approach to TP verification via Jenkins jobs and p2diff files. Evidently they're not working. Or perhaps everyone is assuming everyone else is checking them, and in reality, no one is. I've opened https://issues.jboss.org/browse/JBIDE-22611 to track this issue, linked to the JIRA for our Neon.1 TP updates. Nick On Thu, Jun 16, 2016 at 2:05 PM, Paul Leacu wrote: > > Hey Nick - > Just stumbled across this: > > https://repository.jboss.org/nexus/content/groups/public/org/jboss/tools/targetplatforms/jbosstools-multiple/4.60.0.Final//jbosstools-multiple-4.60.0.Final-jbosstools-multiple.target#L281 > https://repository.jboss.org/nexus/content/groups/public/org/jboss/tools/targetplatforms/jbosstools-multiple/4.60.0.Final//jbosstools-multiple-4.60.0.Final-jbosstools-multiple.target#L482 > > org.eclipse.egit.ui.smartimport is defined twice with two different versions: > > [ERROR] Resolution failed: > [ERROR] Software being installed: org.eclipse.egit.ui.smartimport 4.4.0.201606011500-rc2 > [ERROR] Software being installed: org.eclipse.egit.ui.smartimport 4.4.0.201606070830-r > [ERROR] Only one of the following can be installed at once: [org.eclipse.egit.ui.smartimport 4.4.0.201606070830-r, org.eclipse.egit.ui.smartimport 4.4.0.201606011500-rc2] > > --paull -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com From aer-bot at ctrlflow.com Sun Jun 19 23:30:00 2016 From: aer-bot at ctrlflow.com (Automated Error Reporting Bot) Date: Mon, 20 Jun 2016 03:30:00 +0000 (UTC) Subject: [jbosstools-dev] [aeri] Weekly JBoss Tools Error Reports Digest Message-ID: <2121299963.13.1466393400905.JavaMail.ec2-user@aeri-rh> An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160620/7231d9b6/attachment-0001.html From aer-bot at ctrlflow.com Sun Jun 19 23:30:01 2016 From: aer-bot at ctrlflow.com (Automated Error Reporting Bot) Date: Mon, 20 Jun 2016 03:30:01 +0000 (UTC) Subject: [jbosstools-dev] [aeri] Weekly JBoss Tools Error Reports Digest Message-ID: <1384269424.5.1466393401327.JavaMail.ec2-user@aeri-rh> An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160620/4567ba81/attachment-0001.html From mistria at redhat.com Tue Jun 21 12:00:28 2016 From: mistria at redhat.com (Mickael Istria) Date: Tue, 21 Jun 2016 18:00:28 +0200 Subject: [jbosstools-dev] CI jobs building PR Message-ID: <5769649C.7050308@redhat.com> Hi all, A couple of weeks ago, we created some jobs on so-called "Central CI" to validate incoming pull requests: https://issues.jboss.org/browse/JBIDE-21657?focusedCommentId=13247039&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13247039 Those are now on for all components, but it may not be reporting on the PR for some components because of permissions. If you're using PR, and do not see report from CI jobs such as the one at the bottom of https://github.com/jbosstools/jbosstools-openshift/pull/1175 . If your component is missing those, please add a comment to JBIDE-21657 and we'll figure out what's missing and hopefully fix it. Cheers, -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160621/ef6b98f1/attachment.html From lheinema at redhat.com Wed Jun 22 01:18:54 2016 From: lheinema at redhat.com (Lars Heinemann) Date: Wed, 22 Jun 2016 07:18:54 +0200 Subject: [jbosstools-dev] CI jobs building PR In-Reply-To: <5769649C.7050308@redhat.com> References: <5769649C.7050308@redhat.com> Message-ID: <1466572734.3220.5.camel@redhat.com> Hi Mickael, we currently run the PR tests on the old jenkins. I am wondering if we are supposed to move to Central CI too. If yes, could you setup a job for me or grant me the appropriate rights to do it myself? Lars ##SELECTION_END## -------- Weitergeleitete Nachricht -------- Von: Mickael Istria An: jbosstools-dev jbosstools-dev Betreff: [jbosstools-dev] CI jobs building PR Datum: Tue, 21 Jun 2016 18:00:28 +0200 Mailer: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 Hi all, A couple of weeks ago, we created some jobs on so-called "Central CI" to validate incoming pull requests: https://issues.jboss.org/browse/JBI DE- 21657?focusedCommentId=13247039&page=com.atlassian.jira.plugin.system.i ssuetabpanels:comment-tabpanel#comment-13247039 Those are now on for all components, but it may not be reporting on the PR for some components because of permissions. If you're using PR, and do not see report from CI jobs such as the one at the bottom of https:/ /github.com/jbosstools/jbosstools-openshift/pull/1175 . If your component is missing those, please add a comment to JBIDE-21657 and we'll figure out what's missing and hopefully fix it. Cheers, --? Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets _______________________________________________ jbosstools-dev mailing list jbosstools-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160622/8d282280/attachment.html From mistria at redhat.com Wed Jun 22 01:31:28 2016 From: mistria at redhat.com (Mickael Istria) Date: Wed, 22 Jun 2016 07:31:28 +0200 Subject: [jbosstools-dev] CI jobs building PR In-Reply-To: <1466572734.3220.5.camel@redhat.com> References: <5769649C.7050308@redhat.com> <1466572734.3220.5.camel@redhat.com> Message-ID: <576A22B0.5090104@redhat.com> On 06/22/2016 07:18 AM, Lars Heinemann wrote: > Hi Mickael, Hi, > we currently run the PR tests on the old jenkins. I am wondering if we > are supposed to move to Central CI too. If yes, could you setup a job > for me or grant me the appropriate rights to do it myself? > It seems to me that this instance if for project inside the rhdevelopers program. For integration, you should get in touch with eng-ops and request a dedicated machine. Cheers, -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160622/1529d76e/attachment.html From jmaury at redhat.com Wed Jun 22 03:48:38 2016 From: jmaury at redhat.com (Jean-Francois Maury) Date: Wed, 22 Jun 2016 09:48:38 +0200 Subject: [jbosstools-dev] CI jobs building PR In-Reply-To: <576A22B0.5090104@redhat.com> References: <5769649C.7050308@redhat.com> <1466572734.3220.5.camel@redhat.com> <576A22B0.5090104@redhat.com> Message-ID: When does the job get launched ? Because I see lots of PR not being validated (late ones) in jboss-openshift (ex https://github.com/jbosstools/jbosstools-openshift/pull/1234). If the PR got updated, will the job launched again ? Thanks Jeff On Wed, Jun 22, 2016 at 7:31 AM, Mickael Istria wrote: > On 06/22/2016 07:18 AM, Lars Heinemann wrote: > > Hi Mickael, > > Hi, > > we currently run the PR tests on the old jenkins. I am wondering if we are > supposed to move to Central CI too. If yes, could you setup a job for me or > grant me the appropriate rights to do it myself? > > It seems to me that this instance if for project inside the rhdevelopers > program. For integration, you should get in touch with eng-ops and request > a dedicated machine. > > Cheers, > -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat > My blog - My Tweets > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160622/0165a151/attachment.html From mistria at redhat.com Wed Jun 22 05:15:23 2016 From: mistria at redhat.com (Mickael Istria) Date: Wed, 22 Jun 2016 11:15:23 +0200 Subject: [jbosstools-dev] CI jobs building PR In-Reply-To: References: <5769649C.7050308@redhat.com> <1466572734.3220.5.camel@redhat.com> <576A22B0.5090104@redhat.com> Message-ID: <576A572B.3030105@redhat.com> On 06/22/2016 09:48 AM, Jean-Francois Maury wrote: > When does the job get launched ? Because I see lots of PR not being > validated (late ones) in jboss-openshift (ex > https://github.com/jbosstools/jbosstools-openshift/pull/1234). If the > PR got updated, will the job launched again ? The job get launched automatically if the submitter is part of the "JBoss Tools" GitHub organization. In case the submitter isn't part of this organization, someone from this organization has to comment saying "testPR" to trigger the build. -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160622/cfda8192/attachment.html From marcel.bruch at codetrails.com Wed Jun 22 05:28:29 2016 From: marcel.bruch at codetrails.com (Marcel Bruch) Date: Wed, 22 Jun 2016 11:28:29 +0200 Subject: [jbosstools-dev] [aeri] Adding two new resolutions for "Invalid / Won't Do" Message-ID: Hi, we recently added two new problem resolutions to allow expressing that a problem report (i) is actually not a bug but rather a log message, and (ii) is not caused by JBoss Tools and cannot be fixed within JBoss Tools code (e.g., when the bug is located the Eclipse code base): "Log Message? and "Not JBoss?. Please consider using those resolutions instead of ?Invalid? or ?Won?t do? in future and were appropriate. Thank you. Marcel From jmaury at redhat.com Wed Jun 22 06:28:41 2016 From: jmaury at redhat.com (Jean-Francois Maury) Date: Wed, 22 Jun 2016 12:28:41 +0200 Subject: [jbosstools-dev] CI jobs building PR In-Reply-To: <576A572B.3030105@redhat.com> References: <5769649C.7050308@redhat.com> <1466572734.3220.5.camel@redhat.com> <576A22B0.5090104@redhat.com> <576A572B.3030105@redhat.com> Message-ID: Did it get relaunched when the PR is updated ? Jeff On Wed, Jun 22, 2016 at 11:15 AM, Mickael Istria wrote: > On 06/22/2016 09:48 AM, Jean-Francois Maury wrote: > > When does the job get launched ? Because I see lots of PR not being > validated (late ones) in jboss-openshift (ex > > https://github.com/jbosstools/jbosstools-openshift/pull/1234). If the PR > got updated, will the job launched again ? > > The job get launched automatically if the submitter is part of the "JBoss > Tools" GitHub organization. > In case the submitter isn't part of this organization, someone from this > organization has to comment saying "testPR" to trigger the build. > -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat > My blog - My Tweets > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160622/28452cd7/attachment.html From mistria at redhat.com Wed Jun 22 06:34:03 2016 From: mistria at redhat.com (Mickael Istria) Date: Wed, 22 Jun 2016 12:34:03 +0200 Subject: [jbosstools-dev] CI jobs building PR In-Reply-To: References: <5769649C.7050308@redhat.com> <1466572734.3220.5.camel@redhat.com> <576A22B0.5090104@redhat.com> <576A572B.3030105@redhat.com> Message-ID: <576A699B.70408@redhat.com> On 06/22/2016 12:28 PM, Jean-Francois Maury wrote: > Did it get relaunched when the PR is updated ? If it's updated by someone who's whitelisted (member of JBoss Tools organization on GitHub), then yes, it should be relaunched automatically. If it's from someone external, I believe someone has to say "testPR" to relaunch. On the GitHub PR, you can click on the "Show details" link for the build. It will drive you to Jenkins and on Jenkins you get access to more metadata such as the commitId that was built. HTH -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160622/c666a11a/attachment.html From alkazako at redhat.com Wed Jun 22 09:00:47 2016 From: alkazako at redhat.com (Alexey Kazakov) Date: Wed, 22 Jun 2016 09:00:47 -0400 Subject: [jbosstools-dev] CI jobs building PR In-Reply-To: <576A699B.70408@redhat.com> References: <5769649C.7050308@redhat.com> <1466572734.3220.5.camel@redhat.com> <576A22B0.5090104@redhat.com> <576A572B.3030105@redhat.com> <576A699B.70408@redhat.com> Message-ID: <576A8BFF.40303@redhat.com> Jeff, is a member of JBoss Tools organization. On 06/22/2016 06:34 AM, Mickael Istria wrote: > On 06/22/2016 12:28 PM, Jean-Francois Maury wrote: >> Did it get relaunched when the PR is updated ? > If it's updated by someone who's whitelisted (member of JBoss Tools > organization on GitHub), then yes, it should be relaunched > automatically. If it's from someone external, I believe someone has to > say "testPR" to relaunch. > On the GitHub PR, you can click on the "Show details" link for the > build. It will drive you to Jenkins and on Jenkins you get access to > more metadata such as the commitId that was built. > > HTH > -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat > My blog - My Tweets > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160622/af285ac4/attachment.html From manderse at redhat.com Wed Jun 22 09:45:58 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Wed, 22 Jun 2016 15:45:58 +0200 Subject: [jbosstools-dev] [aeri] Adding two new resolutions for "Invalid / Won't Do" In-Reply-To: References: Message-ID: Thanks Marcel! that is definitely useful! /max > Hi, > > we recently added two new problem resolutions to allow expressing that > a problem report (i) is actually not a bug but rather a log message, > and (ii) is not caused by JBoss Tools and cannot be fixed within JBoss > Tools code (e.g., when the bug is located the Eclipse code base): > > "Log Message? and "Not JBoss?. > > Please consider using those resolutions instead of ?Invalid? or > ?Won?t do? in future and were appropriate. > > Thank you. > Marcel > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev /max http://about.me/maxandersen From nboldt at redhat.com Wed Jun 22 10:54:19 2016 From: nboldt at redhat.com (Nick Boldt) Date: Wed, 22 Jun 2016 10:54:19 -0400 Subject: [jbosstools-dev] ACTION REQUIRED: Migration to jgit timestamps and sprint-based fixversions Message-ID: In the next week, we'll be making some changes to the way the parent pom and JIRA work for you. -- a) jgit timestamps Instead of a BUILD_ALIAS like Alpha1 or Beta1, which forces users to download a whole JBT or devstudio install each time we release a new milestone, plugins and features will soon use the timestamp of their last change in github. Note that two plugins will continue to have a BUILD_ALIAS applied: foundation.core & devstudio.central, which define the version of JBoss Tools / devstudio used by ide-config.properties to assign the correct URLs for Central and quickstarts. But as you'll see below, we will start using Sprint numbers here instead of quality labels like Alpha or Beta. This change will roll out next week once we're done with the Jun 27 release. ACTION REQUIRED: Now, when you're building locally, you will need to *check in your changes* (to your local github clone, not to origin!) in order to ensure that your local changes are seen as "newer" than the stuff available on download.jboss.org, or in your ~/.m2/repo. Ref: https://issues.jboss.org/browse/JBIDE-13671 -- b) sprint-based fixversions Because we no longer need to do the waterfall method of Alpha -> Beta -> CR -> Final, we will now start defining fixversions in JIRA using the sprint numbers, S116, S117, S118, etc. I've for the moment left the .Final and .GA fixversions in place for two reasons: * because we need .GA in order to allocate issues to Target Releases in the JBDS JIRA * because this lets you differentiate between things completed for the Final/GA release vs. things simply completed in a sprint. This change has already been done, in order to see the impact on downstream processes like jiralint. I've also renamed the sprints so that they include their start/end dates, rather than just "June 2016" because I figured that was more meaningful. Dates format is yyyy/mm/dd - mm/dd. You can see this on a board such as https://issues.jboss.org/secure/RapidBoard.jspa?rapidView=3410&view=planning.nodetail&quickFilter=10746 ACTION REQUIRED: Nothing. Ref: https://issues.jboss.org/browse/JBIDE-22619 -- If you have any concerns about these changes, please post them on the associated JIRAs: -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com From jmaury at redhat.com Wed Jun 22 11:20:57 2016 From: jmaury at redhat.com (Jean-Francois Maury) Date: Wed, 22 Jun 2016 17:20:57 +0200 Subject: [jbosstools-dev] CI jobs building PR In-Reply-To: <576A8BFF.40303@redhat.com> References: <5769649C.7050308@redhat.com> <1466572734.3220.5.camel@redhat.com> <576A22B0.5090104@redhat.com> <576A572B.3030105@redhat.com> <576A699B.70408@redhat.com> <576A8BFF.40303@redhat.com> Message-ID: Will it be part of our merge workflow ie merging the PR won't be allowed if the status is not green or has it to be manually by the merger ? jeff On Wed, Jun 22, 2016 at 3:00 PM, Alexey Kazakov wrote: > Jeff, is a member of JBoss Tools organization. > > > On 06/22/2016 06:34 AM, Mickael Istria wrote: > > On 06/22/2016 12:28 PM, Jean-Francois Maury wrote: > > Did it get relaunched when the PR is updated ? > > If it's updated by someone who's whitelisted (member of JBoss Tools > organization on GitHub), then yes, it should be relaunched automatically. > If it's from someone external, I believe someone has to say "testPR" to > relaunch. > On the GitHub PR, you can click on the "Show details" link for the build. > It will drive you to Jenkins and on Jenkins you get access to more metadata > such as the commitId that was built. > > HTH > -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat > My blog - My Tweets > > > > _______________________________________________ > jbosstools-dev mailing listjbosstools-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160622/c7745473/attachment-0001.html From alkazako at redhat.com Wed Jun 22 11:45:38 2016 From: alkazako at redhat.com (Alexey Kazakov) Date: Wed, 22 Jun 2016 11:45:38 -0400 Subject: [jbosstools-dev] CI jobs building PR In-Reply-To: References: <5769649C.7050308@redhat.com> <1466572734.3220.5.camel@redhat.com> <576A22B0.5090104@redhat.com> <576A572B.3030105@redhat.com> <576A699B.70408@redhat.com> <576A8BFF.40303@redhat.com> Message-ID: <576AB2A2.2090905@redhat.com> Yes, we should work on that workflow. On 06/22/2016 11:20 AM, Jean-Francois Maury wrote: > Will it be part of our merge workflow ie merging the PR won't be > allowed if the status is not green or has it to be manually by the > merger ? > > jeff > > On Wed, Jun 22, 2016 at 3:00 PM, Alexey Kazakov > wrote: > > Jeff, is a member of JBoss Tools organization. > > > On 06/22/2016 06:34 AM, Mickael Istria wrote: >> On 06/22/2016 12:28 PM, Jean-Francois Maury wrote: >>> Did it get relaunched when the PR is updated ? >> If it's updated by someone who's whitelisted (member of JBoss >> Tools organization on GitHub), then yes, it should be relaunched >> automatically. If it's from someone external, I believe someone >> has to say "testPR" to relaunch. >> On the GitHub PR, you can click on the "Show details" link for >> the build. It will drive you to Jenkins and on Jenkins you get >> access to more metadata such as the commitId that was built. >> >> HTH >> -- >> Mickael Istria >> Eclipse developer at JBoss, by Red Hat >> My blog - My Tweets >> >> >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160622/143b7d50/attachment.html From nboldt at redhat.com Wed Jun 22 12:20:40 2016 From: nboldt at redhat.com (Nick Boldt) Date: Wed, 22 Jun 2016 12:20:40 -0400 Subject: [jbosstools-dev] CI jobs building PR In-Reply-To: <576AB2A2.2090905@redhat.com> References: <5769649C.7050308@redhat.com> <1466572734.3220.5.camel@redhat.com> <576A22B0.5090104@redhat.com> <576A572B.3030105@redhat.com> <576A699B.70408@redhat.com> <576A8BFF.40303@redhat.com> <576AB2A2.2090905@redhat.com> Message-ID: Joining late so apologies if this was already said. PR jobs could be configured to set up whitelists of people for which a "testPR" keyword is not needed. In fact, it would be awesome if all PRs from people in the jbosstools organization would be build automatically w/o the need to approve the PR prior to it being built. $0.02, Nick On Wed, Jun 22, 2016 at 11:45 AM, Alexey Kazakov wrote: > Yes, we should work on that workflow. > > On 06/22/2016 11:20 AM, Jean-Francois Maury wrote: > > Will it be part of our merge workflow ie merging the PR won't be allowed if > the status is not green or has it to be manually by the merger ? > > jeff > > On Wed, Jun 22, 2016 at 3:00 PM, Alexey Kazakov wrote: >> >> Jeff, is a member of JBoss Tools organization. >> >> >> On 06/22/2016 06:34 AM, Mickael Istria wrote: >> >> On 06/22/2016 12:28 PM, Jean-Francois Maury wrote: >> >> Did it get relaunched when the PR is updated ? >> >> If it's updated by someone who's whitelisted (member of JBoss Tools >> organization on GitHub), then yes, it should be relaunched automatically. If >> it's from someone external, I believe someone has to say "testPR" to >> relaunch. >> On the GitHub PR, you can click on the "Show details" link for the build. >> It will drive you to Jenkins and on Jenkins you get access to more metadata >> such as the commitId that was built. >> >> HTH >> -- >> Mickael Istria >> Eclipse developer at JBoss, by Red Hat >> My blog - My Tweets >> >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> >> > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com From mistria at redhat.com Wed Jun 22 12:32:21 2016 From: mistria at redhat.com (Mickael Istria) Date: Wed, 22 Jun 2016 18:32:21 +0200 Subject: [jbosstools-dev] CI jobs building PR In-Reply-To: References: <5769649C.7050308@redhat.com> <1466572734.3220.5.camel@redhat.com> <576A22B0.5090104@redhat.com> <576A572B.3030105@redhat.com> <576A699B.70408@redhat.com> <576A8BFF.40303@redhat.com> <576AB2A2.2090905@redhat.com> Message-ID: <576ABD95.5070500@redhat.com> On 06/22/2016 06:20 PM, Nick Boldt wrote: > PR jobs could be configured to set up whitelists of people for which a > "testPR" keyword is not needed. In fact, it would be awesome if all > PRs from people in the jbosstools organization would be build > automatically w/o the need to approve the PR prior to it being built. It's actually how they are currently configured. If this doesn't work, please open a Jira and investigate. -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160622/e02761b3/attachment.html From mistria at redhat.com Wed Jun 22 12:34:17 2016 From: mistria at redhat.com (Mickael Istria) Date: Wed, 22 Jun 2016 18:34:17 +0200 Subject: [jbosstools-dev] CI jobs building PR In-Reply-To: References: <5769649C.7050308@redhat.com> <1466572734.3220.5.camel@redhat.com> <576A22B0.5090104@redhat.com> <576A572B.3030105@redhat.com> <576A699B.70408@redhat.com> <576A8BFF.40303@redhat.com> Message-ID: <576ABE09.8010209@redhat.com> On 06/22/2016 05:20 PM, Jean-Francois Maury wrote: > Will it be part of our merge workflow ie merging the PR won't be > allowed if the status is not green or has it to be manually by the > merger ? AFAIK, there is no easy way on GitHub to automatically prevent a commit from being merged via GitHub UI. So at the moment, taking build results into account is the duty of the individual who wants to merge the patch. Once again, Gerrit does it better :P -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160622/30557ebb/attachment.html From fbricon at redhat.com Wed Jun 22 12:38:50 2016 From: fbricon at redhat.com (Fred Bricon) Date: Wed, 22 Jun 2016 12:38:50 -0400 Subject: [jbosstools-dev] Upcoming change in test lookups during Maven builds Message-ID: Team, we're about to modify the default pattern that determines which tests are running in tycho builds [1]. It currently searches for these patterns: **/AllTests.class **/*AllTests*.class **/*AllBotTests*.class **/*TestSuite*.class Instead, we'll move back to using surefire's default patterns (**/Test*.java, **/*Test.java, **/*TestCase.java) The main driver for this change is we currently have tests not referenced in test suites, that are not run during CLI builds [2], which is bad. So, to all component leaders, please verify, once this changes is applied, whether: - new tests are run and fail the build, in which case you need to fix them - tests are gone missing from the CI build, in which case, their classes need to be renamed following surefire's syntax. If you find regressions requiring significant changes in your component, you can apply the original pattern to the tycho-surefire-plugin configuration of your component pom.xml [1] https://issues.jboss.org/browse/JBIDE-19081 [2] https://issues.jboss.org/browse/JBIDE-22449 Fred -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160622/f4d7ddee/attachment.html From manderse at redhat.com Wed Jun 22 12:44:30 2016 From: manderse at redhat.com (Max Andersen) Date: Wed, 22 Jun 2016 18:44:30 +0200 Subject: [jbosstools-dev] CI jobs building PR In-Reply-To: <576ABE09.8010209@redhat.com> References: <5769649C.7050308@redhat.com> <1466572734.3220.5.camel@redhat.com> <576A22B0.5090104@redhat.com> <576A572B.3030105@redhat.com> <576A699B.70408@redhat.com> <576A8BFF.40303@redhat.com> <576ABE09.8010209@redhat.com> Message-ID: Well we could remove all push rights to master repos and let the ci bot do the merge. Then it's as prevented as gerrit. I believe that's what openshift does. But they have actual integration tests too :) But yes gerrit has nicer flow overall. /max On Wednesday, 22 June 2016, Mickael Istria wrote: > On 06/22/2016 05:20 PM, Jean-Francois Maury wrote: > > Will it be part of our merge workflow ie merging the PR won't be allowed > if the status is not green or has it to be manually by the merger ? > > AFAIK, there is no easy way on GitHub to automatically prevent a commit > from being merged via GitHub UI. So at the moment, taking build results > into account is the duty of the individual who wants to merge the patch. > Once again, Gerrit does it better :P > -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat > My blog - My Tweets > > -- /max https://about.me/maxandersen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160622/043728ed/attachment-0001.html From mistria at redhat.com Wed Jun 22 12:49:48 2016 From: mistria at redhat.com (Mickael Istria) Date: Wed, 22 Jun 2016 18:49:48 +0200 Subject: [jbosstools-dev] CI jobs building PR In-Reply-To: References: <5769649C.7050308@redhat.com> <1466572734.3220.5.camel@redhat.com> <576A22B0.5090104@redhat.com> <576A572B.3030105@redhat.com> <576A699B.70408@redhat.com> <576A8BFF.40303@redhat.com> <576ABE09.8010209@redhat.com> Message-ID: <576AC1AC.6060807@redhat.com> On 06/22/2016 06:44 PM, Max Andersen wrote: > Well we could remove all push rights to master repos and let the ci > bot do the merge. You mean a CI bot that would merge on developer request? If so I don't get how it's better than leaving the developer push directly. > Then it's as prevented as gerrit. Usually, Gerrit UI simply hides the "Submit" button on a contribution if it doesn't conform to project requirements (fast-forward, Verified+1, Code-Review+2, no -1). AFAIK, there is no way to add such logic on GitHub UI and the Merge button is always there, even when no-one likes it. Note that usually with Gerrit, it's still possible for committers to push directly to master. But indeed, some projects do lock master and only allow submission via Gerrit UI. Would GitHub allow that? Would it be good to use it given the limitation explained above (no way to control the availability of the merge operation in UI) ? -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160622/cb634e18/attachment.html From manderse at redhat.com Wed Jun 22 13:14:03 2016 From: manderse at redhat.com (Max Andersen) Date: Wed, 22 Jun 2016 19:14:03 +0200 Subject: [jbosstools-dev] ACTION REQUIRED: Migration to jgit timestamps and sprint-based fixversions In-Reply-To: References: Message-ID: Great to see these changes made and looking forward to see it help overall. But could you please rollback the change about putting dates into the sprint names. That was not agreed upon and is very noisy. Optimally it should just be the sprint number but that don't work well In JIRA since it is a global sprint namespace. We agreesd on adding the main month in the sprint to give an idea of where it is. The details about exact date is noise. Please roll that back. Thank you. /max On Wednesday, 22 June 2016, Nick Boldt wrote: > In the next week, we'll be making some changes to the way the parent > pom and JIRA work for you. > > -- > > a) jgit timestamps > > Instead of a BUILD_ALIAS like Alpha1 or Beta1, which forces users to > download a whole JBT or devstudio install each time we release a new > milestone, plugins and features will soon use the timestamp of their > last change in github. > > Note that two plugins will continue to have a BUILD_ALIAS applied: > foundation.core & devstudio.central, which define the version of JBoss > Tools / devstudio used by ide-config.properties to assign the correct > URLs for Central and quickstarts. But as you'll see below, we will > start using Sprint numbers here instead of quality labels like Alpha > or Beta. > > This change will roll out next week once we're done with the Jun 27 > release. > > ACTION REQUIRED: Now, when you're building locally, you will need to > *check in your changes* (to your local github clone, not to origin!) > in order to ensure that your local changes are seen as "newer" than > the stuff available on download.jboss.org, or in your ~/.m2/repo. > > Ref: https://issues.jboss.org/browse/JBIDE-13671 > > -- > > b) sprint-based fixversions > > Because we no longer need to do the waterfall method of Alpha -> Beta > -> CR -> Final, we will now start defining fixversions in JIRA using > the sprint numbers, S116, S117, S118, etc. I've for the moment left > the .Final and .GA fixversions in place for two reasons: > > * because we need .GA in order to allocate issues to Target Releases > in the JBDS JIRA > > * because this lets you differentiate between things completed for the > Final/GA release vs. things simply completed in a sprint. > > This change has already been done, in order to see the impact on > downstream processes like jiralint. > > I've also renamed the sprints so that they include their start/end > dates, rather than just "June 2016" because I figured that was more > meaningful. Dates format is yyyy/mm/dd - mm/dd. You can see this on a > board such as > https://issues.jboss.org/secure/RapidBoard.jspa?rapidView=3410&view=planning.nodetail&quickFilter=10746 > > ACTION REQUIRED: Nothing. > > Ref: https://issues.jboss.org/browse/JBIDE-22619 > > -- > > If you have any concerns about these changes, please post them on the > associated JIRAs: > > -- > Nick Boldt :: JBoss by Red Hat > Productization Lead :: JBoss Tools & Dev Studio > http://nick.divbyzero.com > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > -- /max https://about.me/maxandersen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160622/e195e392/attachment.html From alkazako at redhat.com Wed Jun 22 13:24:35 2016 From: alkazako at redhat.com (Alexey Kazakov) Date: Wed, 22 Jun 2016 13:24:35 -0400 Subject: [jbosstools-dev] ACTION REQUIRED: Migration to jgit timestamps and sprint-based fixversions In-Reply-To: References: Message-ID: <576AC9D3.3020208@redhat.com> On 06/22/2016 01:14 PM, Max Andersen wrote: > > Great to see these changes made and looking forward to see it help > overall. > > But could you please rollback the change about putting dates into the > sprint names. That was not agreed upon and is very noisy. > > Optimally it should just be the sprint number but that don't work well > In JIRA since it is a global sprint namespace. > > We agreesd on adding the main month in the sprint to give an idea of > where it is. The details about exact date is noise. > > Please roll that back. Thank you. +1 From nboldt at redhat.com Wed Jun 22 13:43:37 2016 From: nboldt at redhat.com (Nick Boldt) Date: Wed, 22 Jun 2016 13:43:37 -0400 Subject: [jbosstools-dev] ACTION REQUIRED: Migration to jgit timestamps and sprint-based fixversions In-Reply-To: References: Message-ID: I disagree. Using the "main month in the sprint to give an idea" is a far less useful piece of information than the actual start/end dates, which give you the ACTUAL dates at a glance. When sprints cross months, as most do, which month should be selected? The start month? the end month? or the one that makes up the largest percentage in the sprint? If you feel it's too much information, just glance away. -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com From alkazako at redhat.com Wed Jun 22 15:27:38 2016 From: alkazako at redhat.com (Alexey Kazakov) Date: Wed, 22 Jun 2016 15:27:38 -0400 Subject: [jbosstools-dev] ACTION REQUIRED: Migration to jgit timestamps and sprint-based fixversions In-Reply-To: References: Message-ID: <576AE6AA.7090603@redhat.com> Nick, I also think that the new long names are too "noise". Too many numbers. It's hard to read. Month is enough IMO even if we have two sprints for the same month. I understand that we all can have different preferences. And what is hard to read for us may provide additional useful information for you or someone else. This is why it's very important to discuss such changes first and got to agreement *before* changing it. Can you just revert it for now then we can discuss it later? On 06/22/2016 01:43 PM, Nick Boldt wrote: > I disagree. > > Using the "main month in the sprint to give an idea" is a far less > useful piece of information than the actual start/end dates, which > give you the ACTUAL dates at a glance. > > When sprints cross months, as most do, which month should be selected? > The start month? the end month? or the one that makes up the largest > percentage in the sprint? > > If you feel it's too much information, just glance away. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160622/de903814/attachment.html From stryker at redhat.com Wed Jun 22 23:05:28 2016 From: stryker at redhat.com (Robert Stryker) Date: Wed, 22 Jun 2016 23:05:28 -0400 Subject: [jbosstools-dev] Intention to remove "Server Log View" Message-ID: Hey all: https://issues.jboss.org/browse/JBIDE-22635 The Server Log View had a pretty complicated API, meant to look like the Error Log View, but with some additional mechanisms for sorting the events or providing icons for the various events. In all honesty, it was poorly-conceived from the beginning. Anything that should be logged there should really be logged in the error-log view anyway, so other than that, it's only useful feature was more of a tracing / logging mechanism that would be less annoying to the user. In fact, it's been found to have been used less often than it should be, and used inconsistantly. As far as I can tell, no other plugins other than AS Tools are using it, and some other server adapters have requested the action be removed (since they're not using the API to log events, it's basically useless to them). Anyway, I think it'd make the most sense to remove it. I don't think it's saveable really ;) Any thoughts or objections? - Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160622/d538cfa5/attachment-0001.html From ggastald at redhat.com Wed Jun 22 23:08:14 2016 From: ggastald at redhat.com (George Gastaldi) Date: Thu, 23 Jun 2016 00:08:14 -0300 Subject: [jbosstools-dev] Intention to remove "Server Log View" In-Reply-To: References: Message-ID: +1 to remove it. Never liked or used that view anyway :) Em 23 de jun de 2016 00:06, "Robert Stryker" escreveu: > Hey all: > > https://issues.jboss.org/browse/JBIDE-22635 > > The Server Log View had a pretty complicated API, meant to look like the > Error Log View, but with some additional mechanisms for sorting the events > or providing icons for the various events. > > In all honesty, it was poorly-conceived from the beginning. Anything that > should be logged there should really be logged in the error-log view > anyway, so other than that, it's only useful feature was more of a tracing > / logging mechanism that would be less annoying to the user. > > In fact, it's been found to have been used less often than it should be, > and used inconsistantly. As far as I can tell, no other plugins other than > AS Tools are using it, and some other server adapters have requested the > action be removed (since they're not using the API to log events, it's > basically useless to them). > > Anyway, I think it'd make the most sense to remove it. I don't think it's > saveable really ;) > > Any thoughts or objections? > > - Rob > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160623/a88f1f80/attachment.html From manderse at redhat.com Thu Jun 23 03:55:21 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Thu, 23 Jun 2016 09:55:21 +0200 Subject: [jbosstools-dev] ACTION REQUIRED: Migration to jgit timestamps and sprint-based fixversions In-Reply-To: <576AE6AA.7090603@redhat.com> References: <576AE6AA.7090603@redhat.com> Message-ID: <36557BCD-8CF3-4225-A602-F459A86B16A4@redhat.com> I rolled this change back. To illustrate why exact dates are noise as Alexey mentions, see https://docs.google.com/document/d/1hkn5iYLECN9L-7NK0Q-r_HwvNDpih3P8O7THoZVyGs4/edit?usp=sharing And to answer Nick's question: "When sprints cross months, as most do, which month should be selected? The start month? the end month? or the one that makes up the largest percentage in the sprint?" The start month. That is how it was done from the beginning. /max > Nick, > > I also think that the new long names are too "noise". Too many > numbers. It's hard to read. Month is enough IMO even if we have two > sprints for the same month. > I understand that we all can have different preferences. And what is > hard to read for us may provide additional useful information for you > or someone else. > This is why it's very important to discuss such changes first and got > to agreement *before* changing it. > > Can you just revert it for now then we can discuss it later? > > On 06/22/2016 01:43 PM, Nick Boldt wrote: >> I disagree. >> >> Using the "main month in the sprint to give an idea" is a far less >> useful piece of information than the actual start/end dates, which >> give you the ACTUAL dates at a glance. >> >> When sprints cross months, as most do, which month should be >> selected? >> The start month? the end month? or the one that makes up the largest >> percentage in the sprint? >> >> If you feel it's too much information, just glance away. >> /max http://about.me/maxandersen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160623/6d789434/attachment.html From xcoulon at redhat.com Thu Jun 23 04:20:40 2016 From: xcoulon at redhat.com (Xavier Coulon) Date: Thu, 23 Jun 2016 10:20:40 +0200 Subject: [jbosstools-dev] Docker Tooling for Eclipse Neon Webinar - June 23 9AM EST Message-ID: Hello, Today at 9am EST I'll present the Docker tooling that ships in Eclipse Neon. If you're interested in discovering what kind of tooling we built for Docker and how to use it, feel free to join by registering on https://www.eclipse.org/community/webinars/ Best regards, Xavier -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160623/2e98efc4/attachment.html From xcoulon at redhat.com Thu Jun 23 04:20:40 2016 From: xcoulon at redhat.com (Xavier Coulon) Date: Thu, 23 Jun 2016 10:20:40 +0200 Subject: [jbosstools-dev] Docker Tooling for Eclipse Neon Webinar - June 23 9AM EST Message-ID: Hello, Today at 9am EST I'll present the Docker tooling that ships in Eclipse Neon. If you're interested in discovering what kind of tooling we built for Docker and how to use it, feel free to join by registering on https://www.eclipse.org/community/webinars/ Best regards, Xavier -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160623/2e98efc4/attachment-0001.html From jmaury at redhat.com Thu Jun 23 05:30:56 2016 From: jmaury at redhat.com (Jean-Francois Maury) Date: Thu, 23 Jun 2016 11:30:56 +0200 Subject: [jbosstools-dev] CI jobs building PR In-Reply-To: <576AC1AC.6060807@redhat.com> References: <5769649C.7050308@redhat.com> <1466572734.3220.5.camel@redhat.com> <576A22B0.5090104@redhat.com> <576A572B.3030105@redhat.com> <576A699B.70408@redhat.com> <576A8BFF.40303@redhat.com> <576ABE09.8010209@redhat.com> <576AC1AC.6060807@redhat.com> Message-ID: OK this is running ok if I update the PR. But the PR page says 1 successful check although 2 have run (see https://github.com/jbosstools/jbosstools-openshift/pull/1235). it is a Github pb ? Jeff On Wed, Jun 22, 2016 at 6:49 PM, Mickael Istria wrote: > On 06/22/2016 06:44 PM, Max Andersen wrote: > > Well we could remove all push rights to master repos and let the ci bot do > the merge. > > You mean a CI bot that would merge on developer request? If so I don't get > how it's better than leaving the developer push directly. > > Then it's as prevented as gerrit. > > Usually, Gerrit UI simply hides the "Submit" button on a contribution if > it doesn't conform to project requirements (fast-forward, Verified+1, > Code-Review+2, no -1). AFAIK, there is no way to add such logic on GitHub > UI and the Merge button is always there, even when no-one likes it. > > Note that usually with Gerrit, it's still possible for committers to push > directly to master. > But indeed, some projects do lock master and only allow submission via > Gerrit UI. Would GitHub allow that? Would it be good to use it given the > limitation explained above (no way to control the availability of the merge > operation in UI) ? > > -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat > My blog - My Tweets > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160623/e6775837/attachment.html From mistria at redhat.com Thu Jun 23 07:46:10 2016 From: mistria at redhat.com (Mickael Istria) Date: Thu, 23 Jun 2016 13:46:10 +0200 Subject: [jbosstools-dev] CI jobs building PR In-Reply-To: References: <5769649C.7050308@redhat.com> <1466572734.3220.5.camel@redhat.com> <576A22B0.5090104@redhat.com> <576A572B.3030105@redhat.com> <576A699B.70408@redhat.com> <576A8BFF.40303@redhat.com> <576ABE09.8010209@redhat.com> <576AC1AC.6060807@redhat.com> Message-ID: <576BCC02.9070400@redhat.com> On 06/23/2016 11:30 AM, Jean-Francois Maury wrote: > OK this is running ok if I update the PR. But the PR page says 1 > successful check although 2 have run (see > https://github.com/jbosstools/jbosstools-openshift/pull/1235). it is a > Github pb ? As far as I understand, the status of the GitHub PR is the status of the last commit. If you append a commit, then the status is wiped out, build starts up and then status for the new commit is show. So even if there were 2 successive build, it only shows the "1 successful build" for the latest one, and previous is ignored. If we set up different jobs to review PRs (for example of distinct code quality job), then you'll see the result of these 2 jobs on each commit. If you want to track previous builds for individual commits, there's a green tick or a red cross attached to each commit that was tested. Those are visible at https://github.com/jbosstools/jbosstools-openshift/pull/1235/commits . Clicking on the green tick or red cross directs you to the Jenkins build. HTH -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160623/5f0a82bf/attachment-0001.html From alkazako at redhat.com Thu Jun 23 11:18:31 2016 From: alkazako at redhat.com (Alexey Kazakov) Date: Thu, 23 Jun 2016 11:18:31 -0400 Subject: [jbosstools-dev] ACTION REQUIRED: Migration to jgit timestamps and sprint-based fixversions In-Reply-To: References: Message-ID: <576BFDC7.4000406@redhat.com> After further discussion with Max, Nick and Jeff we agreed to use M1, M2, M3, etc suffixes instead of S114, S115 or Alpha1, Beta1 etc in fix versions in JIRA, pom.xml's, etc. Sorry for all these changes and confusion they may cause but we are still trying to find the best way to version our stuff. So, our fix versions will look something like 4.4.1.M1, 4.4.1.M2, 4.4.1.GA, 4.5.0.M1, 4.5.0.M2, 4.5.0.GA etc. If there is no any objections then I would like to ask Nick to go ahead and fix all the relevant places where we use that suffixes for our versions. On 06/22/2016 10:54 AM, Nick Boldt wrote: > b) sprint-based fixversions > > Because we no longer need to do the waterfall method of Alpha -> Beta > -> CR -> Final, we will now start defining fixversions in JIRA using > the sprint numbers, S116, S117, S118, etc. I've for the moment left > the .Final and .GA fixversions in place for two reasons: > > * because we need .GA in order to allocate issues to Target Releases > in the JBDS JIRA > > * because this lets you differentiate between things completed for the > Final/GA release vs. things simply completed in a sprint. > > This change has already been done, in order to see the impact on > downstream processes like jiralint. > > I've also renamed the sprints so that they include their start/end > dates, rather than just "June 2016" because I figured that was more > meaningful. Dates format is yyyy/mm/dd - mm/dd. You can see this on a > board such as https://issues.jboss.org/secure/RapidBoard.jspa?rapidView=3410&view=planning.nodetail&quickFilter=10746 > > ACTION REQUIRED: Nothing. > > Ref: https://issues.jboss.org/browse/JBIDE-22619 > > -- > > If you have any concerns about these changes, please post them on the > associated JIRAs: > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160623/c3ca491f/attachment.html From jcantril at redhat.com Thu Jun 23 15:57:25 2016 From: jcantril at redhat.com (Jeff Cantrill) Date: Thu, 23 Jun 2016 15:57:25 -0400 Subject: [jbosstools-dev] Refactoring openshift-restclient-java to depend upon OkHttp client Message-ID: The current release of the openshift-restclient-java, for not so obvious reasons, depends on no less then 3 libraries to provide the underlying communication to the cluster server. The following PR https://github.com/openshift/openshift-restclient-java/pull/179 unifies this dependency to a single client which is based on OkHttp. We are looking to make this change to: * Provide a common way to make REST calls * Simplify the authorization semantics to an openshift cluster * Simplify the pattern of making REST calls over what is done today * In future, take advantage of its SPDY support to move away from the oc binary dependency * Put us in a better position to move to the Fabric8 client (if that ever happens) Any comments or objects are welcome -- -- Jeff Cantrill Senior Software Engineer, Red Hat Engineering OpenShift Integration Services Red Hat, Inc. *Office*: 703-748-4420 | 866-546-8970 ext. 8162420 jcantril at redhat.com http://www.redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160623/91327696/attachment.html From nboldt at redhat.com Thu Jun 23 16:43:14 2016 From: nboldt at redhat.com (Nick Boldt) Date: Thu, 23 Jun 2016 16:43:14 -0400 Subject: [jbosstools-dev] ACTION REQUIRED: Migration to jgit timestamps and sprint-based fixversions In-Reply-To: <576BFDC7.4000406@redhat.com> References: <576BFDC7.4000406@redhat.com> Message-ID: JIRA has been updated to use M* instead of S* milestone names. https://issues.jboss.org/projects/JBIDE?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page https://issues.jboss.org/projects/JBDS?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page On Thu, Jun 23, 2016 at 11:18 AM, Alexey Kazakov wrote: > After further discussion with Max, Nick and Jeff we agreed to use M1, M2, > M3, etc suffixes instead of S114, S115 or Alpha1, Beta1 etc in fix versions > in JIRA, pom.xml's, etc. > Sorry for all these changes and confusion they may cause but we are still > trying to find the best way to version our stuff. > > So, our fix versions will look something like 4.4.1.M1, 4.4.1.M2, 4.4.1.GA, > 4.5.0.M1, 4.5.0.M2, 4.5.0.GA etc. > > If there is no any objections then I would like to ask Nick to go ahead and > fix all the relevant places where we use that suffixes for our versions. > > On 06/22/2016 10:54 AM, Nick Boldt wrote: > > b) sprint-based fixversions > > Because we no longer need to do the waterfall method of Alpha -> Beta > -> CR -> Final, we will now start defining fixversions in JIRA using > the sprint numbers, S116, S117, S118, etc. I've for the moment left > the .Final and .GA fixversions in place for two reasons: > > * because we need .GA in order to allocate issues to Target Releases > in the JBDS JIRA > > * because this lets you differentiate between things completed for the > Final/GA release vs. things simply completed in a sprint. > > This change has already been done, in order to see the impact on > downstream processes like jiralint. > > I've also renamed the sprints so that they include their start/end > dates, rather than just "June 2016" because I figured that was more > meaningful. Dates format is yyyy/mm/dd - mm/dd. You can see this on a > board such as > https://issues.jboss.org/secure/RapidBoard.jspa?rapidView=3410&view=planning.nodetail&quickFilter=10746 > > ACTION REQUIRED: Nothing. > > Ref: https://issues.jboss.org/browse/JBIDE-22619 > > -- > > If you have any concerns about these changes, please post them on the > associated JIRAs: > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com From mistria at redhat.com Fri Jun 24 03:48:50 2016 From: mistria at redhat.com (Mickael Istria) Date: Fri, 24 Jun 2016 09:48:50 +0200 Subject: [jbosstools-dev] Refactoring openshift-restclient-java to depend upon OkHttp client In-Reply-To: References: Message-ID: <576CE5E2.5070302@redhat.com> Hi, Make sure that this pom for jbosstools-openshift gets updated to include/remove necessary dependencies when it starts consuming this new version org openshift-restclient-java: https://github.com/jbosstools/jbosstools-openshift/blob/master/plugins/org.jboss.tools.openshift.client/pom.xml#L47 By the way, I can see that it includes libraries that are already part of the target-platform and that could be replaced by requirements in MANIFEST.MF. It might be worth considering reusing libs from target-platforms than including copies of it (however, it's not something high priority IMO). Cheers, -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160624/299ec22f/attachment.html From xcoulon at redhat.com Fri Jun 24 04:46:38 2016 From: xcoulon at redhat.com (Xavier Coulon) Date: Fri, 24 Jun 2016 10:46:38 +0200 Subject: [jbosstools-dev] Intention to remove "Server Log View" In-Reply-To: References: Message-ID: <9F37AFD9-7876-44EC-87E8-379C767BFE5C@redhat.com> +1, I'd rather have everything in a single view. (Error Log) /Xavier > On 23 Jun 2016, at 05:05, Robert Stryker wrote: > > Hey all: > > https://issues.jboss.org/browse/JBIDE-22635 > > The Server Log View had a pretty complicated API, meant to look like the Error Log View, but with some additional mechanisms for sorting the events or providing icons for the various events. > > In all honesty, it was poorly-conceived from the beginning. Anything that should be logged there should really be logged in the error-log view anyway, so other than that, it's only useful feature was more of a tracing / logging mechanism that would be less annoying to the user. > > In fact, it's been found to have been used less often than it should be, and used inconsistantly. As far as I can tell, no other plugins other than AS Tools are using it, and some other server adapters have requested the action be removed (since they're not using the API to log events, it's basically useless to them). > > Anyway, I think it'd make the most sense to remove it. I don't think it's saveable really ;) > > Any thoughts or objections? > > - Rob > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160624/f6940a62/attachment.html From manderse at redhat.com Fri Jun 24 09:48:34 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Fri, 24 Jun 2016 15:48:34 +0200 Subject: [jbosstools-dev] closed freemarker issues Message-ID: <64700995-F4B0-43F9-BFDA-4708E74A3690@redhat.com> Hey, I started to see more and more freemarker issues being open on github despite the readme says to use https://jira.jboss.org/jira/browse/JBIDE. I wanted to leave a comment on the issues that bugs should be open on JBIDE, but before that I just tried to click the "Enable issues" checkbox on github and surprise: github nukes the issues instantly ;/ That was not supposed to happen. Wanted to give a headsup first. Anyways, in short - freemarker repo is now like others that pull-request is open and bugs goes to the relevant component in jira. Paul - sorry for nuking the issues ;/ but please use https://jira.jboss.org/jira/browse/JBIDE for freemarker work. /max http://about.me/maxandersen From fbricon at redhat.com Fri Jun 24 10:18:06 2016 From: fbricon at redhat.com (Fred Bricon) Date: Fri, 24 Jun 2016 10:18:06 -0400 Subject: [jbosstools-dev] Intention to remove "Server Log View" In-Reply-To: <9F37AFD9-7876-44EC-87E8-379C767BFE5C@redhat.com> References: <9F37AFD9-7876-44EC-87E8-379C767BFE5C@redhat.com> Message-ID: +1 to remove it On Fri, Jun 24, 2016 at 4:46 AM, Xavier Coulon wrote: > +1, I'd rather have everything in a single view. (Error Log) > > /Xavier > > On 23 Jun 2016, at 05:05, Robert Stryker wrote: > > Hey all: > > https://issues.jboss.org/browse/JBIDE-22635 > > The Server Log View had a pretty complicated API, meant to look like the > Error Log View, but with some additional mechanisms for sorting the events > or providing icons for the various events. > > In all honesty, it was poorly-conceived from the beginning. Anything that > should be logged there should really be logged in the error-log view > anyway, so other than that, it's only useful feature was more of a tracing > / logging mechanism that would be less annoying to the user. > > In fact, it's been found to have been used less often than it should be, > and used inconsistantly. As far as I can tell, no other plugins other than > AS Tools are using it, and some other server adapters have requested the > action be removed (since they're not using the API to log events, it's > basically useless to them). > > Anyway, I think it'd make the most sense to remove it. I don't think it's > saveable really ;) > > Any thoughts or objections? > > - Rob > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160624/6d6b93f0/attachment.html From alkazako at redhat.com Fri Jun 24 10:56:12 2016 From: alkazako at redhat.com (Alexey Kazakov) Date: Fri, 24 Jun 2016 10:56:12 -0400 Subject: [jbosstools-dev] Intention to remove "Server Log View" In-Reply-To: References: <9F37AFD9-7876-44EC-87E8-379C767BFE5C@redhat.com> Message-ID: <576D4A0C.6020507@redhat.com> +1 to remove it. But should be careful with any public API we expose. Especially when we are talking about plugins like server and base. So let's deprecate it first, then remove. On 06/24/2016 10:18 AM, Fred Bricon wrote: > +1 to remove it > > On Fri, Jun 24, 2016 at 4:46 AM, Xavier Coulon > wrote: > > +1, I'd rather have everything in a single view. (Error Log) > > /Xavier > >> On 23 Jun 2016, at 05:05, Robert Stryker > > wrote: >> >> Hey all: >> >> https://issues.jboss.org/browse/JBIDE-22635 >> >> The Server Log View had a pretty complicated API, meant to look >> like the Error Log View, but with some additional mechanisms for >> sorting the events or providing icons for the various events. >> >> In all honesty, it was poorly-conceived from the beginning. >> Anything that should be logged there should really be logged in >> the error-log view anyway, so other than that, it's only useful >> feature was more of a tracing / logging mechanism that would be >> less annoying to the user. >> >> In fact, it's been found to have been used less often than it >> should be, and used inconsistantly. As far as I can tell, no >> other plugins other than AS Tools are using it, and some other >> server adapters have requested the action be removed (since >> they're not using the API to log events, it's basically useless >> to them). >> >> Anyway, I think it'd make the most sense to remove it. I don't >> think it's saveable really ;) >> >> Any thoughts or objections? >> >> - Rob >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160624/3220089e/attachment.html From manderse at redhat.com Sun Jun 26 05:11:12 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Sun, 26 Jun 2016 11:11:12 +0200 Subject: [jbosstools-dev] Refactoring openshift-restclient-java to depend upon OkHttp client In-Reply-To: References: Message-ID: <47E757A6-D47F-46D7-A422-EEC35D41164A@redhat.com> > The current release of the openshift-restclient-java, for not so > obvious > reasons, depends on no less then 3 libraries to provide the underlying > communication to the cluster server. The following PR > https://github.com/openshift/openshift-restclient-java/pull/179 > unifies > this dependency to a single client which is based on OkHttp. We are > looking to make this change to: > > * Provide a common way to make REST calls > * Simplify the authorization semantics to an openshift cluster > * Simplify the pattern of making REST calls over what is done today > * In future, take advantage of its SPDY support to move away from the > oc > binary dependency > * Put us in a better position to move to the Fabric8 client (if that > ever > happens) > > Any comments or objects are welcome 0) "In future" about SPDY - what does that mean ? Can OKhttp already talk with SPDY on Java 8 without changing the bootclasspath ? 1) did you look at the work Stuart Douglas did ? (see mail thread: "ALPN in Java") Would that be a better option for SPDY ? That would work for Java 8 at least. 2) will this integrate with use of proxy settings etc. configured in Eclipse ? that is what ECF today does for normal http URL connections, if you are using a separate library my guess is that it is ignoring proxy and other auth setup done in eclipse, but I could be wrong. /max /max http://about.me/maxandersen From jmaury at redhat.com Sun Jun 26 11:53:21 2016 From: jmaury at redhat.com (Jean-Francois Maury) Date: Sun, 26 Jun 2016 17:53:21 +0200 Subject: [jbosstools-dev] Refactoring openshift-restclient-java to depend upon OkHttp client In-Reply-To: <47E757A6-D47F-46D7-A422-EEC35D41164A@redhat.com> References: <47E757A6-D47F-46D7-A422-EEC35D41164A@redhat.com> Message-ID: SPDY is really a target ? I thought HTTP/2 is the future. Jeff On Sun, Jun 26, 2016 at 11:11 AM, Max Rydahl Andersen wrote: > > > The current release of the openshift-restclient-java, for not so > > obvious > > reasons, depends on no less then 3 libraries to provide the underlying > > communication to the cluster server. The following PR > > https://github.com/openshift/openshift-restclient-java/pull/179 > > unifies > > this dependency to a single client which is based on OkHttp. We are > > looking to make this change to: > > > > * Provide a common way to make REST calls > > * Simplify the authorization semantics to an openshift cluster > > * Simplify the pattern of making REST calls over what is done today > > * In future, take advantage of its SPDY support to move away from the > > oc > > binary dependency > > * Put us in a better position to move to the Fabric8 client (if that > > ever > > happens) > > > > Any comments or objects are welcome > > 0) "In future" about SPDY - what does that mean ? Can OKhttp already > talk with SPDY > on Java 8 without changing the bootclasspath ? > > 1) did you look at the work Stuart Douglas did ? (see mail thread: "ALPN > in Java") > Would that be a better option for SPDY ? That would work for Java 8 > at least. > > 2) will this integrate with use of proxy settings etc. configured in > Eclipse ? > that is what ECF today does for normal http URL connections, if you > are using > a separate library my guess is that it is ignoring proxy and other > auth setup > done in eclipse, but I could be wrong. > > /max > > > /max > http://about.me/maxandersen > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160626/667f860a/attachment-0001.html From aer-bot at ctrlflow.com Sun Jun 26 23:30:00 2016 From: aer-bot at ctrlflow.com (Automated Error Reporting Bot) Date: Mon, 27 Jun 2016 03:30:00 +0000 (UTC) Subject: [jbosstools-dev] [aeri] Weekly JBoss Tools Error Reports Digest Message-ID: <302446880.12.1466998200787.JavaMail.ec2-user@aeri-rh> An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160627/c212047a/attachment-0001.html From manderse at redhat.com Mon Jun 27 06:40:28 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Mon, 27 Jun 2016 12:40:28 +0200 Subject: [jbosstools-dev] Refactoring openshift-restclient-java to depend upon OkHttp client In-Reply-To: References: <47E757A6-D47F-46D7-A422-EEC35D41164A@redhat.com> Message-ID: <634D26B5-5EC2-493F-81CC-1B59833903F0@redhat.com> On 26 Jun 2016, at 17:53, Jean-Francois Maury wrote: > SPDY is really a target ? I thought HTTP/2 is the future. Yes, but right now SPDY is what OpenShift uses - but yeah, in future its probably full http/2 which its why I ask about #0 and #1 /max > > Jeff > > On Sun, Jun 26, 2016 at 11:11 AM, Max Rydahl Andersen > wrote: > >> >>> The current release of the openshift-restclient-java, for not so >>> obvious >>> reasons, depends on no less then 3 libraries to provide the underlying >>> communication to the cluster server. The following PR >>> https://github.com/openshift/openshift-restclient-java/pull/179 >>> unifies >>> this dependency to a single client which is based on OkHttp. We are >>> looking to make this change to: >>> >>> * Provide a common way to make REST calls >>> * Simplify the authorization semantics to an openshift cluster >>> * Simplify the pattern of making REST calls over what is done today >>> * In future, take advantage of its SPDY support to move away from the >>> oc >>> binary dependency >>> * Put us in a better position to move to the Fabric8 client (if that >>> ever >>> happens) >>> >>> Any comments or objects are welcome >> >> 0) "In future" about SPDY - what does that mean ? Can OKhttp already >> talk with SPDY >> on Java 8 without changing the bootclasspath ? >> >> 1) did you look at the work Stuart Douglas did ? (see mail thread: "ALPN >> in Java") >> Would that be a better option for SPDY ? That would work for Java 8 >> at least. >> >> 2) will this integrate with use of proxy settings etc. configured in >> Eclipse ? >> that is what ECF today does for normal http URL connections, if you >> are using >> a separate library my guess is that it is ignoring proxy and other >> auth setup >> done in eclipse, but I could be wrong. >> >> /max >> >> >> /max >> http://about.me/maxandersen >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> /max http://about.me/maxandersen From jcantril at redhat.com Mon Jun 27 07:55:26 2016 From: jcantril at redhat.com (Jeff Cantrill) Date: Mon, 27 Jun 2016 07:55:26 -0400 Subject: [jbosstools-dev] Refactoring openshift-restclient-java to depend upon OkHttp client In-Reply-To: <47E757A6-D47F-46D7-A422-EEC35D41164A@redhat.com> References: <47E757A6-D47F-46D7-A422-EEC35D41164A@redhat.com> Message-ID: On Sun, Jun 26, 2016 at 5:11 AM, Max Rydahl Andersen wrote: > > The current release of the openshift-restclient-java, for not so obvious >> reasons, depends on no less then 3 libraries to provide the underlying >> communication to the cluster server. The following PR >> https://github.com/openshift/openshift-restclient-java/pull/179 unifies >> this dependency to a single client which is based on OkHttp. We are >> looking to make this change to: >> >> * Provide a common way to make REST calls >> * Simplify the authorization semantics to an openshift cluster >> * Simplify the pattern of making REST calls over what is done today >> * In future, take advantage of its SPDY support to move away from the oc >> binary dependency >> * Put us in a better position to move to the Fabric8 client (if that ever >> happens) >> >> Any comments or objects are welcome >> > > 0) "In future" about SPDY - what does that mean ? Can OKhttp already talk > with SPDY > on Java 8 without changing the bootclasspath ? > > This client already supports both SPDY and HTTP/2. I plan to do further tests to verify what can be done with the SPDY support but implementing puts us in no worse of a position now IMO. > 1) did you look at the work Stuart Douglas did ? (see mail thread: "ALPN > in Java") > Would that be a better option for SPDY ? That would work for Java 8 at > least. > I think if we EVER anticipate unifying a client with fabric8 our best option is to start with dependency on some of the libraries they use. OkHttp has SPDY support which I believe is just a matter of understanding what we can do with it. At a minimum, this library is significantly easier IMO to use then either jetty, apache client, or the home grown client we were using. > 2) will this integrate with use of proxy settings etc. configured in > Eclipse ? > that is what ECF today does for normal http URL connections, if you are > using > a separate library my guess is that it is ignoring proxy and other auth > setup > done in eclipse, but I could be wrong. > > It has proxy support as well. I will add that to my check list of items to verify. > /max > > > /max > http://about.me/maxandersen > -- -- Jeff Cantrill Senior Software Engineer, Red Hat Engineering OpenShift Integration Services Red Hat, Inc. *Office*: 703-748-4420 | 866-546-8970 ext. 8162420 jcantril at redhat.com http://www.redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160627/f6bacea7/attachment.html From manderse at redhat.com Mon Jun 27 08:01:10 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Mon, 27 Jun 2016 14:01:10 +0200 Subject: [jbosstools-dev] Refactoring openshift-restclient-java to depend upon OkHttp client In-Reply-To: References: <47E757A6-D47F-46D7-A422-EEC35D41164A@redhat.com> Message-ID: On 27 Jun 2016, at 13:55, Jeff Cantrill wrote: > On Sun, Jun 26, 2016 at 5:11 AM, Max Rydahl Andersen > > wrote: > >> >> The current release of the openshift-restclient-java, for not so >> obvious >>> reasons, depends on no less then 3 libraries to provide the >>> underlying >>> communication to the cluster server. The following PR >>> https://github.com/openshift/openshift-restclient-java/pull/179 >>> unifies >>> this dependency to a single client which is based on OkHttp. We are >>> looking to make this change to: >>> >>> * Provide a common way to make REST calls >>> * Simplify the authorization semantics to an openshift cluster >>> * Simplify the pattern of making REST calls over what is done today >>> * In future, take advantage of its SPDY support to move away from >>> the oc >>> binary dependency >>> * Put us in a better position to move to the Fabric8 client (if that >>> ever >>> happens) >>> >>> Any comments or objects are welcome >>> >> >> 0) "In future" about SPDY - what does that mean ? Can OKhttp already >> talk >> with SPDY >> on Java 8 without changing the bootclasspath ? >> >> This client already supports both SPDY and HTTP/2. I plan to do >> further > tests to verify what can be done with the SPDY support but > implementing > puts us in no worse of a position now IMO. How does it support it ? If it requires changing the bootclasspath it is not going to work anyway. >> 1) did you look at the work Stuart Douglas did ? (see mail thread: >> "ALPN >> in Java") >> Would that be a better option for SPDY ? That would work for Java >> 8 at >> least. >> > > I think if we EVER anticipate unifying a client with fabric8 our best > option is to start with dependency on some of the libraries they use. > OkHttp has SPDY support which I believe is just a matter of > understanding > what we can do with it. At a minimum, this library is significantly > easier > IMO to use then either jetty, apache client, or the home grown client > we > were using. okey, but that does not matter if this library requires changing bootclasspath when using Java 8. >> 2) will this integrate with use of proxy settings etc. configured in >> Eclipse ? >> that is what ECF today does for normal http URL connections, if >> you are >> using >> a separate library my guess is that it is ignoring proxy and other >> auth >> setup >> done in eclipse, but I could be wrong. >> >> It has proxy support as well. I will add that to my check list of >> items > to verify. Okey, but without that I would say its a nogo since we had more than a big share of issues in past of users having to configure proxies to use openshift and the "fix" for that was users to setup proxies in eclipse. Btw. it is probably possible to add that support but something that should be part of being fixed before including in a release. /max http://about.me/maxandersen From davidmichaelkarr at gmail.com Mon Jun 27 11:23:51 2016 From: davidmichaelkarr at gmail.com (David M. Karr) Date: Mon, 27 Jun 2016 08:23:51 -0700 Subject: [jbosstools-dev] Work with remote container(s)? Message-ID: <57714507.50107@gmail.com> I'm still mostly a Docker beginner, and I just viewed the Docker Tools recorded video. Two related questions: Will it be possible to have the Docker Tooling work with a remote container (not on localhost)? Will it be possible to integrate with Docker Swarm? The latter is likely an academic issue, but perhaps not the former. From alkazako at redhat.com Mon Jun 27 18:24:45 2016 From: alkazako at redhat.com (Alexey Kazakov) Date: Mon, 27 Jun 2016 18:24:45 -0400 Subject: [jbosstools-dev] JBoss Developer Studio 10.0.GA is available Message-ID: <5771A7AD.4060005@redhat.com> JBoss Developer Studio 10.0.GA is available! Download page: https://www.jboss.org/products/devstudio/overview/ Update site: https://devstudio.redhat.com/10.0/stable/updates/ Eclipse Marketplace: https://marketplace.eclipse.org/node/1616973 Blog Announcement: http://tools.jboss.org/blog/ga-for-neon.html New + Noteworthy: http://tools.jboss.org/documentation/whatsnew/jbosstools/4.4.0.Final.html -- Schedule / Upcoming Releases: https://issues.jboss.org/projects/JBDS?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page From alkazako at redhat.com Mon Jun 27 18:29:20 2016 From: alkazako at redhat.com (Alexey Kazakov) Date: Mon, 27 Jun 2016 18:29:20 -0400 Subject: [jbosstools-dev] JBoss Tools 4.4.0.Final is now available Message-ID: <5771A8C0.7010005@redhat.com> This is final release aimed at Eclipse Neon users. Announcement Blog: http://tools.jboss.org/blog/ga-for-neon.html Eclipse Marketplace: https://marketplace.eclipse.org/node/1617241 Update Site: http://download.jboss.org/jbosstools/neon/stable/updates/ Zips: http://tools.jboss.org/downloads/jbosstools/neon/4.4.0.Final.html#zips Installation instructions: http://tools.jboss.org/downloads/installation.html New + Noteworthy (subject to change): http://tools.jboss.org/documentation/whatsnew/jbosstools/4.4.0.Final.html Schedule / Upcoming Releases: https://issues.jboss.org/projects/JBIDE?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page From xcoulon at redhat.com Tue Jun 28 03:39:20 2016 From: xcoulon at redhat.com (Xavier Coulon) Date: Tue, 28 Jun 2016 09:39:20 +0200 Subject: [jbosstools-dev] Work with remote container(s)? In-Reply-To: <57714507.50107@gmail.com> References: <57714507.50107@gmail.com> Message-ID: <5D333CEF-D8A7-4755-ACC1-A1B2ADD0B875@redhat.com> Hello David, Yes, you can also set a connection to a Docker daemon running on a remote machine, as long as you have all the settings to connect to it (the connection wizard will not provide any suggestion for this). You'll need the ip/port to open the socket to the daemon and maybe a copy of the client certificates if authentication is enabled. Please let us know if you have any trouble with that. As far as Docker Swarm is concerned, we don't have any plan for it yet, but I encourage you to open a RFE on https://bugs.eclipse.org/ (select the 'Linux Tools' project and then the 'Docker' component) if this is something you want to see in the future. Best regards, Xavier > On 27 Jun 2016, at 17:23, David M. Karr wrote: > > I'm still mostly a Docker beginner, and I just viewed the Docker Tools > recorded video. > > Two related questions: > > Will it be possible to have the Docker Tooling work with a remote > container (not on localhost)? > > Will it be possible to integrate with Docker Swarm? > > The latter is likely an academic issue, but perhaps not the former. > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev From manderse at redhat.com Tue Jun 28 06:00:30 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Tue, 28 Jun 2016 12:00:30 +0200 Subject: [jbosstools-dev] Work with remote container(s)? In-Reply-To: <57714507.50107@gmail.com> References: <57714507.50107@gmail.com> Message-ID: <4E918C09-5091-490F-A6F3-553D76E1ADCD@redhat.com> On 27 Jun 2016, at 17:23, David M. Karr wrote: > I'm still mostly a Docker beginner, and I just viewed the Docker Tools > recorded video. > > Two related questions: > > Will it be possible to have the Docker Tooling work with a remote > container (not on localhost)? It is possible today. Just put in the host/port info info the connection dialog. > Will it be possible to integrate with Docker Swarm? Not sure what it would imply, but I can say that if you use docker compose or swarm they will just talk with docker deamons and the docker tooling will see/interact with those docker containers. btw. better forum for user questions is on https://developer.jboss.org/en/tools/content?filterID=contentstatus[published]~objecttype~objecttype[thread] this list is more for question about development of jboss tools, not of its usage. /max http://about.me/maxandersen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160628/8301a99f/attachment.html From alkazako at redhat.com Tue Jun 28 16:04:29 2016 From: alkazako at redhat.com (Alexey Kazakov) Date: Tue, 28 Jun 2016 16:04:29 -0400 Subject: [jbosstools-dev] CI jobs building PR In-Reply-To: <576A699B.70408@redhat.com> References: <5769649C.7050308@redhat.com> <1466572734.3220.5.camel@redhat.com> <576A22B0.5090104@redhat.com> <576A572B.3030105@redhat.com> <576A699B.70408@redhat.com> Message-ID: <5772D84D.7080807@redhat.com> Hi Mickael, There was a PR [1] in jst repo. Rick Wagner, the author of the PR is not a member of JBoss Tools organization (I sent him an invitation). So I used "testPR" to trigger the test build. The job was started [2] but it looks like the user used in the job doesn't have write access to jst. [1] https://github.com/jbosstools/jbosstools-jst/pull/566 https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/DevStudio-Pull-Requests/job/jbosstools-jst-Pull-Request/6/console On 06/22/2016 06:34 AM, Mickael Istria wrote: > On 06/22/2016 12:28 PM, Jean-Francois Maury wrote: >> Did it get relaunched when the PR is updated ? > If it's updated by someone who's whitelisted (member of JBoss Tools > organization on GitHub), then yes, it should be relaunched > automatically. If it's from someone external, I believe someone has to > say "testPR" to relaunch. > On the GitHub PR, you can click on the "Show details" link for the > build. It will drive you to Jenkins and on Jenkins you get access to > more metadata such as the commitId that was built. > > HTH > -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat > My blog - My Tweets > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160628/66bf9c45/attachment.html From mistria at redhat.com Tue Jun 28 16:15:24 2016 From: mistria at redhat.com (Mickael Istria) Date: Tue, 28 Jun 2016 22:15:24 +0200 Subject: [jbosstools-dev] CI jobs building PR In-Reply-To: <5772D84D.7080807@redhat.com> References: <5769649C.7050308@redhat.com> <1466572734.3220.5.camel@redhat.com> <576A22B0.5090104@redhat.com> <576A572B.3030105@redhat.com> <576A699B.70408@redhat.com> <5772D84D.7080807@redhat.com> Message-ID: On 06/28/2016 10:04 PM, Alexey Kazakov wrote: > Hi Mickael, Hi, > There was a PR [1] in jst repo. Rick Wagner, the author of the PR is > not a member of JBoss Tools organization (I sent him an invitation). > So I used "testPR" to trigger the test build. > The job was started [2] but it looks like the user used in the job > doesn't have write access to jst. > > [1] https://github.com/jbosstools/jbosstools-jst/pull/566 > https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/DevStudio-Pull-Requests/job/jbosstools-jst-Pull-Request/6/console The GitHub user "rhdevelopers-ci" (https://github.com/rhdevelopers-ci) needs to be added to the members of the jbosstools-jst project. See configuration of jbosstools-openshift members for example https://github.com/jbosstools/jbosstools-openshift/settings/collaboration . HTH -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160628/d16d85c0/attachment.html From alkazako at redhat.com Tue Jun 28 16:16:02 2016 From: alkazako at redhat.com (Alexey Kazakov) Date: Tue, 28 Jun 2016 16:16:02 -0400 Subject: [jbosstools-dev] CI jobs building PR In-Reply-To: References: <5769649C.7050308@redhat.com> <1466572734.3220.5.camel@redhat.com> <576A22B0.5090104@redhat.com> <576A572B.3030105@redhat.com> <576A699B.70408@redhat.com> <5772D84D.7080807@redhat.com> Message-ID: <5772DB02.9080005@redhat.com> Ah, sorry, mixed up two rwagner's ;) Rick you should start creating PRs too! On 06/28/2016 04:13 PM, Rick Wagner wrote: > Hi All, > > I'm sorry, but I can't take credit for that Pull Request. (It's most > likely Radislav Wagner, I think from QE). > > Thanks, > > Rick > > On Tue, Jun 28, 2016 at 3:04 PM, Alexey Kazakov > wrote: > > Hi Mickael, > > There was a PR [1] in jst repo. Rick Wagner, the author of the PR > is not a member of JBoss Tools organization (I sent him an > invitation). So I used "testPR" to trigger the test build. > The job was started [2] but it looks like the user used in the job > doesn't have write access to jst. > > [1] https://github.com/jbosstools/jbosstools-jst/pull/566 > https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/DevStudio-Pull-Requests/job/jbosstools-jst-Pull-Request/6/console > > On 06/22/2016 06:34 AM, Mickael Istria wrote: >> On 06/22/2016 12:28 PM, Jean-Francois Maury wrote: >>> Did it get relaunched when the PR is updated ? >> If it's updated by someone who's whitelisted (member of JBoss >> Tools organization on GitHub), then yes, it should be relaunched >> automatically. If it's from someone external, I believe someone >> has to say "testPR" to relaunch. >> On the GitHub PR, you can click on the "Show details" link for >> the build. It will drive you to Jenkins and on Jenkins you get >> access to more metadata such as the commitId that was built. >> >> HTH >> -- >> Mickael Istria >> Eclipse developer at JBoss, by Red Hat >> My blog - My Tweets >> >> >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160628/ec0b7e90/attachment.html From alkazako at redhat.com Tue Jun 28 16:20:02 2016 From: alkazako at redhat.com (Alexey Kazakov) Date: Tue, 28 Jun 2016 16:20:02 -0400 Subject: [jbosstools-dev] CI jobs building PR In-Reply-To: References: <5769649C.7050308@redhat.com> <1466572734.3220.5.camel@redhat.com> <576A22B0.5090104@redhat.com> <576A572B.3030105@redhat.com> <576A699B.70408@redhat.com> <5772D84D.7080807@redhat.com> Message-ID: <5772DBF2.6030805@redhat.com> On 06/28/2016 04:15 PM, Mickael Istria wrote: > On 06/28/2016 10:04 PM, Alexey Kazakov wrote: >> Hi Mickael, > Hi, >> There was a PR [1] in jst repo. Rick Wagner, the author of the PR is >> not a member of JBoss Tools organization (I sent him an invitation). >> So I used "testPR" to trigger the test build. >> The job was started [2] but it looks like the user used in the job >> doesn't have write access to jst. >> >> [1] https://github.com/jbosstools/jbosstools-jst/pull/566 >> https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/DevStudio-Pull-Requests/job/jbosstools-jst-Pull-Request/6/console > The GitHub user "rhdevelopers-ci" (https://github.com/rhdevelopers-ci) > needs to be added to the members of the jbosstools-jst project. See > configuration of jbosstools-openshift members for example > https://github.com/jbosstools/jbosstools-openshift/settings/collaboration > . It was already a member of JST (via "bot" team) but the "bot" team didn't have write access. I fixed that. Thanks! > HTH > -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat > My blog - My Tweets > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160628/5682b3ac/attachment-0001.html From alkazako at redhat.com Tue Jun 28 16:24:54 2016 From: alkazako at redhat.com (Alexey Kazakov) Date: Tue, 28 Jun 2016 16:24:54 -0400 Subject: [jbosstools-dev] CI jobs building PR In-Reply-To: <5772DBF2.6030805@redhat.com> References: <5769649C.7050308@redhat.com> <1466572734.3220.5.camel@redhat.com> <576A22B0.5090104@redhat.com> <576A572B.3030105@redhat.com> <576A699B.70408@redhat.com> <5772D84D.7080807@redhat.com> <5772DBF2.6030805@redhat.com> Message-ID: <5772DD16.3030506@redhat.com> Actually half of our repos didn't have this set up properly. Fixed now. On 06/28/2016 04:20 PM, Alexey Kazakov wrote: > > > On 06/28/2016 04:15 PM, Mickael Istria wrote: >> On 06/28/2016 10:04 PM, Alexey Kazakov wrote: >>> Hi Mickael, >> Hi, >>> There was a PR [1] in jst repo. Rick Wagner, the author of the PR is >>> not a member of JBoss Tools organization (I sent him an invitation). >>> So I used "testPR" to trigger the test build. >>> The job was started [2] but it looks like the user used in the job >>> doesn't have write access to jst. >>> >>> [1] https://github.com/jbosstools/jbosstools-jst/pull/566 >>> https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/DevStudio-Pull-Requests/job/jbosstools-jst-Pull-Request/6/console >> The GitHub user "rhdevelopers-ci" >> (https://github.com/rhdevelopers-ci) needs to be added to the members >> of the jbosstools-jst project. See configuration of >> jbosstools-openshift members for example >> https://github.com/jbosstools/jbosstools-openshift/settings/collaboration >> . > > It was already a member of JST (via "bot" team) but the "bot" team > didn't have write access. I fixed that. > Thanks! > >> HTH >> -- >> Mickael Istria >> Eclipse developer at JBoss, by Red Hat >> My blog - My Tweets >> >> >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160628/9961aba7/attachment.html From rwagner at redhat.com Tue Jun 28 16:13:46 2016 From: rwagner at redhat.com (Rick Wagner) Date: Tue, 28 Jun 2016 15:13:46 -0500 Subject: [jbosstools-dev] CI jobs building PR In-Reply-To: <5772D84D.7080807@redhat.com> References: <5769649C.7050308@redhat.com> <1466572734.3220.5.camel@redhat.com> <576A22B0.5090104@redhat.com> <576A572B.3030105@redhat.com> <576A699B.70408@redhat.com> <5772D84D.7080807@redhat.com> Message-ID: Hi All, I'm sorry, but I can't take credit for that Pull Request. (It's most likely Radislav Wagner, I think from QE). Thanks, Rick On Tue, Jun 28, 2016 at 3:04 PM, Alexey Kazakov wrote: > Hi Mickael, > > There was a PR [1] in jst repo. Rick Wagner, the author of the PR is not a > member of JBoss Tools organization (I sent him an invitation). So I used > "testPR" to trigger the test build. > The job was started [2] but it looks like the user used in the job doesn't > have write access to jst. > > [1] https://github.com/jbosstools/jbosstools-jst/pull/566 > > https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/DevStudio-Pull-Requests/job/jbosstools-jst-Pull-Request/6/console > > On 06/22/2016 06:34 AM, Mickael Istria wrote: > > On 06/22/2016 12:28 PM, Jean-Francois Maury wrote: > > Did it get relaunched when the PR is updated ? > > If it's updated by someone who's whitelisted (member of JBoss Tools > organization on GitHub), then yes, it should be relaunched automatically. > If it's from someone external, I believe someone has to say "testPR" to > relaunch. > On the GitHub PR, you can click on the "Show details" link for the build. > It will drive you to Jenkins and on Jenkins you get access to more metadata > such as the commitId that was built. > > HTH > -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat > My blog - My Tweets > > > > _______________________________________________ > jbosstools-dev mailing listjbosstools-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160628/f98d646a/attachment.html From nboldt at redhat.com Wed Jun 29 20:17:22 2016 From: nboldt at redhat.com (Nick Boldt) Date: Wed, 29 Jun 2016 20:17:22 -0400 Subject: [jbosstools-dev] Migration to jgit timestamps Message-ID: (Previously, on "migrating to jgit timestamps"...) Instead of a BUILD_ALIAS like Alpha1 or Beta1, which forces users to download a whole JBT or devstudio install each time we release a new milestone, plugins and features will soon use the timestamp of their last change in github. Note that two plugins will continue to have a BUILD_ALIAS applied: foundation.core & devstudio.core.central, which define the version of JBoss Tools / devstudio used by ide-config.properties to assign the correct URLs for Central and quickstarts. But as you may have seen in another thread, we are now using milestone numbers instead of quality labels like Alpha or Beta. These milestones will be called AM1, AM2, AM3, because we need a letter that's ascii-wise a lower value that Final & GA. Previously, I had said that you need to *check in your local changes* (to your local github clone, not to origin!) in order to ensure that those local changes are seen as "newer" than the stuff available on download.jboss.org, or in your ~/.m2/repo. This is no longer true -- a dirty github workspace will still result in upversioned plugin timestamps. I believe this should even work across timezones, since the plugins I built appear to be timestamped in GMT, not EST. Anyway, thanks for reading this far. The PRs in JBIDE-13671 have been applied, and fresh CI builds should be available tomorrow. Ref: https://issues.jboss.org/browse/JBIDE-13671 -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com From manderse at redhat.com Thu Jun 30 11:34:41 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Thu, 30 Jun 2016 17:34:41 +0200 Subject: [jbosstools-dev] Migration to jgit timestamps In-Reply-To: References: Message-ID: <6A20FF77-DC9A-439D-8FC2-B6264D019AF7@redhat.com> On 30 Jun 2016, at 2:17, Nick Boldt wrote: > (Previously, on "migrating to jgit timestamps"...) > > Instead of a BUILD_ALIAS like Alpha1 or Beta1, which forces users to > download a whole JBT or devstudio install each time we release a new > milestone, plugins and features will soon use the timestamp of their > last change in github. > > Note that two plugins will continue to have a BUILD_ALIAS applied: > foundation.core & devstudio.core.central, which define the version of > JBoss > Tools / devstudio used by ide-config.properties to assign the correct > URLs for Central and quickstarts. Just realised - this won't just be needed on the plugins, but also needed to be reflected on the feature, right ? P2 won't update individual plugins afaik unless the feature providing them bump too. This might already be handed by tycho's jgit mechanism but just wanted to be sure we didn't state it was just for the plugin if it also includes the feature and all up to whatever product feature. > This is no longer true -- a dirty github workspace will still result > in upversioned plugin timestamps. I believe this should even work > across timezones, since the plugins I built appear to be timestamped > in GMT, not EST. so you removed the need for doing git commits for local testing ? great! > Anyway, thanks for reading this far. The PRs in JBIDE-13671 have been > applied, and fresh CI builds should be available tomorrow. > > Ref: https://issues.jboss.org/browse/JBIDE-13671 crossing fingers it will work - will definitely be nice seeing only actual changed updates in future. /max http://about.me/maxandersen From mistria at redhat.com Thu Jun 30 11:48:25 2016 From: mistria at redhat.com (Mickael Istria) Date: Thu, 30 Jun 2016 17:48:25 +0200 Subject: [jbosstools-dev] Migration to jgit timestamps In-Reply-To: <6A20FF77-DC9A-439D-8FC2-B6264D019AF7@redhat.com> References: <6A20FF77-DC9A-439D-8FC2-B6264D019AF7@redhat.com> Message-ID: On 06/30/2016 05:34 PM, Max Rydahl Andersen wrote: > This might already be handed by tycho's jgit mechanism but just wanted > to be sure we didn't state it was just for the plugin if it also > includes > the feature and all up to whatever product feature. Yeah, see https://wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers#Feature_version_qualifiers -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160630/cf2a1b36/attachment.html From nboldt at redhat.com Thu Jun 30 12:20:58 2016 From: nboldt at redhat.com (Nick Boldt) Date: Thu, 30 Jun 2016 12:20:58 -0400 Subject: [jbosstools-dev] Migration to jgit timestamps In-Reply-To: References: <6A20FF77-DC9A-439D-8FC2-B6264D019AF7@redhat.com> Message-ID: Or look at the examples I posted on the JIRA [1] . Because features/com.jboss.devstudio.core.feature/feature.xml contains therefore its version is bumped to a newer timestamp every time we edit anything in com.jboss.devstudio.core.central or cause a new version to be produced. [1] https://issues.jboss.org/browse/JBIDE-13671?focusedCommentId=13259284&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13259284 On Thu, Jun 30, 2016 at 11:48 AM, Mickael Istria wrote: > On 06/30/2016 05:34 PM, Max Rydahl Andersen wrote: > > This might already be handed by tycho's jgit mechanism but just wanted > > to be sure we didn't state it was just for the plugin if it also > includes > the feature and all up to whatever product feature. > > Yeah, see > https://wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers#Feature_version_qualifiers > > -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat > My blog - My Tweets > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com