[JBoss JIRA] (ERT-323) Registry Account Unavailable In Preferences
by Trevor Trevor (JIRA)
[ https://issues.jboss.org/browse/ERT-323?page=com.atlassian.jira.plugin.sy... ]
Trevor Trevor commented on ERT-323:
-----------------------------------
Docker Tooling was installed from the Eclipse Marketplace.
Installed Software shows Docker Tooling 1.2.0.
When looking at Plug-ins, I can actually see that version 2.0.0 was also installed. To be more precise, only the Docker Core Plugin 2.0.0 was installed, the UI Plug-in, Tooling Documentation are at 1.2.0, and the 1.2.0 core plugin was also installed.
So, perhaps this is really an issue with installation from the Eclipse Marketplace and having started on Eclipse Mars, once an update is run, it is actually 2.0.0, and everything is happier.
> Registry Account Unavailable In Preferences
> -------------------------------------------
>
> Key: ERT-323
> URL: https://issues.jboss.org/browse/ERT-323
> Project: Eclipse Release Train
> Issue Type: Bug
> Components: Linux Tools
> Affects Versions: Mars.2 (4.5), Neon (4.6)
> Environment: Windows 7 Enterprise 64-bit
> 64-bit Eclipse
> Reporter: Trevor Trevor
> Attachments: no_registry_account.png
>
>
> According to the [user guide|https://wiki.eclipse.org/Linux_Tools_Project/Docker_Tooling/User_Guide] "By default, the Docker Hub registry will be used, however, a user may specify an additional private registry if desired. Additional registries are added using Windows -> Preferences -> Docker -> Registry Accounts."
> However, the only things available under Docker are "Docker Machine," and "Logging"; "Registry Accounts" is not present. I have observed this on both Eclipse Neon and Mars, and on a different Windows 7 machine. The plugin does work to show containers and images, but this prevents me from being able to connect to private repository on my network.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22619) Decide strategy for fixversion targets in JIRA
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22619?page=com.atlassian.jira.plugi... ]
Alexey Kazakov commented on JBIDE-22619:
----------------------------------------
After further discussion with [~maxandersen], [~nickboldt], [~jeffmaury] we agreed to use M1, M2, M3, etc suffixes instead of S114, S115 or Alpha1, Beta1 ets in fix versions in JIRA, pom.xml's, etc.
> Decide strategy for fixversion targets in JIRA
> ----------------------------------------------
>
> Key: JBIDE-22619
> URL: https://issues.jboss.org/browse/JBIDE-22619
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: build
> Affects Versions: 4.4.1.S116
> Reporter: Nick Boldt
> Assignee: Alexey Kazakov
> Fix For: 4.4.1.S116
>
>
> We need to decide the strategy for milestones / fixversions in JIRA.
> One suggestion has been to align fixversions w/ sprint numbers, thus:
> * 4.4.1.S116, 4.4.1.S117, 4.4.1.S118, 4.4.1.S119, ...?
> instead of
> * 4.4.1.Alpha1, 4.4.1.Alpha2, 4.4.1.Alpha3, 4.4.1.Beta1, ... ?
> Questions/concerns:
> * what do we do for unscheduled milestones (4.5.0.Alpha1, 11.0.0.Alpha1) and placeholders (4.4.1.Final, 10.0.1.GA) ? Should we just use Alpha1 or Final/GA until we know which sprint applies?
> * whatever schema we adopt has to work with bzira and jiralint
> * any other systems that parse JIRA for integration purposes?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22641) When an Openshift connection is deleted, the secure entries are not removed
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22641?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-22641:
-------------------------------------
Labels: connection openshift_v3 secure_storage (was: connection openshift_v3)
> When an Openshift connection is deleted, the secure entries are not removed
> ---------------------------------------------------------------------------
>
> Key: JBIDE-22641
> URL: https://issues.jboss.org/browse/JBIDE-22641
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.0.Final
> Reporter: Jeff MAURY
> Priority: Critical
> Labels: connection, openshift_v3, secure_storage
>
> When a token or password is saved in secure storage for an Openshift connection, then deleting this connection will not remove this data from secure storage. Then creating a new connection with the same address will reuse this infos. This is a security breach
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22639) Opening an Openshift3 server adapter when connection does not exists anymore causes NPE
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22639?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich commented on JBIDE-22639:
-----------------------------------------------
[~jeffmaury], [~adietish], please take a look at the pull request.
Since there was already the check for null connection, the editor allows for that case. However, when connection is removed by user, could it make sense to remove also all server adapters based on that connection? If you agree, I would open an issue for that.
> Opening an Openshift3 server adapter when connection does not exists anymore causes NPE
> ---------------------------------------------------------------------------------------
>
> Key: JBIDE-22639
> URL: https://issues.jboss.org/browse/JBIDE-22639
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift, server
> Affects Versions: 4.4.0.Final
> Reporter: Jeff MAURY
> Fix For: 4.4.1.S117
>
> Attachments: screenshot-1.png
>
>
> ASSERT: create an Openshift3 connection
> ASSERT: create a server adapter from that connection
> ASSERT: delete the Openshift3 connection
> EXEC: open the server adapter
> ASSERT: NPE is thrown and dialog is displayed (see [^screenshot-1.png])
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months