[JBoss JIRA] (JBIDE-24436) Deploy wizard: dialog expands to full available vertical space
by Josef Kopriva (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24436?page=com.atlassian.jira.plugi... ]
Josef Kopriva updated JBIDE-24436:
----------------------------------
Fix Version/s: 4.5.3.Final
(was: 4.5.x)
> Deploy wizard: dialog expands to full available vertical space
> --------------------------------------------------------------
>
> Key: JBIDE-24436
> URL: https://issues.jboss.org/browse/JBIDE-24436
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.4.Final
> Reporter: Andre Dietisheim
> Priority: Minor
> Labels: deploy_docker_wizard, openshift_v3
> Fix For: 4.5.3.Final
>
> Attachments: deploy-image-wizard-too-tall.png
>
>
> steps:
> # ASSERT: have a docker image available in your local docker daemon
> # ASSERT: have docker tooling installed and a connection to your local docker daemon defined
> # EXEC: open "Docker Explorer" view, unfold "Images" for the conneciton to your local docker daemon
> # EXEC: select your docker image and pick "Deploy to OpenShift..."
> Result:
> Docker Image deploy wizard pops up, taking all the available vertical space
> !deploy-image-wizard-too-tall.png!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JBIDE-23512) Properties: Header hidden by another header is not retrievable
by Josef Kopriva (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23512?page=com.atlassian.jira.plugi... ]
Josef Kopriva commented on JBIDE-23512:
---------------------------------------
[~adietish] yes, I am able to reproduce it on F28.
> Properties: Header hidden by another header is not retrievable
> --------------------------------------------------------------
>
> Key: JBIDE-23512
> URL: https://issues.jboss.org/browse/JBIDE-23512
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.2.Final
> Reporter: Marián Labuda
> Priority: Minor
> Labels: openshift_v3, properties
> Fix For: 4.5.x
>
> Attachments: out-1.ogv, properties.ogv
>
>
> Table header in Properties for OpenShift 3 resources can be moved/resized. If I resize a header to beginning of another header, the another header is hidden and I cant resize is back or retrieve the second header with its column. See video for more details
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JBIDE-25504) Support hot deploy for workspace dependencies for SpringBoot applications on OpenShift
by Roland Huß (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25504?page=com.atlassian.jira.plugi... ]
Roland Huß commented on JBIDE-25504:
------------------------------------
[~adietish] sorry, I have no idea really. And I'm probably also not the right person to ask for as I'm not that deep into Spring (as it really looks like an intrinsis Spring Boot problem). But maybe the RHOAR guys can help here ?
> Support hot deploy for workspace dependencies for SpringBoot applications on OpenShift
> --------------------------------------------------------------------------------------
>
> Key: JBIDE-25504
> URL: https://issues.jboss.org/browse/JBIDE-25504
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.5.2.AM2
> Reporter: Jeff MAURY
> Assignee: Andre Dietisheim
> Labels: openshift, openshift_v3, server_adapter
> Fix For: 4.5.3.Final
>
> Attachments: springboot-dependencies.zip
>
>
> When a SpringBoot application is being deployed on OpenShift with the server adapter, we should support the following use case:
> * the SpringBoot app has a dependency which is avalailable in the workspace
> * when a modifiction is done on the dependency code, it should be synced to OpenShift by the server adapter
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JBDS-3846) Create container oriented perspective
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3846?page=com.atlassian.jira.plugin.... ]
Denis Golovin edited comment on JBDS-3846 at 4/4/18 11:33 PM:
--------------------------------------------------------------
[~jeffmaury]OpenShift deserves to have a dedicated Perspective, would be good to have a perspective where all related/used in relation to OpenShift Views are present. Would be good starting point for OpenShift related cheatsheets "Open OpenShift Perspective". I can help to make that happened in next release.
was (Author: dgolovin):
[~jeffmaury]IOpenShift deserves to have a dedicated Perspective, would be good to have a perspective where all related/used in relation to OpenShift Views are present. Would be good starting point for OpenShift related cheatsheets "Open OpenShift Perspective". I can help to make that happened in next release.
> Create container oriented perspective
> -------------------------------------
>
> Key: JBDS-3846
> URL: https://issues.jboss.org/browse/JBDS-3846
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Feature Request
> Components: cdk, docker, openshift
> Affects Versions: 10.0.0.Alpha1
> Reporter: Marián Labuda
> Assignee: Jeff MAURY
> Priority: Critical
> Fix For: 11.x
>
>
> At the moment we have only JBoss perspective. We should create a new, more container oriented perspective, where Docker Explorer view would be opened by default and other views should be added and aligned to satisfy user needs. Layout of perspective should be more focused on container development.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JBDS-3846) Create container oriented perspective
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3846?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-3846:
-------------------------------------
[~jeffmaury]IOpenShift deserves to have a dedicated Perspective, would be good to have a perspective where all related/used in relation to OpenShift Views are present. Would be good starting point for OpenShift related cheatsheets "Open OpenShift Perspective". I can help to make that happened in next release.
> Create container oriented perspective
> -------------------------------------
>
> Key: JBDS-3846
> URL: https://issues.jboss.org/browse/JBDS-3846
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Feature Request
> Components: cdk, docker, openshift
> Affects Versions: 10.0.0.Alpha1
> Reporter: Marián Labuda
> Assignee: Jeff MAURY
> Priority: Critical
> Fix For: 11.x
>
>
> At the moment we have only JBoss perspective. We should create a new, more container oriented perspective, where Docker Explorer view would be opened by default and other views should be added and aligned to satisfy user needs. Layout of perspective should be more focused on container development.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JBIDE-25902) OpenShift Delete Resources is not deleting all selected resources
by Denis Golovin (JIRA)
Denis Golovin created JBIDE-25902:
-------------------------------------
Summary: OpenShift Delete Resources is not deleting all selected resources
Key: JBIDE-25902
URL: https://issues.jboss.org/browse/JBIDE-25902
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: openshift
Affects Versions: 4.5.3.AM3
Environment: Windows 10 Pro
Reporter: Denis Golovin
Attachments: delete-resources.gif
Delete Resources dialog would not delete all selected resources at once. For example for jenkins service created from Jenkins docker image that would require to run dialog three times to get all jenkins service related resources deleted. It looks like it does matter in waht order resources are deleted.
!delete-resources.gif!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JBIDE-25504) Support hot deploy for workspace dependencies for SpringBoot applications on OpenShift
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25504?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-25504 at 4/4/18 5:54 PM:
------------------------------------------------------------------
[~rhuss] I get the spring-boot app restarting fine but fail to have it load classes that I'd expect to hot swap:
I run the camel spring-boot example as exploded jar. I have the camel spring-boot example classes deployed to **/deployments/BOOT-INF/classes. The dependency is present as a jar in **/deployments/BOOT-INF/lib**.
I then try to hot swap the dependency by replacing the dependency jar with an exploded version (I tried both variants, adding an exploded folder with a different name or then replacing the jar with an exploded folder that has the same name). Spring-Boot then detects the change, restarts the whole app but wont use the new classes in the dependency. It still runs the classes that it had from the jar.
I have the classpath pointing to the following:
{code}
-cp /deployments/BOOT-INF/classes/:/deployments/BOOT-INF/lib/*:/deployments/BOOT-INF/lib/:/deployments
{code}
I also have the following file in /deployments/BOOT-INF/classes/META-INF/spring-devtools.properties where I try to push project B into the restart classloader
{code}
restart.include.dependency=/dependency-.*
{code}
Do you have any idea what I a missing so that I can hot swap classes in the dependency?
was (Author: adietish):
[~rhuss] I get the spring-boot app restarting fine but fail to have it load classes that I'd expect to hot swap:
I run the camel spring-boot example as exploded jar. I am deploying the dependency as a jar to /deployments/BOOT-INF/lib as a jar initially.
I then try to hot swap the dependency by replacing the dependency jar with an exploded version (I tried both variants, adding an exploded folder with a different name or then replacing the jar with an exploded folder that has the same name). Spring-Boot then detects the change, restarts the whole app but wont use the new classes in the dependency. It still runs the classes that it had from the jar.
I have the classpath pointing to the following:
{code}
-cp /deployments/BOOT-INF/classes/:/deployments/BOOT-INF/lib/*:/deployments/BOOT-INF/lib/:/deployments
{code}
I also have the following file in /deployments/BOOT-INF/classes/META-INF/spring-devtools.properties where I try to push project B into the restart classloader
{code}
restart.include.dependency=/dependency-.*
{code}
Do you have any idea what I a missing so that I can hot swap classes in the dependency?
> Support hot deploy for workspace dependencies for SpringBoot applications on OpenShift
> --------------------------------------------------------------------------------------
>
> Key: JBIDE-25504
> URL: https://issues.jboss.org/browse/JBIDE-25504
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.5.2.AM2
> Reporter: Jeff MAURY
> Assignee: Andre Dietisheim
> Labels: openshift, openshift_v3, server_adapter
> Fix For: 4.5.3.Final
>
> Attachments: springboot-dependencies.zip
>
>
> When a SpringBoot application is being deployed on OpenShift with the server adapter, we should support the following use case:
> * the SpringBoot app has a dependency which is avalailable in the workspace
> * when a modifiction is done on the dependency code, it should be synced to OpenShift by the server adapter
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JBIDE-25504) Support hot deploy for workspace dependencies for SpringBoot applications on OpenShift
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25504?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-25504 at 4/4/18 5:52 PM:
------------------------------------------------------------------
[~rhuss] I get the spring-boot app restarting fine but fail to have it load classes that I'd expect to hot swap:
I run the camel spring-boot example as exploded jar. I am deploying the dependency as a jar to /deployments/BOOT-INF/lib as a jar initially.
I then try to hot swap the dependency by replacing the dependency jar with an exploded version (I tried both variants, adding an exploded folder with a different name or then replacing the jar with an exploded folder that has the same name). Spring-Boot then detects the change, restarts the whole app but wont use the new classes in the dependency. It still runs the classes that it had from the jar.
I have the classpath pointing to the following:
{code}
-cp /deployments/BOOT-INF/classes/:/deployments/BOOT-INF/lib/*:/deployments/BOOT-INF/lib/:/deployments
{code}
I also have the following file in /deployments/BOOT-INF/classes/META-INF/spring-devtools.properties where I try to push project B into the restart classloader
{code}
restart.include.dependency=/dependency-.*
{code}
Do you have any idea what I a missing so that I can hot swap classes in the dependency?
was (Author: adietish):
[~rhuss] I get the spring-boot app restarting fine but fail to have it load classes that I'd expect to hot swap:
I run the camel spring-boot example as exploded jar. I am deploying the dependency as a jar to /deployments/BOOT-INF/lib as a jar initially.
I then try to hot swap the dependency by replacing the dependency jar with an exploded version (I tried both variants, adding an exploded folder with a different name or then replacing the jar with an exploded folder that has the same name). Spring-Boot then detects the change, restarts the whole app but wont use the new classes in the dependency. It still runs the classes that it had from the jar.
I have the classpath pointing to the following:
-cp /deployments/BOOT-INF/classes/:/deployments/BOOT-INF/lib/*:/deployments/BOOT-INF/lib/:/deployments
I also have the following file in /deployments/BOOT-INF/classes/META-INF/spring-devtools.properties where I try to push project B into the restart classloader
restart.include.dependency=/dependency-.*
Do you have any idea what I a missing so that I can hot swap classes in the dependency?
> Support hot deploy for workspace dependencies for SpringBoot applications on OpenShift
> --------------------------------------------------------------------------------------
>
> Key: JBIDE-25504
> URL: https://issues.jboss.org/browse/JBIDE-25504
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.5.2.AM2
> Reporter: Jeff MAURY
> Assignee: Andre Dietisheim
> Labels: openshift, openshift_v3, server_adapter
> Fix For: 4.5.3.Final
>
> Attachments: springboot-dependencies.zip
>
>
> When a SpringBoot application is being deployed on OpenShift with the server adapter, we should support the following use case:
> * the SpringBoot app has a dependency which is avalailable in the workspace
> * when a modifiction is done on the dependency code, it should be synced to OpenShift by the server adapter
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JBIDE-25504) Support hot deploy for workspace dependencies for SpringBoot applications on OpenShift
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25504?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-25504:
------------------------------------------
[~rhuss] I get the spring-boot app restarting fine but fail to have it load classes that I'd expect to hot swap:
I run the camel spring-boot example as exploded jar. I am deploying the dependency as a jar to /deployments/BOOT-INF/lib as a jar initially.
I then try to hot swap the dependency by replacing the dependency jar with an exploded version (I tried both variants, adding an exploded folder with a different name or then replacing the jar with an exploded folder that has the same name). Spring-Boot then detects the change, restarts the whole app but wont use the new classes in the dependency. It still runs the classes that it had from the jar.
I have the classpath pointing to the following:
-cp /deployments/BOOT-INF/classes/:/deployments/BOOT-INF/lib/*:/deployments/BOOT-INF/lib/:/deployments
I also have the following file in /deployments/BOOT-INF/classes/META-INF/spring-devtools.properties where I try to push project B into the restart classloader
restart.include.dependency=/dependency-.*
Do you have any idea what I a missing so that I can hot swap classes in the dependency?
> Support hot deploy for workspace dependencies for SpringBoot applications on OpenShift
> --------------------------------------------------------------------------------------
>
> Key: JBIDE-25504
> URL: https://issues.jboss.org/browse/JBIDE-25504
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.5.2.AM2
> Reporter: Jeff MAURY
> Assignee: Andre Dietisheim
> Labels: openshift, openshift_v3, server_adapter
> Fix For: 4.5.3.Final
>
> Attachments: springboot-dependencies.zip
>
>
> When a SpringBoot application is being deployed on OpenShift with the server adapter, we should support the following use case:
> * the SpringBoot app has a dependency which is avalailable in the workspace
> * when a modifiction is done on the dependency code, it should be synced to OpenShift by the server adapter
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JBIDE-25901) MINISHIFT_HOME is not propagated to new detected cdk binary properly
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25901?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-25901:
---------------------------------------
[~rob.stryker] the main problem here is that you never told anybody about those choices that you made. I may admit that it makes sense, but I cannot guess how you made things work - I was operating under the assumption that we honor $MINISHIFT_HOME at all times. So when I see it not being the case what do I do? I report a bug!
So this is not about me feeling it should work one way or the other. This is about me inferring the correct behavior based on the information you gave me previously.
OK, now about minishift home. You're right that the situation is not ideal. Especially for the use case of avoiding the CLI altogether (i.e. when downloading using runtime detection) it seems to make sense to make up a unique minishift home directory for each new binary/adapter. But in another case it may be desirable. Consider this scenario: You're all set in CLI - you have your custom $MINISHIFT_HOME and a cdk binary somewhere. You start devstudio and search your cdk dir or start creating a cdk server adapter manually - in both cases it would be preferable to use the $MINISHIFT_HOME variable. So now which one is more common - to have multiple cdk adapters where we don't want to use one minishift home path for all of them OR users having $MINISHIFT_HOME setup and dealing with just one cdk binary. I'm afraid I cannot answer this one with high level of confidence, but I would guess that multiple cdk binaries/adapters is not a common setup for our end users.
One more question: Can you please some up the use cases where having $MINISHIFT_HOME will make a difference? I just did a quick test to see what happens if I have that and install devstudio and then run it. The result was that runtime detection had both paths - ~/.minishift and $MINISHIFT_HOME. Is that intended? What are the other use cases for $MINISHIFT_HOME? Thanks!
> MINISHIFT_HOME is not propagated to new detected cdk binary properly
> --------------------------------------------------------------------
>
> Key: JBIDE-25901
> URL: https://issues.jboss.org/browse/JBIDE-25901
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk, runtime-detection
> Affects Versions: 4.5.3.Final
> Reporter: Martin Malina
> Assignee: Rob Stryker
>
> Following some of the changes to how cdk and runtime detection works (most notably that path to cdk binary can now be used for searching), I wanted to try and see if $MINISHIFT_HOME is still respected and works properly. And it seems to fail.
> I started devstudio with MINISHIFT_HOME=/Users/rasp/minishift_home, then ran runtime detection against /Users/rasp/tmp where a cdk binary was found. But the newly created adapter had this set up as minishift home: /Users/rasp/tmp/MINISHIFT_HOME
> That seems totally wrong.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years