October 2016 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-22598) Support runtime detection for manual CDK install

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22598?page=com.atlassian.jira.plugi... ] Rob Stryker resolved JBIDE-22598. --------------------------------- Resolution: Done I've pushed https://github.com/jbosstools/jbosstools-base/pull/536/files as well. This should fix the depth issue and also adds a proper progress bar to the search dialog. > Support runtime detection for manual CDK install > ------------------------------------------------ > > Key: JBIDE-22598 > URL: https://issues.jboss.org/browse/JBIDE-22598 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: cdk, runtime-detection > Affects Versions: 4.4.0.Final > Reporter: Martin Malina > Assignee: Rob Stryker > Fix For: 4.4.2.AM2 > > > Right now with CDK 2.1 when you have a manual cdk install (i.e. using cdk.zip and then adding the vagrant box yourself), there will be no .cdk marker, so Runtime Detection will not work. > The only case where Runtime Detection will work is when you use the (as of now Windows-only) suite installer. At that point Runtime Detection will do its thing silently without you noticing. > The way I see it there are two options: > a) Create and upstream issue with CDK and ask them to include a basic .cdk in their zip > b) Make the runtime detection work without .cdk -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23182) NullPointerException in PodLogsHandler.handleEvent

by Dmitrii Bocharov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23182?page=com.atlassian.jira.plugi... ] Dmitrii Bocharov commented on JBIDE-23182: ------------------------------------------ I don't think it's an Eclipse issue. It's more an intended behavior. I reviewed the PR and tried to find if somebody had the same problems. I think [this answer|http://stackoverflow.com/questions/8682978/how-to-make-a-propertys...] is the most suitable for us: {quote} ... But since PropertySheetPage is designed to change its input on global selection change, then you have to find some custom way to notify/update your handler.{quote} So i agree with the last Slava's comment. _HandlerUtil.getCurrentSelection(event)_ takes the selection from the context. So if we sum up, we need to update EvaluationContext in OpenShiftResourcePropertySection class for example like this: {code:java}table.addSelectionChangedListener(new ISelectionChangedListener() { @Override public void selectionChanged(SelectionChangedEvent event) { IHandlerService service = (IHandlerService) page.getSite().getService(IHandlerService.class); service.getCurrentState().addVariable(ISources.ACTIVE_CURRENT_SELECTION_NAME, table.getSelection()); } });{code} But this made no sense, because in the example above i'm trying to update the global evaluation context from getter. Nothing just happens. So the way to solve it is to define a child evaluation context, which will be used then in Handlers too. I think it's a much bigger refactoring, than the one that Slava made. I think we should merge it. However, i might have missed some possibilities and maybe someone has more experience with updating the evaluation context. That is the thing that should be done for Properties view similarly to what i offered above, because it's a "peculiar" view. > NullPointerException in PodLogsHandler.handleEvent > -------------------------------------------------- > > Key: JBIDE-23182 > URL: https://issues.jboss.org/browse/JBIDE-23182 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Reporter: Automated Error Reporting Bot > Labels: openshift_v3, pod_log_console > Fix For: 4.4.2.AM2 > > > The following problem was reported via the automated error reporting: > Message: Unhandled event loop exception > {noformat} > java.lang.NullPointerException: null > at org.jboss.tools.openshift.internal.ui.handler.PodLogsHandler.handleEvent(PodLogsHandler.java:46) > at org.jboss.tools.openshift.internal.ui.handler.AbstractOpenShiftCliHandler.execute(AbstractOpenShiftCliHandler.java:70) > at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:295) > at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90) > at sun.reflect.NativeMethodAccessorImpl.invoke0(null:-2) > at sun.reflect.NativeMethodAccessorImpl.invoke(null:-1) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(null:-1) > at java.lang.reflect.Method.invoke(null:-1) > at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:54) > {noformat} > Bundles: > | org.eclipse.e4.core.di | 1.6.0.v20160319-0612 | 1.6.0.v20160319-0612 | > | org.eclipse.ui | 3.108.0.v20160518-1929 | 3.108.0.v20160518-1929 | > | org.jboss.tools.openshift.ui | 3.3.0.v20160831-0703 | 3.3.0.v20160831-0703 | > Operating Systems: > | Windows | 10.0.0 | 10.0.0 | > The above information is a snapshot of the collected data. Visit [this page|https://redhat.ctrlflow.com/reviewers/#!/problems/57d6df25e4b0fd7621...] for the latest data. > Thank you for your assistance. > Your friendly error-reports-inbox. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23323) Update org.jboss.tools.mylyn.ui.bot.test tests - remove redundant code that leads to intermittent failures

by Len DiMaggio (JIRA)

Len DiMaggio created JBIDE-23323: ------------------------------------ Summary: Update org.jboss.tools.mylyn.ui.bot.test tests - remove redundant code that leads to intermittent failures Key: JBIDE-23323 URL: https://issues.jboss.org/browse/JBIDE-23323 Project: Tools (JBoss Tools) Issue Type: Task Components: qa Affects Versions: 4.4.2.AM1 Reporter: Len DiMaggio -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23323) Update org.jboss.tools.mylyn.ui.bot.test tests - remove redundant code that leads to intermittent failures

by Len DiMaggio (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23323?page=com.atlassian.jira.plugi... ] Len DiMaggio reassigned JBIDE-23323: ------------------------------------ Assignee: Len DiMaggio > Update org.jboss.tools.mylyn.ui.bot.test tests - remove redundant code that leads to intermittent failures > ---------------------------------------------------------------------------------------------------------- > > Key: JBIDE-23323 > URL: https://issues.jboss.org/browse/JBIDE-23323 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: qa > Affects Versions: 4.4.2.AM1 > Reporter: Len DiMaggio > Assignee: Len DiMaggio > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22598) Support runtime detection for manual CDK install

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22598?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-22598: ------------------------------------- Seems we hard-code a max-depth of 4 since the runtime detection wizard doesn't have a cancel button. I guess I can look into fixing this but I'd prefer a new issue. > Support runtime detection for manual CDK install > ------------------------------------------------ > > Key: JBIDE-22598 > URL: https://issues.jboss.org/browse/JBIDE-22598 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: cdk, runtime-detection > Affects Versions: 4.4.0.Final > Reporter: Martin Malina > Assignee: Rob Stryker > Fix For: 4.4.2.AM2 > > > Right now with CDK 2.1 when you have a manual cdk install (i.e. using cdk.zip and then adding the vagrant box yourself), there will be no .cdk marker, so Runtime Detection will not work. > The only case where Runtime Detection will work is when you use the (as of now Windows-only) suite installer. At that point Runtime Detection will do its thing silently without you noticing. > The way I see it there are two options: > a) Create and upstream issue with CDK and ask them to include a basic .cdk in their zip > b) Make the runtime detection work without .cdk -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-13661) Cannot create archive from archive in explorer

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-13661?page=com.atlassian.jira.plugi... ] Rob Stryker resolved JBIDE-13661. --------------------------------- Resolution: Done Fixed it > Cannot create archive from archive in explorer > ---------------------------------------------- > > Key: JBIDE-13661 > URL: https://issues.jboss.org/browse/JBIDE-13661 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: archives > Affects Versions: 4.1.0.Alpha1 > Reporter: Jaroslav Jankovič > Assignee: Rob Stryker > Priority: Minor > Fix For: 4.4.2.AM2 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-13661) Cannot create archive from archive in explorer

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-13661?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-13661: ------------------------------------- Thanks for the debugging, [~rawagner]. It seems to be a bit of a regression related to (either before or after) JBIDE-3627, which is pretty old ;) > Cannot create archive from archive in explorer > ---------------------------------------------- > > Key: JBIDE-13661 > URL: https://issues.jboss.org/browse/JBIDE-13661 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: archives > Affects Versions: 4.1.0.Alpha1 > Reporter: Jaroslav Jankovič > Assignee: Rob Stryker > Priority: Minor > Fix For: 4.4.2.AM2 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21065) Server host name address should not be defaulted during server adapter creation

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21065?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-21065: ------------------------------------- Asked upstream to add to neon.2 I'll leave this open until it's confirmed in neon.2 and it's in our TP > Server host name address should not be defaulted during server adapter creation > ------------------------------------------------------------------------------- > > Key: JBIDE-21065 > URL: https://issues.jboss.org/browse/JBIDE-21065 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server, upstream > Affects Versions: 4.3.0.Final > Reporter: Xavier Coulon > Assignee: Rob Stryker > Fix For: 4.4.2.AM2 > > > I've noticed that when I create a server adapter and I give it an IP address as the hostname, the hostname remains the default value, ie, {{localhost}}. > This is annoying in the case where I want to connect to a VM running on my own host (eg, a VM running Docker). In this particular case, I set the hostname at something like {{192.168.99.100}} but it is reverted as {{localhost}} which gives {{127.0.0.1}} as the primary IP address. As a consequence, the server adapter fails to connect to the server since it uses the wrong IP address. > Note that the host name can be changed for good in the Server Configuration Editor _after_ its creation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23322) create mojo that takes as input a list of URLs and a name, and generates a composite site

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23322?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-23322: ------------------------------- Description: In https://issues.jboss.org/browse/WINDUP-1189 it was requested that tycho builds be able to produce a simple composite site, using as input 2 or more URLs. So, to generalize this for use by other projects, we need a mojo that can be configured with a set of URLs, and a site name, in order to produce: target/composite/ target/composite/compositeContent.xml target/composite/compositeArtifacts.xml target/composite/p2.index (like https://devstudio.jboss.com/10.0/stable/updates/p2.index ) was: It would be great if local build of windup eclipse plugins could create a composite update site. Details: 1) windup eclipse plugin source: https://github.com/windup/windup-eclipse-plugin 2) windup eclipse code nightly update site: http://download.jboss.org/jbosstools/neon/snapshots/builds/windup-eclipse... 3) jbt dependency update site: http://download.jboss.org/jbosstools/neon/snapshots/updates/ 4) Jenkins job: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/Windup/job/windup-e... Making these maven flags would allow for easier over-riding so that when windup tools branch for alpha1 they can change the deps to our am2 release for stability. > create mojo that takes as input a list of URLs and a name, and generates a composite site > ----------------------------------------------------------------------------------------- > > Key: JBIDE-23322 > URL: https://issues.jboss.org/browse/JBIDE-23322 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.2.AM3 > > > In https://issues.jboss.org/browse/WINDUP-1189 it was requested that tycho builds be able to produce a simple composite site, using as input 2 or more URLs. > So, to generalize this for use by other projects, we need a mojo that can be configured with a set of URLs, and a site name, in order to produce: > target/composite/ > target/composite/compositeContent.xml > target/composite/compositeArtifacts.xml > target/composite/p2.index (like https://devstudio.jboss.com/10.0/stable/updates/p2.index ) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21065) Server host name address should not be defaulted during server adapter creation

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21065?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-21065: -------------------------------- Story Points: 8 (was: 3) > Server host name address should not be defaulted during server adapter creation > ------------------------------------------------------------------------------- > > Key: JBIDE-21065 > URL: https://issues.jboss.org/browse/JBIDE-21065 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server, upstream > Affects Versions: 4.3.0.Final > Reporter: Xavier Coulon > Assignee: Rob Stryker > Fix For: 4.4.2.AM2 > > > I've noticed that when I create a server adapter and I give it an IP address as the hostname, the hostname remains the default value, ie, {{localhost}}. > This is annoying in the case where I want to connect to a VM running on my own host (eg, a VM running Docker). In this particular case, I set the hostname at something like {{192.168.99.100}} but it is reverted as {{localhost}} which gives {{127.0.0.1}} as the primary IP address. As a consequence, the server adapter fails to connect to the server since it uses the wrong IP address. > Note that the host name can be changed for good in the Server Configuration Editor _after_ its creation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

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 October 2016