[JBoss JIRA] (JBIDE-13882) Allow users to easily "binary deploy"
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13882?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-13882:
------------------------------------------
we discussed where to put the UI to allow to create the "skip_maven_project" marker for existing projects. We decided that the OpenShift Explorer is not the right place since its focused on the OpenShift server, the remote part. We add the marker in the local clone/project the Explorer would therefore have to look for a matching project for a given/selected OpenShift application. We opted for a context menu in 2 places:
* Project Explorer: context menu for projects with a .openshift folder: OpenShift->Skip Maven Build
* Servers view: context menu: OpenShift->Markers->Skip Maven Build
> Allow users to easily "binary deploy"
> -------------------------------------
>
> Key: JBIDE-13882
> URL: https://issues.jboss.org/browse/JBIDE-13882
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.1.0.Alpha1
> Reporter: Andre Dietisheim
> Assignee: Max Rydahl Andersen
> Labels: new_and_noteworthy
> Fix For: 4.1.0.Beta2
>
> Attachments: 2013-05-29 13.33.bmml, 2013-05-29 13.33.bmml, 2013-05-29 13.33.bmml, 2013-05-29 13.33.png
>
>
> We should have an option in the wizard that allows easy "binary only" deployment
> {quote}
> 'binary deployment only' option which will go disable the the build marker...but what do we do about the existing project content - just leave it in place I would say.{quote}
--
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, 10 months
[JBoss JIRA] (JBIDE-14832) ASTools uses deprecated runtime wizard which has been replaced
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14832?page=com.atlassian.jira.plugi... ]
Rob Stryker resolved JBIDE-14832.
---------------------------------
Resolution: Done
The entire change here was committed to runtimes. No changes were made to AS. ASTools was using the proper API to locate a 'downloader', which in this case was declared in runtimes.ui. The downloader was launching the deprecated dialog rather than the new wizard.
The 'downloader' needed to be updated, and the new wizard needed a constructor to respect previous API.
> ASTools uses deprecated runtime wizard which has been replaced
> --------------------------------------------------------------
>
> Key: JBIDE-14832
> URL: https://issues.jboss.org/browse/JBIDE-14832
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: runtime-detection, server
> Affects Versions: 4.1.0.Beta1
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.1.0.Beta2
>
>
> The download runtime wizard was replaced with a new implementation. Previously was dialogs, now is a wizard. Wizard requires additional constructor to handle the previous use case of a filter. Deprecated classes need to be removed.
--
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, 10 months
[JBoss JIRA] (JBIDE-14832) ASTools uses deprecated runtime wizard which has been replaced
by Rob Stryker (JIRA)
Rob Stryker created JBIDE-14832:
-----------------------------------
Summary: ASTools uses deprecated runtime wizard which has been replaced
Key: JBIDE-14832
URL: https://issues.jboss.org/browse/JBIDE-14832
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: runtime-detection, server
Affects Versions: 4.1.0.Beta1
Reporter: Rob Stryker
Assignee: Rob Stryker
Fix For: 4.1.0.Beta2
The download runtime wizard was replaced with a new implementation. Previously was dialogs, now is a wizard. Wizard requires additional constructor to handle the previous use case of a filter. Deprecated classes need to be removed.
--
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, 10 months
[JBoss JIRA] (JBIDE-14079) Weinre in browsersim slow/not-informative
by Konstantin Marmalyukov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14079?page=com.atlassian.jira.plugi... ]
Konstantin Marmalyukov commented on JBIDE-14079:
------------------------------------------------
[~lfryc], we had smth like holywar on jbosstools-dev where was decided that we cannot make developers to run weinre locally, so we need something to make default server working more user-friendly.
> Weinre in browsersim slow/not-informative
> -----------------------------------------
>
> Key: JBIDE-14079
> URL: https://issues.jboss.org/browse/JBIDE-14079
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: browsersim
> Reporter: Max Rydahl Andersen
> Assignee: Konstantin Marmalyukov
> Priority: Minor
> Fix For: 4.1.0.Beta2
>
>
> BrowerSim weinre seems to load *very* slowly and there is just a big white dialog shown while it do so.
> I initially thought it was broken but after 4-5 attempts it suddenly showed up.
> Problem is users has no idea what is actually going on.
> Could we:
> A) show a progress monitor (even a fake one would be useful)
> B) show what url the dialog is visiting (that gives a hint it is waiting)
> C) have a link/info button explaining you can configure weinre in preferences
> Ca) have a dialog pop up on initial start of weinre explaining it will inject weinre and go to client url X which can be configured in the preferences...and then a "Do not ask me again" checkbox for future usage.
--
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, 10 months
[JBoss JIRA] (JBIDE-14831) DownloadRuntime dialog takes too long to load
by Rob Stryker (JIRA)
Rob Stryker created JBIDE-14831:
-----------------------------------
Summary: DownloadRuntime dialog takes too long to load
Key: JBIDE-14831
URL: https://issues.jboss.org/browse/JBIDE-14831
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: runtime-detection
Affects Versions: 4.1.0.Beta2
Reporter: Rob Stryker
Assignee: Rob Stryker
Fix For: 4.1.0.Beta2
Now that there are 2 stacks files, and additional files being downloaded, loading of the runtime dialog takes much too long. It needs a progress dialog to go before 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, 10 months
[JBoss JIRA] (JBIDE-14760) Cannot connect to OpenShift Enterprise with hostname: javax.net.ssl.SSLProtocolException (WATCHER)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14760?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on JBIDE-14760:
-------------------------------------------------
Jason DeTiberus <jdetiber(a)redhat.com> made a comment on [bug 973219|https://bugzilla.redhat.com/show_bug.cgi?id=973219]
+++ This bug was initially created as a clone of Bug #970805 +++
Description of problem:
In the installation scripts and deployment guide, we do not change the ServerName setting for the broker's Apache from the default of 'localhost'. Consequently, the TLS handshake raises a warning alert. This warning alert can cause JBoss Developer Studio to report an authentication failure.
Version-Release number of selected component (if applicable):
How reproducible:
Thoroughly.
Steps to Reproduce:
1. Install a new broker host and a new node host using the installation scripts under <https://github.com/openshift/openshift-extras/blob/enterprise-1.1/enterpr...> (for OSE 1.1), the scripts under <https://github.com/openshift/openshift-extras/blob/enterprise-1.2/enterpr...> (for OSE 1.2), or the deployment guide at <https://access.redhat.com/site/documentation/en-US/OpenShift_Enterprise/1...>.
2. Run `httpd -S` on the broker host.
3. Run `tcpdump -lnni eth0 -w /tmp/tcpdump.out tcp port 443` on the broker host, run `curl -k https://broker.example.com/broker/rest/api` on a host that is remote to the broker, and run Wireshark on the resulting tcpdump.out file.
Actual results:
In Step 2, the `httpd -S` output shows 'localhost' for the virtual servers.
In Step 3, Wireshark shows "TLSv1 Alert (Level: Warning, Description: Unrecognized Name), Server Hello, Certificate" in the TLS handshake of every new connection.
Expected results:
In Step 2, the `httpd -S` output should show the configured hostnames for the virtual servers.
In Step 3, Wireshark should not show any warnings or errors in the TLS handshake.
Need to make the following Docs changes (based on the current 1.1 documentation):
Section 5.8.6.2 - Remove '-extensions v3_req' from the openssl command to generate a self signed cert.
Section 6.8.6.1 - Remove '-extensions v3_req' from the openssl command to generate a self signed cert.
Section 6.8.6.1 - Remove the duplicate line '-x509 -days 3650 -extensions v3_req \'
We also need to add a section to both the node and broker configuration to set the ServerName.
Node:
modify /etc/httpd/conf.d/000001_openshift_origin_node.conf
Change ServerName to hosts fqdn or run the following sed command
sed -i -e "s/ServerName .*$/ServerName `hostname`/" \
/etc/httpd/conf.d/000001_openshift_origin_node.conf
Broker:
modify /etc/httpd/conf.d/000002_openshift_origin_broker_servername.conf
Change ServerName to hosts fqdn or run the following sed command
sed -i -e "s/ServerName .*$/ServerName `hostname`/" \
/etc/httpd/conf.d/000002_openshift_origin_broker_servername.conf
> Cannot connect to OpenShift Enterprise with hostname: javax.net.ssl.SSLProtocolException (WATCHER)
> --------------------------------------------------------------------------------------------------
>
> Key: JBIDE-14760
> URL: https://issues.jboss.org/browse/JBIDE-14760
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.0.Beta2
> Environment: jdk7
> Reporter: jing zh
> Assignee: Andre Dietisheim
> Fix For: 4.1.0.Beta2
>
> Attachments: JBT_test.png
>
>
> If trying to connect openshift server ,it would be failed with following error shown.
> Could not verify credentials for jinzhang1: Could not request https://broker.osetestv2.com/broker/rest/api: javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name
--
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, 10 months
[JBoss JIRA] (JBIDE-14828) OpenShift application/import wizard: if git clone directory already exist i cannot do anything
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14828?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-14828:
-------------------------------------
Description:
steps to reproduce:
# EXEC: create and/or import some appliaction from OpenShift to your local workspace using the application/import wizard
# EXEC: once you have the project imported to your workspace, delete it
# EXEC: once it is deleted, go and try to re-import the very same application
Result:
The 3rd wizard page errors on the git cloning destination. You're told that the destination folder already exists within the clone destination folder. The only way out currently is to choose a different clone destination folder.
!application-folder-already-exists.png!
Expected:
It would help a lot if wizard would allow you to overwrite the existing destination. The wizard could also check if the given folder holds a prior clone and then allow one to "reuse" this folder. The given folder would then simply get imported to Eclipse and we'd fetch instead of cloning.
was:
steps to reproduce:
# EXEC: create and/or import some appliaction from OpenShift to your local workspace using the application/import wizard
# EXEC: once you have the project imported to your workspace, delete it
# EXEC: once it is deleted, go and try to re-import the very same application
Result:
The 3rd wizard page errors on the git cloning destination. You're told that the destination folder already exists within the clone destination folder. The only way out currently is to choose a different clone destination folder.
!application-folder-already-exists.png!
Expected:
It would help a lot if wizard would allow you to overwrite the existing destination. The wizard could also check if the given folder holds a prior clone and the allow one to "reuse" this folder.
> OpenShift application/import wizard: if git clone directory already exist i cannot do anything
> ----------------------------------------------------------------------------------------------
>
> Key: JBIDE-14828
> URL: https://issues.jboss.org/browse/JBIDE-14828
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.1.0.Beta2
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.1.x
>
> Attachments: application-folder-already-exists.png
>
>
> steps to reproduce:
> # EXEC: create and/or import some appliaction from OpenShift to your local workspace using the application/import wizard
> # EXEC: once you have the project imported to your workspace, delete it
> # EXEC: once it is deleted, go and try to re-import the very same application
> Result:
> The 3rd wizard page errors on the git cloning destination. You're told that the destination folder already exists within the clone destination folder. The only way out currently is to choose a different clone destination folder.
> !application-folder-already-exists.png!
> Expected:
> It would help a lot if wizard would allow you to overwrite the existing destination. The wizard could also check if the given folder holds a prior clone and then allow one to "reuse" this folder. The given folder would then simply get imported to Eclipse and we'd fetch instead of cloning.
--
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, 10 months