April 2017 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-23017) use sshfs to speed up publishing process

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23017?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-23017: ------------------------------- Fix Version/s: 4.4.4.AM3 (was: 4.4.4.AM2) > use sshfs to speed up publishing process > ----------------------------------------- > > Key: JBIDE-23017 > URL: https://issues.jboss.org/browse/JBIDE-23017 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: build > Affects Versions: 4.4.1.AM3 > Reporter: Nick Boldt > Assignee: Nick Boldt > Labels: releasework > Fix For: 4.4.4.AM3, 4.4.4.Final > > Attachments: staging-times.png > > > Currently, publishing from /snapshots to /staging and from /staging to /development requires that we fetch several GBs of data from filemgmt.jboss.org to a temp folder, then push those bits to a new folder on filemgmt.jboss.org. > If we could simply copy bits over sshfs, the process might be a lot faster than these times: > {code} > JBT coretests 1.1G: 59m20 > JBT core 1.2G: 64m23 > devstudio (copy from filemgmt to filemgmt) 2.4G: 2h13 > devstudio (copy from local to www.qa) 3.1G: 6mins(?) > {code} > To make this work, however, we need more slaves to have sshfs installed. Currently, it appears that only dev01 [1] is so equipped. And that slave, currently, has a build queue more than 170 jobs long, making it impractical to even TEST publishing over sshfs. > [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/computer/dev01-rhel5-x86/ -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-23017) use sshfs to speed up publishing process

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23017?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-23017: ------------------------------------ Stats collected for AM2 release. Looks reasonable. https://docs.google.com/spreadsheets/d/1T-QBqznq_0CySe4bDvIFYrws-FA1HhcS8... > use sshfs to speed up publishing process > ----------------------------------------- > > Key: JBIDE-23017 > URL: https://issues.jboss.org/browse/JBIDE-23017 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: build > Affects Versions: 4.4.1.AM3 > Reporter: Nick Boldt > Assignee: Nick Boldt > Labels: releasework > Fix For: 4.4.4.AM3, 4.4.4.Final > > Attachments: staging-times.png > > > Currently, publishing from /snapshots to /staging and from /staging to /development requires that we fetch several GBs of data from filemgmt.jboss.org to a temp folder, then push those bits to a new folder on filemgmt.jboss.org. > If we could simply copy bits over sshfs, the process might be a lot faster than these times: > {code} > JBT coretests 1.1G: 59m20 > JBT core 1.2G: 64m23 > devstudio (copy from filemgmt to filemgmt) 2.4G: 2h13 > devstudio (copy from local to www.qa) 3.1G: 6mins(?) > {code} > To make this work, however, we need more slaves to have sshfs installed. Currently, it appears that only dev01 [1] is so equipped. And that slave, currently, has a build queue more than 170 jobs long, making it impractical to even TEST publishing over sshfs. > [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/computer/dev01-rhel5-x86/ -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-23959) For JBIDE 4.5.0.AM1: Prepare for 4.5.0.AM1 / 11.0.0.AM1 [integration-tests]

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23959?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-23959 at 4/6/17 1:07 PM: ------------------------------------------------------------ https://github.com/jbosstools/jbosstools-integration-tests/pull/1789 PR should also fix interdependency problems causing build failures: {code} 10:22:43 [ERROR] Cannot resolve project dependencies: 10:22:43 [ERROR] Software being installed: org.jboss.tools.arquillian.reddeer 4.4.3.qualifier 10:22:43 [ERROR] Missing requirement: org.jboss.tools.arquillian.reddeer 4.4.3.qualifier requires 'bundle org.jboss.ide.eclipse.as.reddeer [3.2.3,3.3.0)' but it could not be found {code} -- https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Devstud... was (Author: nickboldt): https://github.com/jbosstools/jbosstools-integration-tests/pull/1789 > For JBIDE 4.5.0.AM1: Prepare for 4.5.0.AM1 / 11.0.0.AM1 [integration-tests] > --------------------------------------------------------------------------- > > Key: JBIDE-23959 > URL: https://issues.jboss.org/browse/JBIDE-23959 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: integration-tests > Reporter: Jeff MAURY > Assignee: Martin Malina > Priority: Blocker > Labels: task > Fix For: 4.5.0.AM1 > > > For JBIDE 4.5.0.AM1 [integration-tests]: Please perform the following tasks: > > 1. Check out your existing *{color:orange}master{color}* branch: > > {code} > git checkout master > {code} > > 2. Update your *{color:orange}master branch{color}* root pom to use the latest parent pom version, *{color:orange}4.5.0.AM1-SNAPSHOT{color}*: > > {code} > <parent> > <groupId>org.jboss.tools</groupId> > <artifactId>parent</artifactId> > <version>4.5.0.AM1-SNAPSHOT</version> > </parent> > {code} > > Now, your root pom will use parent pom version: > > * *{color:orange}4.5.0.AM1-SNAPSHOT{color}* in your *{color:orange}master{color}* branch > > 3. Ensure that component features/plugins have been [properly upversioned|http://wiki.eclipse.org/Version_Numbering#Overall_example], eg., from 1.0.0 to 1.0.1. > > {code} > mvn -Dtycho.mode=maven org.eclipse.tycho:tycho-versions-plugin:0.26.0:set-version -DnewVersion=1.0.1-SNAPSHOT > {code} > > > 4a. Ensure you've *built your code* using the latest *minimum* target platform version 4.70.0.AM1-SNAPSHOT > > {code} > mvn clean verify -Dtpc.version=4.70.0.AM1-SNAPSHOT > {code} > > 4b. Ensure you've *run your tests* using the latest *maximum* target platform version 4.70.0.AM1-SNAPSHOT > > {code} > mvn clean verify -Dtpc.version=4.70.0.AM1-SNAPSHOT > {code} > > 5. Close (do not resolve) this JIRA when done. > > 6. If you have any outstanding [New + Noteworthy JIRAs|https://issues.jboss.org/issues/?jql=%28%28project%20%3D%20%22JBIDE...] to do, please complete them next. > > [Search for all task JIRA|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+and...], or [Search for integration-tests task JIRA|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+and...] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-23959) For JBIDE 4.5.0.AM1: Prepare for 4.5.0.AM1 / 11.0.0.AM1 [integration-tests]

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23959?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-23959: ------------------------------------ https://github.com/jbosstools/jbosstools-integration-tests/pull/1789 > For JBIDE 4.5.0.AM1: Prepare for 4.5.0.AM1 / 11.0.0.AM1 [integration-tests] > --------------------------------------------------------------------------- > > Key: JBIDE-23959 > URL: https://issues.jboss.org/browse/JBIDE-23959 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: integration-tests > Reporter: Jeff MAURY > Assignee: Martin Malina > Priority: Blocker > Labels: task > Fix For: 4.5.0.AM1 > > > For JBIDE 4.5.0.AM1 [integration-tests]: Please perform the following tasks: > > 1. Check out your existing *{color:orange}master{color}* branch: > > {code} > git checkout master > {code} > > 2. Update your *{color:orange}master branch{color}* root pom to use the latest parent pom version, *{color:orange}4.5.0.AM1-SNAPSHOT{color}*: > > {code} > <parent> > <groupId>org.jboss.tools</groupId> > <artifactId>parent</artifactId> > <version>4.5.0.AM1-SNAPSHOT</version> > </parent> > {code} > > Now, your root pom will use parent pom version: > > * *{color:orange}4.5.0.AM1-SNAPSHOT{color}* in your *{color:orange}master{color}* branch > > 3. Ensure that component features/plugins have been [properly upversioned|http://wiki.eclipse.org/Version_Numbering#Overall_example], eg., from 1.0.0 to 1.0.1. > > {code} > mvn -Dtycho.mode=maven org.eclipse.tycho:tycho-versions-plugin:0.26.0:set-version -DnewVersion=1.0.1-SNAPSHOT > {code} > > > 4a. Ensure you've *built your code* using the latest *minimum* target platform version 4.70.0.AM1-SNAPSHOT > > {code} > mvn clean verify -Dtpc.version=4.70.0.AM1-SNAPSHOT > {code} > > 4b. Ensure you've *run your tests* using the latest *maximum* target platform version 4.70.0.AM1-SNAPSHOT > > {code} > mvn clean verify -Dtpc.version=4.70.0.AM1-SNAPSHOT > {code} > > 5. Close (do not resolve) this JIRA when done. > > 6. If you have any outstanding [New + Noteworthy JIRAs|https://issues.jboss.org/issues/?jql=%28%28project%20%3D%20%22JBIDE...] to do, please complete them next. > > [Search for all task JIRA|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+and...], or [Search for integration-tests task JIRA|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+and...] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-24236) cdk3 oc command

by Rob Stryker (JIRA)

Rob Stryker created JBIDE-24236: ----------------------------------- Summary: cdk3 oc command Key: JBIDE-24236 URL: https://issues.jboss.org/browse/JBIDE-24236 Project: Tools (JBoss Tools) Issue Type: Bug Reporter: Rob Stryker After minishift setup-cdk, the oc command is at %USERPROFILE%\.minishift\cache\oc\v3.4.1.2 Should our tools help streamline this process for users? I would suggest yes, but needs investigation **how** to do it. Another question is, do we need different 'oc' command versions for each openshift connection? Should it really be a workplace setting? Or should it be per-connection? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-24236) cdk3 oc command

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24236?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-24236: -------------------------------- Component/s: cdk openshift > cdk3 oc command > --------------- > > Key: JBIDE-24236 > URL: https://issues.jboss.org/browse/JBIDE-24236 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: cdk, openshift > Reporter: Rob Stryker > Assignee: Rob Stryker > > After minishift setup-cdk, the oc command is at %USERPROFILE%\.minishift\cache\oc\v3.4.1.2 > Should our tools help streamline this process for users? I would suggest yes, but needs investigation **how** to do it. > Another question is, do we need different 'oc' command versions for each openshift connection? Should it really be a workplace setting? Or should it be per-connection? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-24236) cdk3 oc command

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24236?page=com.atlassian.jira.plugi... ] Rob Stryker reassigned JBIDE-24236: ----------------------------------- Assignee: Rob Stryker > cdk3 oc command > --------------- > > Key: JBIDE-24236 > URL: https://issues.jboss.org/browse/JBIDE-24236 > Project: Tools (JBoss Tools) > Issue Type: Bug > Reporter: Rob Stryker > Assignee: Rob Stryker > > After minishift setup-cdk, the oc command is at %USERPROFILE%\.minishift\cache\oc\v3.4.1.2 > Should our tools help streamline this process for users? I would suggest yes, but needs investigation **how** to do it. > Another question is, do we need different 'oc' command versions for each openshift connection? Should it really be a workplace setting? Or should it be per-connection? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-24084) To succesfully start CDKv3 Server adapter with hyperV provider, IDE must be start with admin rights

by Martin Malina (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24084?page=com.atlassian.jira.plugi... ] Martin Malina commented on JBIDE-24084: --------------------------------------- [~odockal], yeah, it seems to be a limitation of Hyper-V that it requires admin privileges. So far I have mostly been using VirtualBox on Windows, but I struggle even with that - see: CDK-84 minishift takes 10 minutes to start and is unresponsive > To succesfully start CDKv3 Server adapter with hyperV provider, IDE must be start with admin rights > --------------------------------------------------------------------------------------------------- > > Key: JBIDE-24084 > URL: https://issues.jboss.org/browse/JBIDE-24084 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: cdk > Affects Versions: 4.4.4.AM1 > Environment: Windows 10 Pro, x86_64 > HyperV allowed > Reporter: Ondrej Dockal > Priority: Blocker > Fix For: 4.4.4.AM3 > > > One must run devstudio with admin rights to be able to start CDKv3 server adapter with hyperV vm-provider. Also, setup-cdk command must be run in cli before server adapter is started in IDE (admin rights are not required). > I am not sure, if those issues are bugs or more features requests/enhancements, but we should definitely do something about it. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-23896) Allow user to choose hypervisor in editor and new server wizard

by Martin Malina (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23896?page=com.atlassian.jira.plugi... ] Martin Malina closed JBIDE-23896. --------------------------------- I checked this again with devstudio 10.4.0.AM3 B389 and it looks fine now. I also noticed that [~odockal] commented in a similar way on JBIDE-23905 and closed that one. So I am closing this also. > Allow user to choose hypervisor in editor and new server wizard > --------------------------------------------------------------- > > Key: JBIDE-23896 > URL: https://issues.jboss.org/browse/JBIDE-23896 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: cdk, server > Affects Versions: 4.4.3.AM2 > Reporter: Rob Stryker > Assignee: Rob Stryker > Fix For: 4.4.4.AM2 > > Attachments: cdk3tp.png > > > Users do not like going to customize cmd args unless absolutely necessary. The most common usecases should be doable from the server editor or the creation wizard. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ERT-499) Deadlock DependencyGraphImpl and ComponentCore [EBZ#511793]

by Friendly Jira Robot (JIRA)

Friendly Jira Robot created ERT-499: --------------------------------------- Summary: Deadlock DependencyGraphImpl and ComponentCore [EBZ#511793] Key: ERT-499 URL: https://issues.jboss.org/browse/ERT-499 Project: Eclipse Release Train Issue Type: Task Components: WTP Common Tools Reporter: Friendly Jira Robot We have some code that creates a project and then installs a custom facet. We're seeing a deadlock with the DependencyGraphImpl's GraphUpdateJob. Our code creates the project and then uses FacetedProject#modify() to install our own facet in the project. It hangs attempting to acquire the project's lock. But it has already acquired the ComponentImplManager's synchronization lock (stack frame marked with XXX): Thread [ModalContext] (Suspended (entry into method getProjectLockObject in EMFWorkbenchEditContextFactory)) owns: ComponentImplManager (id=218) owns: CreateAppEngineStandardWtpProject (id=219) EMFWorkbenchEditContextFactory.getProjectLockObject(IProject) line: 63 EMFWorkbenchEditContextFactory.createEMFContext(IProject, IEMFContextContributor) line: 79 WorkbenchResourceHelperBase.createEMFContext(IProject, IEMFContextContributor) line: 249 ModuleCoreNature(EMFNature).createEmfContext() line: 105 ModuleCoreNature(EMFNature).getEmfContextBase() line: 229 ModuleCoreNature(EditModelNature).getEmfContext() line: 61 ModuleCoreNature.getModuleStructuralModelForWrite(Object) line: 303 StructureEdit.<init>(ModuleCoreNature, boolean) line: 329 StructureEdit.getStructureEditForRead(IProject) line: 119 VirtualComponent.createResource() line: 121 VirtualComponent.initializeResource() line: 113 VirtualComponent.<init>(IProject, IPath) line: 148 XXX ComponentImplManager.createComponent(IProject, boolean) line: 250 ComponentCore.createComponent(IProject, boolean) line: 84 WebFacetInstallDelegate.setContentPropertyIfNeeded(IDataModel, IPath, IProject) line: 221 WebFacetInstallDelegate.execute(IProject, IProjectFacetVersion, Object, IProgressMonitor) line: 86 FacetedProject.callDelegate(IProjectFacetVersion, IDelegate, Object, Object, IProgressMonitor) line: 1477 FacetedProject.modifyInternal(Set<Action>, IProgressMonitor) line: 441 FacetedProject.mergeChangesInternal(IFacetedProjectWorkingCopy, IProgressMonitor) line: 1181 FacetedProject.access$2(FacetedProject, IFacetedProjectWorkingCopy, IProgressMonitor) line: 1117 FacetedProject$1.run(IProgressMonitor) line: 324 Workspace.run(ICoreRunnable, ISchedulingRule, int, IProgressMonitor) line: 2240 Workspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) line: 2267 FacetedProject.modify(Set<Action>, IProgressMonitor) line: 339 AppEngineStandardFacet.installAppEngineFacet(IFacetedProject, boolean, IProgressMonitor) line: 150 CreateAppEngineStandardWtpProject.execute(IProgressMonitor) line: 103 CreateAppEngineStandardWtpProject(WorkspaceModifyOperation).lambda$0(InvocationTargetException[], IProgressMonitor) line: 107 1612372028.run(IProgressMonitor) line: not available Workspace.run(ICoreRunnable, ISchedulingRule, int, IProgressMonitor) line: 2240 Workspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) line: 2267 CreateAppEngineStandardWtpProject(WorkspaceModifyOperation).run(IProgressMonitor) line: 128 ModalContext$ModalContextThread.run() line: 119 The project creation spawns a GraphUpdateJob that call ComponentImplManager#createComponent(IProject). This method first acquires the associated project lock, and then attempts to call ComponentImplManager#createComponent(IProject,boolean), which is a synchronized method. Thread [Worker-0] (Suspended (entry into method getProjectLockObject in EMFWorkbenchEditContextFactory)) EMFWorkbenchEditContextFactory.getProjectLockObject(IProject) line: 63 ComponentImplManager.createComponent(IProject) line: 207 ComponentCore.createComponent(IProject) line: 64 DependencyGraphImpl$GraphUpdateJob$1.run() line: 494 SafeRunner.run(ISafeRunnable) line: 42 DependencyGraphImpl$GraphUpdateJob.run(IProgressMonitor) line: 462 Worker.run() line: 56 If the GraphUpdateJob acquires the project lock first, we have deadlock as our ModalContext thread has the ComponentImplManager's synchronization lock. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues April 2017