[JBoss JIRA] (JBDS-3755) JBDS source zip: all files have 000 permissions after unzip
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-3755?page=com.atlassian.jira.plugin.... ]
Nick Boldt updated JBDS-3755:
-----------------------------
Status: New (was: New)
Target Release: 9.1.0.GA
> JBDS source zip: all files have 000 permissions after unzip
> -----------------------------------------------------------
>
> Key: JBDS-3755
> URL: https://issues.jboss.org/browse/JBDS-3755
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: build
> Affects Versions: 9.1.0.CR1
> Reporter: Martin Malina
> Assignee: Nick Boldt
> Fix For: 9.1.0.GA
>
> Attachments: readme.png, readme2.png
>
>
> While verifying JBDS-3598 and trying to build from the latest source zip (jboss-devstudio-9.1.0.CR1-v20160326-0059-B443-src.zip), I hit a problem:
> When I unzipped the zip, I could not cd to the directory. It turned out that all the files had zero permissions. So I had to do "chmod -R 777 jboss-devstudio-9.1.0.CR1-src" first. Could we fix that?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBDS-3755) JBDS source zip: all files have 000 permissions after unzip
by CDW Engine (JIRA)
[ https://issues.jboss.org/browse/JBDS-3755?page=com.atlassian.jira.plugin.... ]
CDW Engine reassigned JBDS-3755:
--------------------------------
> JBDS source zip: all files have 000 permissions after unzip
> -----------------------------------------------------------
>
> Key: JBDS-3755
> URL: https://issues.jboss.org/browse/JBDS-3755
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: build
> Affects Versions: 9.1.0.CR1
> Reporter: Martin Malina
> Assignee: Nick Boldt
> Fix For: 9.1.0.GA
>
> Attachments: readme.png, readme2.png
>
>
> While verifying JBDS-3598 and trying to build from the latest source zip (jboss-devstudio-9.1.0.CR1-v20160326-0059-B443-src.zip), I hit a problem:
> When I unzipped the zip, I could not cd to the directory. It turned out that all the files had zero permissions. So I had to do "chmod -R 777 jboss-devstudio-9.1.0.CR1-src" first. Could we fix that?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBIDE-22105) Update AERI Server to 2.0
by Marcel Bruch (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22105?page=com.atlassian.jira.plugi... ]
Marcel Bruch commented on JBIDE-22105:
--------------------------------------
No documentation why. It's a tradeoff decision. At the end it boils down to the question which skill set is available in your team.
> Update AERI Server to 2.0
> -------------------------
>
> Key: JBIDE-22105
> URL: https://issues.jboss.org/browse/JBIDE-22105
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: aeri
> Reporter: Marcel Bruch
> Priority: Minor
>
> I'd like to roll out an update of the aeri server.
> Notable changes on for Eclipse clients:
> This update changes the sever responses send back to clients on submission of a problem report. The response format is compatible with the Eclipse AERI integration 1.100+
> No breaking changes.
> Most notable changes on the server's web-site:
> * The UI changed from AngularJS to Vaadin
> * Improved JIRA integration.
> * Improved customization of email digests and bug creation templates
> * Fine-grained control over server-responses
> * Auto-Actions for automated problem state transitions on problem state changes (e.g., _number-of-reporters > 100 && status=open --> Set Severity to major._ or _If new error reports arrived in with bundle.version > 1.2.3 --> set status=reopen.
> Details will be announced separately.
> In this bug I'm looking for a process *how* to perform an server-update for JBoss Tools.
> I'd like to know who needs to be involved in case of major/minor updates? Is some testing / approval from QE required before an update can go live?
> My proposed way of doing a major update:
> * Copy the current database.
> * Set up a sandbox instance running on the copied database
> * Create a JIRA issue for the planned update.
> * After approval by QE switch testing instance to production
> FWIW, I don't plan to announce minor bugfixes and minor improvements (e.g., to duplicate detection) as long as they do have user-observable impact or lead to significant changes in the UI and workflows.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBIDE-22105) Update AERI Server to 2.0
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22105?page=com.atlassian.jira.plugi... ]
Fred Bricon commented on JBIDE-22105:
-------------------------------------
I'm curious to know your motivations for doing the angularjs to vaadin migration. If you have that documented somewhere.
> Update AERI Server to 2.0
> -------------------------
>
> Key: JBIDE-22105
> URL: https://issues.jboss.org/browse/JBIDE-22105
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: aeri
> Reporter: Marcel Bruch
> Priority: Minor
>
> I'd like to roll out an update of the aeri server.
> Notable changes on for Eclipse clients:
> This update changes the sever responses send back to clients on submission of a problem report. The response format is compatible with the Eclipse AERI integration 1.100+
> No breaking changes.
> Most notable changes on the server's web-site:
> * The UI changed from AngularJS to Vaadin
> * Improved JIRA integration.
> * Improved customization of email digests and bug creation templates
> * Fine-grained control over server-responses
> * Auto-Actions for automated problem state transitions on problem state changes (e.g., _number-of-reporters > 100 && status=open --> Set Severity to major._ or _If new error reports arrived in with bundle.version > 1.2.3 --> set status=reopen.
> Details will be announced separately.
> In this bug I'm looking for a process *how* to perform an server-update for JBoss Tools.
> I'd like to know who needs to be involved in case of major/minor updates? Is some testing / approval from QE required before an update can go live?
> My proposed way of doing a major update:
> * Copy the current database.
> * Set up a sandbox instance running on the copied database
> * Create a JIRA issue for the planned update.
> * After approval by QE switch testing instance to production
> FWIW, I don't plan to announce minor bugfixes and minor improvements (e.g., to duplicate detection) as long as they do have user-observable impact or lead to significant changes in the UI and workflows.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBDS-3728) Assign IDs to UI elements
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3728?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-3728:
-------------------------------------
That is a good idea, we'll do it as we write tests.
> Assign IDs to UI elements
> -------------------------
>
> Key: JBDS-3728
> URL: https://issues.jboss.org/browse/JBDS-3728
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Task
> Components: installer
> Reporter: Jan Richter
> Labels: havoc, ui
> Fix For: 10.0.0.Alpha1
>
>
> The use of IDs greatly improves the lookup times and makes automated testing a lot easier. So please do include IDs in elements you create + we should add them to already existing elements that don't have any.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBIDE-22105) Update AERI Server to 2.0
by Marcel Bruch (JIRA)
Marcel Bruch created JBIDE-22105:
------------------------------------
Summary: Update AERI Server to 2.0
Key: JBIDE-22105
URL: https://issues.jboss.org/browse/JBIDE-22105
Project: Tools (JBoss Tools)
Issue Type: Task
Components: aeri
Reporter: Marcel Bruch
Priority: Minor
I'd like to roll out an update of the aeri server.
Notable changes on for Eclipse clients:
This update changes the sever responses send back to clients on submission of a problem report. The response format is compatible with the Eclipse AERI integration 1.100+
No breaking changes.
Most notable changes on the server's web-site:
* The UI changed from AngularJS to Vaadin
* Improved JIRA integration.
* Improved customization of email digests and bug creation templates
* Fine-grained control over server-responses
* Auto-Actions for automated problem state transitions on problem state changes (e.g., _number-of-reporters > 100 && status=open --> Set Severity to major._ or _If new error reports arrived in with bundle.version > 1.2.3 --> set status=reopen.
Details will be announced separately.
In this bug I'm looking for a process *how* to perform an server-update for JBoss Tools.
I'd like to know who needs to be involved in case of major/minor updates? Is some testing / approval from QE required before an update can go live?
My proposed way of doing a major update:
* Copy the current database.
* Set up a sandbox instance running on the copied database
* Create a JIRA issue for the planned update.
* After approval by QE switch testing instance to production
FWIW, I don't plan to announce minor bugfixes and minor improvements (e.g., to duplicate detection) as long as they do have user-observable impact or lead to significant changes in the UI and workflows.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBDS-3719) Initial search for an existing JBDS is present but disabled
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3719?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-3719:
-------------------------------------
That intentional, because JBDS detection is simple iteration over filesystem and might take forever. This code should be used when manually points to JBDS location to verify its real JBDS installation.
> Initial search for an existing JBDS is present but disabled
> -----------------------------------------------------------
>
> Key: JBDS-3719
> URL: https://issues.jboss.org/browse/JBDS-3719
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer
> Affects Versions: 9.1.0.CR1
> Reporter: Jan Richter
> Assignee: Denis Golovin
> Labels: havoc
> Fix For: 10.0.0.Alpha1
>
>
> The installer calls the functionality to search for an existing JBDS when the confirm page loads, but the method has a built-in check that just interrupts it. Meaning - checking an existing installation will only proceed if a folder was selected by the user, the initial search will not.
> Is this by design? If it is there is no point in initiating the search automatically.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years