[JBoss JIRA] (JBIDE-18438) OpenShift: can complete New App Wizard without selecting gear profile
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18438?page=com.atlassian.jira.plugi... ]
Marián Labuda reassigned JBIDE-18438:
-------------------------------------
Assignee: (was: Marián Labuda)
> OpenShift: can complete New App Wizard without selecting gear profile
> ---------------------------------------------------------------------
>
> Key: JBIDE-18438
> URL: https://issues.jboss.org/browse/JBIDE-18438
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.2.0.CR1
> Reporter: Michelle Murray
> Priority: Minor
> Fix For: LATER
>
>
> In New OpenShift Application wizard, on page where select 'Gear Profile' - this field is initially blank and user can leave it blank and still successfully complete the wizard. So it works.
> But I don't think it is a good user experience. User should not be able to move to next page until there is a value in this field. Perhaps this field should have a value to start with instead of being blank based on the users account?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (JBIDE-10650) EGitUtils is too large, needs to be split into smaller parts
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-10650?page=com.atlassian.jira.plugi... ]
Marián Labuda reassigned JBIDE-10650:
-------------------------------------
Assignee: (was: Marián Labuda)
> EGitUtils is too large, needs to be split into smaller parts
> ------------------------------------------------------------
>
> Key: JBIDE-10650
> URL: https://issues.jboss.org/browse/JBIDE-10650
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 3.3.0.M5
> Reporter: Andre Dietisheim
> Fix For: LATER
>
>
> EGitUtils is a collection of handy utilities to simplify tasks when dealing with EGit/JGit in OpenShift. It holds all its functionality in static methods. The class grew up to > 800 lines in its current incarnation. This is by far too large to be maintained effectively. We need to split it up into smaller parts (into commands? into several util classes?)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (JBIDE-20100) how to make users aware of fuse and other tooling only being available from earlyaccess?
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20100?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-20100:
----------------------------------------
A-B) So far, it doesn't tell user when no connector exists. As reading the initial comment from [~jtyrrell], both story of Early-Access visibility and unexisting connector seem not so correlated. The proposal I made earlier (for which I have a first iteration almost ready) only address the 1st part.
B) I don't understand the user story here. We should always recommend people to use the newest JBDS, and if we have a version of Fuse supported against a lower version of JBDS, isn't it expected to work on the newer one too? Not doing that is IMO a big risk of confusing users, or blocking them to old release and making the amount of maintained/tested combinations grow too much for no real benefit.
C) I'll attach a screenshot when I make the PR.
> how to make users aware of fuse and other tooling only being available from earlyaccess?
> -----------------------------------------------------------------------------------------
>
> Key: JBIDE-20100
> URL: https://issues.jboss.org/browse/JBIDE-20100
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: central
> Reporter: Max Rydahl Andersen
> Assignee: Mickael Istria
> Fix For: 4.3.0.CR1
>
>
> [~jtyrrell] find it confusing when he cannot see Fuse and other earlyaccess features immediately on the install page.
> Some comments:
> "I install JBDS 8.1 and click on the JBoss Integration and SOA Development, but where is the Fuse tooling in that list."
> "<without earlyaccess> why doesn’t my screen shot tell me to use an older version of JBDS or something."
> Suggestion:
> "when I picked the Integration Stack a greyed out Fuse IDE thingy in the list of choices, and something like (Select early Access) to enable this feature."
> I'm fine exploring options to show early access features more prominently but would prefer we would not need to treat Fuse "special" so maybe we should have a "Early Access" section at the bottom instead of filtered in between everything else ?
> and for any connectors that has additional/different features just add a "Extra features available in Early access " comment ?
> But what to do when Fuse or others dont even have an earlyaccess out yet ? (like is currently the state for devstudio 9)
> [~crobson], [~aileenc] and [~lhein] got any suggestions ?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (JBIDE-20153) Docker server adapter
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20153?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-20153:
---------------------------------------------
Yes, I don't expect this to be *in* GA; but I do expect we start figuring out how to make this available.
> Docker server adapter
> ---------------------
>
> Key: JBIDE-20153
> URL: https://issues.jboss.org/browse/JBIDE-20153
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: docker, server
> Reporter: Max Rydahl Andersen
> Assignee: Rob Stryker
> Priority: Critical
> Fix For: 4.3.x, 4.4.x
>
>
> I've been wondering for a time what would be the best way to integrate docker with our server adapters.
> I initially first thought it should be an additional profile to the existing local or remote profiles - but I think that option actually ends up being too limiting. To start - the server inside the docker then is assumed to always be a wildfly server; and I think for docker that is too limiting.
> Watching Eclipse Che demo at EclipseCon I realized their approach for "Runners" actually fits perfectly.
> What they do is that they don't actually have any insight into what servers they are running - they simply just have an associated DockerFile for a "runner" which they build and then run before launching.
> Once launched they then know where the server port is, where the possible debug port is, where files are mounted etc.
> So this Docker Server Adapter can be made to run *any* kind of application.
> WildFly, Tomcat, Python, even plain java apps.
> And actually it is not just a DockerFile that is associated with the run but a templated dockerfile. A file where certain variables will be replaced; like:
> {code}
> VOLUME /deployments
> ADD $app$ /deployments
> {code}
> will add the packaged app (i.e. wonka.war) into the /deployments folder and /deployments is mounted.
> And actually the /deployments can then be updated incrementally if wanted to.
> Even greater is that if we could support the same syntax and semantics of the templating we can simply reuse the templates defined by Che at https://github.com/codenvy/dockerfiles/
> You can see more complete info on what codenvy/che does http://docs.codenvy.com/user/builders-and-runners/#custom-machines
> This would cover all the usecases I can currently think of with launching docker from eclipse - but not be tied to any specific server type.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (JBIDE-20100) how to make users aware of fuse and other tooling only being available from earlyaccess?
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20100?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-20100:
---------------------------------------------
[~mickael_istria] not a bad idea.
Two things:
A) this assumes there actually *are* Early access available - there won't be for all, so this does not cover the case of when it does not exist yet.
B) How do it tell users they can install devstudio X to get supported version?
C) I don't follow the last bullet point. about "moving setting to installation details page". Can you elaborate ?
> how to make users aware of fuse and other tooling only being available from earlyaccess?
> -----------------------------------------------------------------------------------------
>
> Key: JBIDE-20100
> URL: https://issues.jboss.org/browse/JBIDE-20100
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: central
> Reporter: Max Rydahl Andersen
> Assignee: Mickael Istria
> Fix For: 4.3.0.CR1
>
>
> [~jtyrrell] find it confusing when he cannot see Fuse and other earlyaccess features immediately on the install page.
> Some comments:
> "I install JBDS 8.1 and click on the JBoss Integration and SOA Development, but where is the Fuse tooling in that list."
> "<without earlyaccess> why doesn’t my screen shot tell me to use an older version of JBDS or something."
> Suggestion:
> "when I picked the Integration Stack a greyed out Fuse IDE thingy in the list of choices, and something like (Select early Access) to enable this feature."
> I'm fine exploring options to show early access features more prominently but would prefer we would not need to treat Fuse "special" so maybe we should have a "Early Access" section at the bottom instead of filtered in between everything else ?
> and for any connectors that has additional/different features just add a "Extra features available in Early access " comment ?
> But what to do when Fuse or others dont even have an earlyaccess out yet ? (like is currently the state for devstudio 9)
> [~crobson], [~aileenc] and [~lhein] got any suggestions ?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (JBDS-3490) Include capabilities preference page into jbdevstudio product
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3490?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-3490:
-------------------------------------
[~nickboldt], thanks for PR :) It seems missing dependency to eclipse bundle where ActivityCategoryPrefrencePage is located.
> Include capabilities preference page into jbdevstudio product
> -------------------------------------------------------------
>
> Key: JBDS-3490
> URL: https://issues.jboss.org/browse/JBDS-3490
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Enhancement
> Components: javascript, target-platform
> Affects Versions: 9.0.0.Beta2
> Reporter: Denis Golovin
> Assignee: Denis Golovin
> Priority: Blocker
> Fix For: 9.0.0.CR1
>
> Attachments: 3490-error.png, jbds-preferences.png
>
>
> Currently there is no way to enable/disable capabilities to see hidden nodes in preferences/properties dialogs. It might be needed as a backup to be able to debug for example tern related issues.
> Current approach is using capabilities to hide Tern category from Preferences and Properties dialogs. If something goes wrong there is no way to see preferences and properties in hidden categories, because Capabilities Preference page is not included into ibdevstudio product. Before it was included by default but in Mars release it seems moved to EPP side. For example Committer Package does not provide Capabilities preference page, but Java EE Package does.
> In current devstudio product package preferences categories looks like
> !jbds-preferences.png!
> as you see there is no Capabilities node in categories tree (1) because Capabilities preference page is not defined for jbdevstudio product and Tern node (2) is filtered out by default. It means in case of any problem with tern it is not possible do enable tern console tracing using Tern Preferences or see node.js configuration.
> It is probably should be implemented as additional feature/plugin to include it into JBDS product, but it should beexcluded from BYOE feature to avoid preferences categories conflict in case of installation BYOE feature into Java EE EPP.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (JBIDE-20402) Contribute "Deploy to Openshift" menu in Docker Tools' Image view
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20402?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich commented on JBIDE-20402:
-----------------------------------------------
PR https://github.com/jcantrill/jbosstools-openshift/pull/1 against https://github.com/jcantrill/jbosstools-openshift/tree/20402_deploy_image...
> Contribute "Deploy to Openshift" menu in Docker Tools' Image view
> -----------------------------------------------------------------
>
> Key: JBIDE-20402
> URL: https://issues.jboss.org/browse/JBIDE-20402
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.3.0.Beta2
> Reporter: Fred Bricon
> Assignee: Jeff Cantrill
> Labels: openshift_v3
> Fix For: 4.3.0.CR1
>
> Attachments: deploy image WF.bmml, deploy image WF.png, deployment_config.json, run image - screen 1.png, run image 2.png
>
>
> To make this happen we will need docker tooling to provide:
> * ports
> * env variables
> * volumes
> A user will 'deploy to openshift'...I think they might see portions of the 'run image..' menus that are attached but not all. The workflow would be:
> * Ask user about ports, additional env besides those already provided in the image, volumes,
> * Ask about # of replicas, triggers
> * tag and push image to registry (tag=repo/project/stream)
> ** repo is either assumed to be Dockerhub, or the route to the OS registry
> * create a deploymentConfig for the selected image
> * create a service for the image
> * optionally create a route
> Consider running oc new-app on an image to see what it generates
> ==================================================================
> It's possible to contribute a new menu/handler to the Docker Tooling Images view.
> We'd like to be able to select a Docker image from the Docker tooling view, right-click on it and the "Deploy to Openshift"
> The following infos are required to actually be able to deploy the selected image onto OS:
> - the local docker registry. OS will need a route to be able to access it
> - the docker hub registry
> - environment variables
> - ports
> - volumes
> The docker tooling code is available at : http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.git
> The IDockerImage is accessible from the image view : http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.git/tree/conta...
> Example of menu contribution: http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.git/tree/conta...
> Currently the search image wizard is not reusable (internal package), if needed, this will require exposing it in Docker tooling for Mars SR1
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (JBIDE-20402) Contribute "Deploy to Openshift" menu in Docker Tools' Image view
by Jeff Cantrill (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20402?page=com.atlassian.jira.plugi... ]
Jeff Cantrill commented on JBIDE-20402:
---------------------------------------
Please make a PR against https://github.com/jcantrill/openshift-restclient-java/tree/deploy_image_.... I'll merge your changes into the things I'm doing and make a final PR against upstream.
> Contribute "Deploy to Openshift" menu in Docker Tools' Image view
> -----------------------------------------------------------------
>
> Key: JBIDE-20402
> URL: https://issues.jboss.org/browse/JBIDE-20402
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.3.0.Beta2
> Reporter: Fred Bricon
> Assignee: Jeff Cantrill
> Labels: openshift_v3
> Fix For: 4.3.0.CR1
>
> Attachments: deploy image WF.bmml, deploy image WF.png, deployment_config.json, run image - screen 1.png, run image 2.png
>
>
> To make this happen we will need docker tooling to provide:
> * ports
> * env variables
> * volumes
> A user will 'deploy to openshift'...I think they might see portions of the 'run image..' menus that are attached but not all. The workflow would be:
> * Ask user about ports, additional env besides those already provided in the image, volumes,
> * Ask about # of replicas, triggers
> * tag and push image to registry (tag=repo/project/stream)
> ** repo is either assumed to be Dockerhub, or the route to the OS registry
> * create a deploymentConfig for the selected image
> * create a service for the image
> * optionally create a route
> Consider running oc new-app on an image to see what it generates
> ==================================================================
> It's possible to contribute a new menu/handler to the Docker Tooling Images view.
> We'd like to be able to select a Docker image from the Docker tooling view, right-click on it and the "Deploy to Openshift"
> The following infos are required to actually be able to deploy the selected image onto OS:
> - the local docker registry. OS will need a route to be able to access it
> - the docker hub registry
> - environment variables
> - ports
> - volumes
> The docker tooling code is available at : http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.git
> The IDockerImage is accessible from the image view : http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.git/tree/conta...
> Example of menu contribution: http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.git/tree/conta...
> Currently the search image wizard is not reusable (internal package), if needed, this will require exposing it in Docker tooling for Mars SR1
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months