[JBoss JIRA] (JBIDE-16142) BrowserSim: enable use of a custom skin
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16142?page=com.atlassian.jira.plugi... ]
Ilya Buziuk reassigned JBIDE-16142:
-----------------------------------
Assignee: Ilya Buziuk
> BrowserSim: enable use of a custom skin
> ---------------------------------------
>
> Key: JBIDE-16142
> URL: https://issues.jboss.org/browse/JBIDE-16142
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: browsersim
> Affects Versions: 4.1.1.CR1
> Reporter: Michelle Murray
> Assignee: Ilya Buziuk
>
> Open BrowserSim simulated device. Right-click device and click Preferences. For devices, click Add. In last field of Add Device wizard user selects a skin from a predefined list.
> User should be able to select to upload a custom skin. For example they might have their own skin for a pink iPhone 5c or some other shiny new phone.
> I guess the issue in including this feature might be activating functionality for buttons on the front of the skin? Perhaps that's why it hasn't been done?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JBIDE-16107) Improve portlet component
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16107?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-16107:
---------------------------------------------
Nice writeup - for now portal team is not that focused on wfk integration in JPP 6 and it is unsure to me where things are going. For now I would wait before we do big changes to this.
> Improve portlet component
> -------------------------
>
> Key: JBIDE-16107
> URL: https://issues.jboss.org/browse/JBIDE-16107
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: portal-gatein
> Affects Versions: 4.1.1.CR1
> Reporter: Snjezana Peco
> Assignee: Max Rydahl Andersen
>
> Currently, the portlet component supports (or it should support) the following runtimes:
> - JBoss Portal 2.7
> - EPP 4.3/5.0/5.1/5.2
> - GateIn 3.x
> - JPP 6.x
> There are three facets:
> - Java Portlet
> - JSF Portlet
> - Seam Portlet
> The required libraries are the following:
> Java Portlet
> - requires portlet-api that is, currently, correctly recognized for some of the above mentioned runtimes.
> However, there is no rule how this library would be recognized, which means it could be broken in some new runtime.
> JSF Portlet
> - requires portletbridge and, optionaly, richfaces libraries
> Those libraries can be added from the server runtimes or a user can use his own distribution that can be added to the JSF Portlet wizard page.
> If a user creates a Seam portlet and selects his richfaces distribution, the richfaces libraries added with the seam facet will be replaced with the user's library because we can't have two richfaces versions in the application.
> If a user doesn't select his richfaces distribution, the richfaces libraries from Seam will be used.
> Currently, there is no rule for adding those libraries. Different server runtimes contain the libraries in different locations. Portletbridge and richfaces distributions also have different structure.
> Seam Portlet
> The Seam portlet uses the standard seam facet and configures web.xml.
> I have tried to deploy and run the seam portlet on JPP 6.1 using the Seam 2.3.2 version from WFK.
> It can be deployed and run. The home page is opened, but I am not sure if all the features work correctly.
> Seam 2.3.2 works properly on EAP 6.1, AS 7.1.1, AS 7.2.0.Final.
> Seam 2.3.1 (the latest community version) requires adding the guava module to the jboss-deployment-structure.xml.
> If a user selects the JBoss Maven Integration facet, the portlet component will create a maven project. It is possible to add portletbridge 2.0.0 as a maven artifact.
> We would probably have to improve this feature.
> We would have to define the following:
> - what server runtimes we want to support in the future (AS 7+ runtimes GateIn 3.5/3.6, JPP
> - what kinds of portlets we would support(Java portlet, JSF portlet, JSF Richfaces... not sure for Seam)
> - how the required libraries (portletbridge, richfaces...) would be added. Is there a rule how they are placed to the server?
> - if we will support only a mavenized portlet (all GateIn 3.6, JPP 6.1 quickstarts are maven projects)
> If we decide to support only mavenized portlets, adding libraries would be much simpler. A user would only need to choose versions, i.e., to define different Maven libraries containers.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JBIDE-16143) BrowserSim: touch events options should have same wording
by Konstantin Marmalyukov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16143?page=com.atlassian.jira.plugi... ]
Konstantin Marmalyukov commented on JBIDE-16143:
------------------------------------------------
1. Yes, we decide to male this point available via preferences.
2. Ok, I miss this thing, will be fixed. Thank you.
> BrowserSim: touch events options should have same wording
> ---------------------------------------------------------
>
> Key: JBIDE-16143
> URL: https://issues.jboss.org/browse/JBIDE-16143
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: browsersim
> Affects Versions: 4.1.1.CR1
> Reporter: Michelle Murray
> Assignee: Konstantin Marmalyukov
>
> In BrowserSim there are two options for enabling touch events. For example, when using skins:
> * Right-click device and click *Enable Touch Events*
> * Right-click device, click preferences and on settings tab select *Emulate Touch Events* check box
> 1) Does this activation option need to be listed in both of these places?
> 2) If it is needed twice, the two names should read the same thing. I would suggest 'Enable Touch Events' is best.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JBIDE-16143) BrowserSim: touch events options should have same wording
by Konstantin Marmalyukov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16143?page=com.atlassian.jira.plugi... ]
Konstantin Marmalyukov reassigned JBIDE-16143:
----------------------------------------------
Assignee: Konstantin Marmalyukov
> BrowserSim: touch events options should have same wording
> ---------------------------------------------------------
>
> Key: JBIDE-16143
> URL: https://issues.jboss.org/browse/JBIDE-16143
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: browsersim
> Affects Versions: 4.1.1.CR1
> Reporter: Michelle Murray
> Assignee: Konstantin Marmalyukov
>
> In BrowserSim there are two options for enabling touch events. For example, when using skins:
> * Right-click device and click *Enable Touch Events*
> * Right-click device, click preferences and on settings tab select *Emulate Touch Events* check box
> 1) Does this activation option need to be listed in both of these places?
> 2) If it is needed twice, the two names should read the same thing. I would suggest 'Enable Touch Events' is best.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JBIDE-16100) OpenShift time out preference should show default 240 seconds and not 0
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16100?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-16100:
------------------------------------------
The default in the preferences pages is 0. If we have 0 in the text-field we're not providing a timeout. The client will then fall back to a default of 2 minutes (see 4 above).
> OpenShift time out preference should show default 240 seconds and not 0
> -----------------------------------------------------------------------
>
> Key: JBIDE-16100
> URL: https://issues.jboss.org/browse/JBIDE-16100
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.1.CR1
> Environment: Version: 7.1.0.CR1
> Build id: CR1-v20131124-0717-B560
> Build date: 20131124-0717
> Reporter: Michelle Murray
> Assignee: Max Rydahl Andersen
> Attachments: OpenShift_deftimeout.png
>
>
> Click Window > Preferences > JBoss Tools > OpenShift.
> Remote requests time out field states '0'.
> !OpenShift_deftimeout.png!
> If the default time out is 240 seconds (as stated in N&N) and I haven't changed the default time out, then this should read 240 - right?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JBIDE-15622) Automatically open/send report when log has error
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15622?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-15622:
---------------------------------------------
I got various input to the dialog suggestions but my biggest questions are outside the dialog:
A) how are duplicates going to be located ? How does netbeans ?
B) how do we/netbeans avoid duplicates being reported once the issue is known to be solved ?
> Automatically open/send report when log has error
> -------------------------------------------------
>
> Key: JBIDE-15622
> URL: https://issues.jboss.org/browse/JBIDE-15622
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: common/jst/core
> Affects Versions: 4.1.1.Alpha1
> Reporter: Mickael Istria
> Attachments: ReportBugStep2.bmml, ReportBugStep2.bmml, ReportBugStep2.bmml, ReportBugStep2.bmml, ReportBugStep2.png, ReportBugStep3.bmml, ReportBugStep3.bmml, ReportBugStep3.bmml, ReportBugStep3.bmml, ReportBugStep3.bmml, ReportBugStep3.png, ReportBugStep3SourceView.bmml, ReportBugStep3SourceView.bmml, ReportBugStep3SourceView.bmml, ReportBugStep3SourceView.png, ReportError1.bmml, ReportError1.bmml, ReportError1.bmml, ReportError1.png, ResultPage.bmml, ResultPage.png
>
>
> Step 1:
> !ReportError1.png!
> Step 2:
> !ReportBugStep3.png!
> !ReportBugStep3SourceView.png!
> Step 3:
> !ReportBugStep2.png!
> Result Page:
> !ResultPage.png!
> *Where to:*
> 1. Error Dialog (Steps 1,2,3) – when problem occurs Error Dialog appears and provides opportunity to report a bug
> 2. Error Log View (Steps 2,3) (Tool-bar, Menu, Context menu) – report problem for selected stack-trace
> 3. Help->Report Problem Dialog (Steps 2,3) – report problem which may be not related with any exceptions
> 1. We should filter this dialog appearance by Severity, by Existence (local in log file and remote in JIRA), by Time (not often then one time in a minute, in case of crash where could be a lot of exceptions in short period of time). Offer automatic send report?
> 1. and 2. should create issues in “special” project (see Preconditions). 3. may create issues directly to project Tools (JBoss Tools)?
> *Feature list:*
> 1. Log in/Anonymous bug reporting (If the user has login to JIRA he can report issues with it. Or he can do it anonymously)
> 2. Check Exception Stack-trace for duplicate
> 3. Report should contain all needed (useful) information about user's environment (JDK/JRE version, eclipse version, OS version, configuration, etc)
> 4. As much as possible fields should be filled up automatically (project, issue type, priority, component/s, affects version/s, environment) may be some of them should be filled up later by Administrator
> 5. User should be able to see all the data he is going to send (see tab "Source View")
> 6. Show communication errors
> 7. Return link to created JIRA
> 8. Inform user about the general/common process of bug reporting (see Work-flow)
> 9. Option to attach log file
> 10. Option to attach screen-shot
> *Preconditions:*
> 1. We need to create “special” project in JIRA to primary report issue to with anonymous (or dedicated) user.
> 2. We need person as Administrator (QE-?) to periodically verifying issue from “special” project.
> *Work-flow:*
> 1. User decides/agrees to report the problem (see list Where to)
> 2. Report Problem dialog appears, user fills up the form
> 2. Dialog checks for existing exception stack-traces (when stack-trace available) or by key-words from field summary.
> 3. If validation passes dialog creates issue in “special” project of JIRA (see Preconditions)
> 4. User gets link to created issue and short description of what will happen next. (features 7. 8.)
> 5. Administrator should periodically check “special” project and verify all issues. Administrator may reject issue or correct (versions, components etc, if needed) and move to project Tools (JBoss Tools).
> *Primary Description:*
> JBT should set up an ILogListener on the Eclipse log and send an error report whenever something is logged as error.
> As it's probably not possible to send the error report without asking users, it should show the "Report problem" page.
> NetBeans does that and has reported an actual quality benefit.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JBIDE-15935) Android SDK not installed automatically on OS X
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15935?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-15935:
---------------------------------------------
thanks [~vpakan]. I added a pointer back to here so ADT team could get some screenshots of the issue.
> Android SDK not installed automatically on OS X
> -----------------------------------------------
>
> Key: JBIDE-15935
> URL: https://issues.jboss.org/browse/JBIDE-15935
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: aerogear-hybrid, upstream
> Affects Versions: 4.1.1.Beta1
> Environment: JBDS 7.1.0.Beta1
> OS X Mavericks
> Reporter: Martin Malina
> Assignee: Vlado Pakan
> Fix For: 4.1.x, 4.2.x
>
> Attachments: android-sdk.png, Central_AndTools.png, installadk.png
>
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> When I install android tools from central and then I restart the IDE as requested, I should be asked to automatically download and install Android SDK (I got word it works this way on Linux). I got nothing like that on OS X.
> So I had to download and setup SDK manually.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JBIDE-16128) Publish component sites to Nexus
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16128?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-16128:
----------------------------------------
> With respect to next steps - Mickael Istria are you just suggesting we enabled mvn deploy towards snapshot repo in jenkins build to see what happens ?
> Not really sure what that will give us that a basic manual mvn deploy would not do ?
I agree that very first step would be a manual deploy to Nexus.
The goal of publishing to Nexus on all component jobs (and multiple streams) is to make it clear that if we go for Nexus, dev have to carefully maintain the version of the projet.
> Publish component sites to Nexus
> --------------------------------
>
> Key: JBIDE-16128
> URL: https://issues.jboss.org/browse/JBIDE-16128
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Fix For: 4.2.0.Alpha1
>
>
> In order to get a first idea of how easy/difficult it would be to rely on Nexus for publication,we could simply start by configuring CI jobs to also run a "mvn deploy" to deploy the output p2 repository onto Nexus.
> Then we'll see what are the pros/cons of this approach.
> Current publication process and locations will be kept. These p2 repo on Nexus won't be consumed by aggregator, at least not until we are sure it's worth it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JBIDE-13862) server adapter wizard: When creating adapter manually, the deploying project should be added automatically
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13862?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-13862:
---------------------------------------------
I don't understand why it should not be added. if it is not added as a module where would the run as and show in and other actions that is related to that module be shown ?
> server adapter wizard: When creating adapter manually, the deploying project should be added automatically
> ----------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-13862
> URL: https://issues.jboss.org/browse/JBIDE-13862
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.0.Alpha1
> Reporter: Stefan Bunciak
> Assignee: Max Rydahl Andersen
> Priority: Minor
> Fix For: 4.2.x
>
> Attachments: server.png, server1.png, server2.png
>
>
> Deploying project is automatically added to OpenShift Server adapter after application import:
> * after application import contains the deploying project: !server.png|thumbnail!
> When created manually via OpenShift Explorer (Application - Create Server Adapter), the deploying project is not automatically added, even though I'm selecting the deploying project:
> * !server2.png|thumbnail! *->* !server1.png|thumbnail!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months