[JBoss JIRA] (JBIDE-19605) Avoid need for multiple javax.servlet
by Brian Fitzpatrick (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19605?page=com.atlassian.jira.plugi... ]
Brian Fitzpatrick commented on JBIDE-19605:
-------------------------------------------
[~xcoulon] Any ideas on the test failures? Since everything seems to pass in the latest Jenkins builds, I suspect it may be something local?
> Avoid need for multiple javax.servlet
> -------------------------------------
>
> Key: JBIDE-19605
> URL: https://issues.jboss.org/browse/JBIDE-19605
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: target-platform, webservices
> Affects Versions: 4.3.0.Alpha2
> Reporter: Mickael Istria
> Assignee: Brian Fitzpatrick
> Fix For: LATER
>
> Attachments: org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.JavaElement11ChangedProcessingTestCase.txt, org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.JaxrsMetamodelChangedProcessorTestCase.txt, org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.ResourceChangedProcessingTestCase.txt, org.jboss.tools.ws.jaxrs.core.internal.metamodel.domain.Jaxrs11ElementFactoryTestCase.txt, org.jboss.tools.ws.jaxrs.core.internal.metamodel.domain.Jaxrs20EndpointTestCase.txt
>
>
> We currently use 2 different version of javax.servlet bundle. We'd rather decide on sticking to 1.
> {code}
> On 04/15/2015 11:56 PM, Nick Boldt wrote:
> > Just wondering if anyone knows WHY we include javax.servlet 3.0.0 and
> > 3.1.0 in JBDS.
> > More importantly... SHOULD we be including both? Or can we just include
> > 3.1.0 and drop 3.0.0?
> I have JBDS installed from installer, which basically ran a p2 director. And I get jetty 3.0.0 and jetty 3.1.0. Than means that while resolving what to installed, p2 has to keep both versions of javax.servlet. That's definitely a sign that our dependency chain currently need both (or p2 wouldn't have installed both).
> So I've tried the ultimate test:
> $ cd jbdevstudio-9.0.0.Alpha2/studio
> $ rm plugins/javax.servlet_3.0.0*
> $ ./jbdevstudio
> And saw
> !ENTRY org.jboss.tools.ws.ui 4 0 2015-04-16 10:35:49.110
> !MESSAGE FrameworkEvent ERROR
> !STACK 0
> org.osgi.framework.BundleException: Could not resolve module: org.jboss.tools.ws.ui [967]
> Unresolved requirement: Import-Package: javax.servlet; version="[2.4.0,3.0.0)"
> at org.eclipse.osgi.container.Module.start(Module.java:434)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1561)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
> at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
> Fun thing is that the javax.servlet_3.0.0 actually exports packages in version 2.6.0, whereas javax.servlet_3.1.0 exports them in version 3.1.0.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19605) Avoid need for multiple javax.servlet
by Brian Fitzpatrick (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19605?page=com.atlassian.jira.plugi... ]
Brian Fitzpatrick updated JBIDE-19605:
--------------------------------------
Attachment: org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.JavaElement11ChangedProcessingTestCase.txt
org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.JaxrsMetamodelChangedProcessorTestCase.txt
org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.ResourceChangedProcessingTestCase.txt
org.jboss.tools.ws.jaxrs.core.internal.metamodel.domain.Jaxrs11ElementFactoryTestCase.txt
org.jboss.tools.ws.jaxrs.core.internal.metamodel.domain.Jaxrs20EndpointTestCase.txt
> Avoid need for multiple javax.servlet
> -------------------------------------
>
> Key: JBIDE-19605
> URL: https://issues.jboss.org/browse/JBIDE-19605
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: target-platform, webservices
> Affects Versions: 4.3.0.Alpha2
> Reporter: Mickael Istria
> Assignee: Brian Fitzpatrick
> Fix For: LATER
>
> Attachments: org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.JavaElement11ChangedProcessingTestCase.txt, org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.JaxrsMetamodelChangedProcessorTestCase.txt, org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.ResourceChangedProcessingTestCase.txt, org.jboss.tools.ws.jaxrs.core.internal.metamodel.domain.Jaxrs11ElementFactoryTestCase.txt, org.jboss.tools.ws.jaxrs.core.internal.metamodel.domain.Jaxrs20EndpointTestCase.txt
>
>
> We currently use 2 different version of javax.servlet bundle. We'd rather decide on sticking to 1.
> {code}
> On 04/15/2015 11:56 PM, Nick Boldt wrote:
> > Just wondering if anyone knows WHY we include javax.servlet 3.0.0 and
> > 3.1.0 in JBDS.
> > More importantly... SHOULD we be including both? Or can we just include
> > 3.1.0 and drop 3.0.0?
> I have JBDS installed from installer, which basically ran a p2 director. And I get jetty 3.0.0 and jetty 3.1.0. Than means that while resolving what to installed, p2 has to keep both versions of javax.servlet. That's definitely a sign that our dependency chain currently need both (or p2 wouldn't have installed both).
> So I've tried the ultimate test:
> $ cd jbdevstudio-9.0.0.Alpha2/studio
> $ rm plugins/javax.servlet_3.0.0*
> $ ./jbdevstudio
> And saw
> !ENTRY org.jboss.tools.ws.ui 4 0 2015-04-16 10:35:49.110
> !MESSAGE FrameworkEvent ERROR
> !STACK 0
> org.osgi.framework.BundleException: Could not resolve module: org.jboss.tools.ws.ui [967]
> Unresolved requirement: Import-Package: javax.servlet; version="[2.4.0,3.0.0)"
> at org.eclipse.osgi.container.Module.start(Module.java:434)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1561)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
> at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
> Fun thing is that the javax.servlet_3.0.0 actually exports packages in version 2.6.0, whereas javax.servlet_3.1.0 exports them in version 3.1.0.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19605) Avoid need for multiple javax.servlet
by Brian Fitzpatrick (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19605?page=com.atlassian.jira.plugi... ]
Brian Fitzpatrick commented on JBIDE-19605:
-------------------------------------------
Removed the following lines from the MANIFEST.MF for org.jboss.tools.ws.ui
{code}
javax.servlet;version="[2.4.0,3.0.0)",
javax.servlet.http;version="[2.4.0,3.0.0)",
{code}
And it builds ok, and all the main JAX-WS tests pass fine but I have test failures in JAX-RS (org.jboss.tools.ws.jaxrs.core.test). Will attach the surefire logs.
> Avoid need for multiple javax.servlet
> -------------------------------------
>
> Key: JBIDE-19605
> URL: https://issues.jboss.org/browse/JBIDE-19605
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: target-platform, webservices
> Affects Versions: 4.3.0.Alpha2
> Reporter: Mickael Istria
> Assignee: Brian Fitzpatrick
> Fix For: LATER
>
>
> We currently use 2 different version of javax.servlet bundle. We'd rather decide on sticking to 1.
> {code}
> On 04/15/2015 11:56 PM, Nick Boldt wrote:
> > Just wondering if anyone knows WHY we include javax.servlet 3.0.0 and
> > 3.1.0 in JBDS.
> > More importantly... SHOULD we be including both? Or can we just include
> > 3.1.0 and drop 3.0.0?
> I have JBDS installed from installer, which basically ran a p2 director. And I get jetty 3.0.0 and jetty 3.1.0. Than means that while resolving what to installed, p2 has to keep both versions of javax.servlet. That's definitely a sign that our dependency chain currently need both (or p2 wouldn't have installed both).
> So I've tried the ultimate test:
> $ cd jbdevstudio-9.0.0.Alpha2/studio
> $ rm plugins/javax.servlet_3.0.0*
> $ ./jbdevstudio
> And saw
> !ENTRY org.jboss.tools.ws.ui 4 0 2015-04-16 10:35:49.110
> !MESSAGE FrameworkEvent ERROR
> !STACK 0
> org.osgi.framework.BundleException: Could not resolve module: org.jboss.tools.ws.ui [967]
> Unresolved requirement: Import-Package: javax.servlet; version="[2.4.0,3.0.0)"
> at org.eclipse.osgi.container.Module.start(Module.java:434)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1561)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
> at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
> Fun thing is that the javax.servlet_3.0.0 actually exports packages in version 2.6.0, whereas javax.servlet_3.1.0 exports them in version 3.1.0.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBDS-2044) .eclipseproduct file no longer refers to JBDS
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-2044?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-2044:
-------------------------------------
I've tested devstudio build without references to org.eclipse.platform feature to check if it still has all product related feature. I removed everything related to platform feature and feature itself and ran the product build. Build and installation were fine no errors no .eclipseproduct file, but devstudio failed to start with error
{code}!ENTRY org.eclipse.e4.ui.workbench 4 0 2015-04-28 11:25:37.892
!MESSAGE Unable to load resource platform:/plugin/org.eclipse.platform/LegacyIDE.e4xmi
!STACK 0
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl$1DiagnosticWrappedException: java.io.IOException: Unable to resolve plug-in "platform:/plugin/org.eclipse.platform/LegacyIDE.e4xmi".
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.handleDemandLoadException(ResourceSetImpl.java:319)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:278)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResource(ResourceSetImpl.java:406)
at org.eclipse.e4.ui.internal.workbench.ResourceHandler.getResource(ResourceHandler.java:350)
at org.eclipse.e4.ui.internal.workbench.ResourceHandler.loadResource(ResourceHandler.java:326)
at org.eclipse.e4.ui.internal.workbench.ResourceHandler.loadMostRecentModel(ResourceHandler.java:243)
at org.eclipse.e4.ui.internal.workbench.swt.E4Application.loadApplicationModel(E4Application.java:398)
at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createE4Workbench(E4Application.java:255)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:620)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:598)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:138)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
Caused by: java.io.IOException: Unable to resolve plug-in "platform:/plugin/org.eclipse.platform/LegacyIDE.e4xmi".
at org.eclipse.core.internal.runtime.PlatformURLPluginConnection.parse(PlatformURLPluginConnection.java:65)
at org.eclipse.core.internal.runtime.PlatformURLPluginConnection.resolve(PlatformURLPluginConnection.java:77)
at org.eclipse.core.internal.boot.PlatformURLHandler.openConnection(PlatformURLHandler.java:69)
at org.eclipse.osgi.internal.url.URLStreamHandlerProxy.openConnection(URLStreamHandlerProxy.java:114)
at java.net.URL.openConnection(URL.java:971)
at org.eclipse.emf.ecore.resource.impl.URIHandlerImpl.createInputStream(URIHandlerImpl.java:200)
at org.eclipse.emf.ecore.resource.impl.ExtensibleURIConverterImpl.createInputStream(ExtensibleURIConverterImpl.java:360)
at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1269)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoad(ResourceSetImpl.java:259)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:274)
... 24 more
{code}
After I added reference to org.eclipse.platform bundle everything went back to normal and no .eclipseproduct file.
Only m2e* features has references to org.eclipse.platform feature and that is the reason we cannot include our own marker file with right product id in it. But as I said before that really doesn't harm anyone, because equinox will generate unique location to store its state info based on installation folder hash.
So it is really optional issue to fix.
> .eclipseproduct file no longer refers to JBDS
> ---------------------------------------------
>
> Key: JBDS-2044
> URL: https://issues.jboss.org/browse/JBDS-2044
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer
> Affects Versions: 5.0.0.Beta1
> Reporter: Nick Boldt
> Assignee: Denis Golovin
> Labels: discuss
> Fix For: 8.x
>
>
> Before, with the linux x64 installer (jbdevstudio-product-linux-gtk-x86_64-5.0.0.v201202271832M-H79-Beta1.jar) the .eclipseproduct file read:
> {code}
> name=JBoss Developer Studio
> id=com.jboss.jbds.all
> version=5.0.0.v201202271832M-H79-Beta1
> {code}
> Now, with the universal installer (jbdevstudio-product-universal-5.0.0.v201202271832M-H79-Beta1.jar), it reads:
> {code}
> name=Eclipse Platform
> id=org.eclipse.platform
> version=3.7.0
> {code}
> Latest code in equinox.runtime master branch is located http://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/bundles/or...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-15481) setup of vwatch for jboss tools installations
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15481?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-15481:
-------------------------------
Description:
1. use the install robot and then run versionwatch aginst JBoss Tools install with all of central content installed.
usecases:
* find missing/weird versions
* duplicate components
* get list of potential unnecessary plugins in TP
2. document how to do installs for Eclipse, JBT or JBDS BYOE via commandline for setting up the footprint of installs against which to do baseline version watches – pre-existing doc here:
http://download.jboss.org/jbosstools/updates/scripted-installation/
https://devstudio.redhat.com/download/scripted-install/
3. test #2 to ensure it works, and that a mix of "studio" and "eclipse" folders can be used in a vwatch report
4. create new jobs (or extend existing ones) to provide reports about JBT, JBT+Central, JBT+Central+EA; repeat for JBDS combinations. Maybe migrate jobs to matrixes?
Additionally, now that jbdevstudio-qa/vwatch has moved to jbosstools-versionwatch, we should also do these two things:
5. remove all refs to QA Jenkins file paths to make *.sh scripts more generic
6. migrate those internal file paths into jenkins config.xml files so they're not stored in public repos
was:
1. use the install robot and then run versionwatch aginst JBoss Tools install with all of central content installed.
usecases:
* find missing/weird versions
* duplicate components
* get list of potential unnecessary plugins in TP
2. document how to do installs for Eclipse, JBT or JBDS BYOE via commandline for setting up the footprint of installs against which to do baseline version watches – pre-existing doc here:
http://download.jboss.org/jbosstools/updates/scripted-installation/
https://devstudio.redhat.com/download/scripted-install/
3. test #2 to ensure it works, and that a mix of "studio" and "eclipse" folders can be used in a vwatch report
4. create new jobs (or extend existing ones) to provide reports about JBT, JBT+Central, JBT+Central+EA; repeat for JBDS combinations. Maybe migrate jobs to matrixes?
> setup of vwatch for jboss tools installations
> ---------------------------------------------
>
> Key: JBIDE-15481
> URL: https://issues.jboss.org/browse/JBIDE-15481
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Reporter: Max Rydahl Andersen
> Assignee: Nick Boldt
> Fix For: 4.3.0.Beta1
>
> Attachments: jbide15481.png
>
>
> 1. use the install robot and then run versionwatch aginst JBoss Tools install with all of central content installed.
> usecases:
> * find missing/weird versions
> * duplicate components
> * get list of potential unnecessary plugins in TP
> 2. document how to do installs for Eclipse, JBT or JBDS BYOE via commandline for setting up the footprint of installs against which to do baseline version watches – pre-existing doc here:
> http://download.jboss.org/jbosstools/updates/scripted-installation/
> https://devstudio.redhat.com/download/scripted-install/
> 3. test #2 to ensure it works, and that a mix of "studio" and "eclipse" folders can be used in a vwatch report
> 4. create new jobs (or extend existing ones) to provide reports about JBT, JBT+Central, JBT+Central+EA; repeat for JBDS combinations. Maybe migrate jobs to matrixes?
> Additionally, now that jbdevstudio-qa/vwatch has moved to jbosstools-versionwatch, we should also do these two things:
> 5. remove all refs to QA Jenkins file paths to make *.sh scripts more generic
> 6. migrate those internal file paths into jenkins config.xml files so they're not stored in public repos
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-18570) Creating EJB 3.x bean is asking EJB 2.x values
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18570?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-18570:
---------------------------------------
[~ArunGupta], I don't have an opinion on this, but if you still think this shouldn't be there or should be handled differently, let us know (including some arguments) and I'm sure Rob will be happy to reconsider :) Otherwise I will close this JIRA.
> Creating EJB 3.x bean is asking EJB 2.x values
> ----------------------------------------------
>
> Key: JBIDE-18570
> URL: https://issues.jboss.org/browse/JBIDE-18570
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: ejb3, upstream
> Reporter: Arun Gupta
> Assignee: Rob Stryker
> Fix For: 4.3.x
>
> Attachments: Screen Shot 2014-10-09 at 9.41.39 pm.png
>
>
> Creating a singleton EJB using 3.x wizard and its asking for home and component interfaces from 2.x. This is confusing and redundant.
> Image coming in attachment next.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19453) Remote host information does not fit in the server editor
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19453?page=com.atlassian.jira.plugi... ]
Martin Malina updated JBIDE-19453:
----------------------------------
Attachment: server-editor-linux.png
I tried the same on Linux (RHEL 7 with Gnome) and it is better, but the buttons are still a bit cut off:
!server-editor-linux.png!
Again, if I made the window wide enough, it will eventually show up correctly.
So the minimal width of the column needs to be wider and it should be same on OS X and Linux - I thought it more or less was that way in the past.
> Remote host information does not fit in the server editor
> ---------------------------------------------------------
>
> Key: JBIDE-19453
> URL: https://issues.jboss.org/browse/JBIDE-19453
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.3.Beta1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.3.0.Beta1
>
> Attachments: remote-runtime-does-not-fit.png, server-editor-2.png, server-editor-linux.png
>
>
> Today I noticed this. When I set up a remote server and then open it in the Server editor, the part under Server Behavior where it shows the remote host configuration (e.g. Remote Server Home) does not fix - it needs more space to the right, but it's hidden and there is no way to scroll to view it.
> !remote-runtime-does-not-fit.png!
> The same problem applies to both JBDS 8.1.0.Beta1 and JBDS 9.0.0.Alpha1. So you may want to clone this for 4.3.x.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months