[JBoss JIRA] (JBIDE-9660) Cmd+4/Forge menu should be possible to activate without having the forge shell active
by Pavol Srna (JIRA)
[ https://issues.jboss.org/browse/JBIDE-9660?page=com.atlassian.jira.plugin... ]
Pavol Srna updated JBIDE-9660:
------------------------------
Fix Version/s: 4.1.1.Alpha1
(was: 4.2.0.Alpha1)
> Cmd+4/Forge menu should be possible to activate without having the forge shell active
> -------------------------------------------------------------------------------------
>
> Key: JBIDE-9660
> URL: https://issues.jboss.org/browse/JBIDE-9660
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: forge
> Reporter: Max Rydahl Andersen
> Assignee: Koen Aers
> Fix For: 4.1.1.Alpha1
>
>
> if the forge shell only is possible to show when the forge shell is in focus then its just a fancy ctrl+space thing.
> Should be able to call it from outside of the forge UI so it becomes easily accessible.
> Challenge is though to ensure forge is in the right directory - but taking the current selection as the directory to ensure forge is operating in should be enough.
> Maybe the shell command should show the path for current selection so possible to know what context it will be executed in ?
> Possibly even provide a "breadcrumb" style ui allowing users to click on a path segment to choose at what level it will operate.
--
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, 5 months
[JBoss JIRA] (JBIDE-16108) Eclipse Preferences: Timeout preferences should not set system properties but operation specific timeout
by Andre Dietisheim (JIRA)
Andre Dietisheim created JBIDE-16108:
----------------------------------------
Summary: Eclipse Preferences: Timeout preferences should not set system properties but operation specific timeout
Key: JBIDE-16108
URL: https://issues.jboss.org/browse/JBIDE-16108
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: openshift
Affects Versions: 4.1.1.CR1
Reporter: Andre Dietisheim
Assignee: Andre Dietisheim
Fix For: 4.2.x
In JBIDE-16046 we introduced an Eclipse Preferences to set the openshift-java-clilent timeouts. These preferences currently set the lib specific system property which is not good. Consider the following usecase:
1) User launches Eclipse and has system property set to 10000 (-D): Eclipse Preferences display 10000
2) User sets preference to 1234
3) restarts Ecllipse: Preferences display 1234
3) happens because we load the value from eclipse preferences and override the system property
We should keep both separate: System property and Eclipse preferences:
We use operation specific timeouts in all Eclipse code and make the Eclipse preferences provide some value for this. Leaving the system property alone.
We should also:
* add a checkbox for "[ ] use default"
* change openshift-java-client to differentiate "no value" (<0) and value set (>=0)
* remove current hard-coded safe default in openshift-java-client, replace it by system-property we already have).
--
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, 5 months
[JBoss JIRA] (JBIDE-16109) CLONE - Cmd+4/Forge menu should be possible to activate without having the forge shell active
by Pavol Srna (JIRA)
Pavol Srna created JBIDE-16109:
----------------------------------
Summary: CLONE - Cmd+4/Forge menu should be possible to activate without having the forge shell active
Key: JBIDE-16109
URL: https://issues.jboss.org/browse/JBIDE-16109
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: forge
Reporter: Pavol Srna
Assignee: Koen Aers
Fix For: 4.1.1.Alpha1, 4.2.0.Alpha1
if the forge shell only is possible to show when the forge shell is in focus then its just a fancy ctrl+space thing.
Should be able to call it from outside of the forge UI so it becomes easily accessible.
Challenge is though to ensure forge is in the right directory - but taking the current selection as the directory to ensure forge is operating in should be enough.
Maybe the shell command should show the path for current selection so possible to know what context it will be executed in ?
Possibly even provide a "breadcrumb" style ui allowing users to click on a path segment to choose at what level it will operate.
--
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, 5 months
[JBoss JIRA] (JBIDE-16109) CLONE - Cmd+4/Forge menu should be possible to activate without having the forge shell active
by Pavol Srna (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16109?page=com.atlassian.jira.plugi... ]
Pavol Srna updated JBIDE-16109:
-------------------------------
Fix Version/s: (was: 4.1.1.Alpha1)
> CLONE - Cmd+4/Forge menu should be possible to activate without having the forge shell active
> ---------------------------------------------------------------------------------------------
>
> Key: JBIDE-16109
> URL: https://issues.jboss.org/browse/JBIDE-16109
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: forge
> Reporter: Pavol Srna
> Assignee: Koen Aers
> Fix For: 4.2.0.Alpha1
>
>
> if the forge shell only is possible to show when the forge shell is in focus then its just a fancy ctrl+space thing.
> Should be able to call it from outside of the forge UI so it becomes easily accessible.
> Challenge is though to ensure forge is in the right directory - but taking the current selection as the directory to ensure forge is operating in should be enough.
> Maybe the shell command should show the path for current selection so possible to know what context it will be executed in ?
> Possibly even provide a "breadcrumb" style ui allowing users to click on a path segment to choose at what level it will operate.
--
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, 5 months
[JBoss JIRA] (JBIDE-16107) Improve portlet component
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16107?page=com.atlassian.jira.plugi... ]
Snjezana Peco reassigned JBIDE-16107:
-------------------------------------
Assignee: Max Rydahl Andersen (was: Snjezana Peco)
Max,
Could you please comment on 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, 5 months
[JBoss JIRA] (JBIDE-16107) Improve portlet component
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16107?page=com.atlassian.jira.plugi... ]
Snjezana Peco updated JBIDE-16107:
----------------------------------
Description:
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.
was:
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?
- will we 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.
> 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: Snjezana Peco
>
> 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, 5 months
[JBoss JIRA] (JBIDE-16081) Aerogear.hybrid requires org.eclipse.debug.core [3.7.0, 3.9.0) but Luna includes 3.9.0
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16081?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-16081:
-------------------------------
Fix Version/s: 4.1.1.Final
(was: 4.1.1.CR1)
> Aerogear.hybrid requires org.eclipse.debug.core [3.7.0,3.9.0) but Luna includes 3.9.0
> -------------------------------------------------------------------------------------
>
> Key: JBIDE-16081
> URL: https://issues.jboss.org/browse/JBIDE-16081
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: aerogear-hybrid
> Affects Versions: 4.1.1.CR1
> Reporter: Nick Boldt
> Assignee: Gorkem Ercan
> Labels: respin-a
> Fix For: 4.1.1.Final, 4.2.0.Alpha1
>
> Attachments: install-all-of-JBT-into-LunaM3-except-aerogear.hybrid-error-details.png, install-all-of-JBT-into-LunaM3-except-aerogear.hybrid.png
>
>
> If org.jboss.tools.aerogear.hybrid.ios.core could be changed to depend on org.eclipse.debug.core [3.7.0,3.10.0) then it could be installed into Luna M3.
> 1. fire up Eclipse Standard Luna M3 package (eclipse-standard-luna-M3-linux-gtk-x86_64.tar.gz). Help > Install new > ...
> * http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.3... (JBT 4.1.1.CR1 TP site)
> * http://download.jboss.org/jbosstools/updates/nightly/core/4.1.kepler/ (JBT 4.1.1.CR1 Core update site)
> uncheck "group by category" then select all features, and you'll get this:
> !install-all-of-JBT-into-LunaM3-except-aerogear.hybrid.png!
> !install-all-of-JBT-into-LunaM3-except-aerogear.hybrid-error-details.png!
> {code}
> Cannot complete the install because of a conflicting dependency.
> Software being installed: JBoss Hybrid Mobile Application Development Tools (Experimental) 1.0.100.CR1-v20131116-0025-B52 (org.jboss.tools.aerogear.hybrid.feature.feature.group 1.0.100.CR1-v20131116-0025-B52)
> Software currently installed: Eclipse Standard/SDK 2.1.0.20131103-0830 (epp.package.standard 2.1.0.20131103-0830)
> Only one of the following can be installed at once:
> Debug Core 3.9.0.v20131003-1341 (org.eclipse.debug.core 3.9.0.v20131003-1341)
> Debug Core 3.9.0.v20130819-1716 (org.eclipse.debug.core 3.9.0.v20130819-1716)
> Debug Core 3.9.0.v20130731-1644 (org.eclipse.debug.core 3.9.0.v20130731-1644)
> Debug Core 3.8.0.v20130514-0954 (org.eclipse.debug.core 3.8.0.v20130514-0954)
> Cannot satisfy dependency:
> From: Eclipse Standard/SDK 2.1.0.20131103-0830 (epp.package.standard 2.1.0.20131103-0830)
> To: org.eclipse.epp.package.standard.feature.feature.group [2.1.0.20131103-0830]
> Cannot satisfy dependency:
> From: Eclipse Standard/SDK Feature 2.1.0.20131103-0830 (org.eclipse.epp.package.standard.feature.feature.group 2.1.0.20131103-0830)
> To: org.eclipse.platform.feature.group [4.4.0.v20131030-2000]
> Cannot satisfy dependency:
> From: Eclipse Platform 4.4.0.v20131030-2000 (org.eclipse.platform.feature.group 4.4.0.v20131030-2000)
> To: org.eclipse.debug.core [3.9.0.v20131003-1341]
> Cannot satisfy dependency:
> From: JBoss Hybrid Mobile Application Development Tools (Experimental) 1.0.100.CR1-v20131116-0025-B52 (org.jboss.tools.aerogear.hybrid.feature.feature.group 1.0.100.CR1-v20131116-0025-B52)
> To: org.jboss.tools.aerogear.hybrid.ios.core [1.0.100.CR1-v20131116-0025-B52]
> Cannot satisfy dependency:
> From: JBoss Hybrid Mobile App. Dev. iOS Core 1.0.100.CR1-v20131116-0025-B52 (org.jboss.tools.aerogear.hybrid.ios.core 1.0.100.CR1-v20131116-0025-B52)
> To: bundle org.eclipse.debug.core [3.7.0,3.9.0)
> {code}
--
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, 5 months
[JBoss JIRA] (JBIDE-13862) server adapter wizard: When creating adapter manually, the deploying project should be added automatically
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13862?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-13862:
-------------------------------------
Component/s: (was: server)
> 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: Andre Dietisheim
> 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, 5 months
[JBoss JIRA] (JBIDE-15934) Run on Android Device does not work on OS X
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15934?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-15934:
---------------------------------------
Sorry for the delay, I didn't have an android device at hand. But unfortunately it still does not work for me (JBDS 7.1.0.CR1a).
I created a hybrid application, connected the device (developer mode) and then tried Run on Android Device.
And I got:
'Launching myhybridproj (Android Device)' has encountered a problem.
Could not establish connection with the device. Please try again.
On second attempt I got:
Build failed... Build artifact does not exist
Maybe my android sdk is not properly configured - I will discuss with Vlado tomorrow.
> Run on Android Device does not work on OS X
> -------------------------------------------
>
> Key: JBIDE-15934
> URL: https://issues.jboss.org/browse/JBIDE-15934
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: aerogear-hybrid
> Affects Versions: 4.1.1.Beta1
> Environment: OS X Mavericks
> Latest Android SDK
> JBDS 7.1.0.Beta1
> Nexus 7
> Reporter: Martin Malina
> Assignee: Gorkem Ercan
> Fix For: 4.1.1.CR1
>
>
> Following the instructions in JBIDE-15904 I am trying to run an app on an Android Device.
> This fails for me - I get: No developer enabled android device is attached to this computer please attach your device and try again. (Punctuation is missing, btw.)
> When I try to run adb devices, I can see the device is not there. Development mode is enabled on the device and it works for Vlado on Linux.
> I found out that using Run on Android Device somehow breaks the connection with the device - before I run that, "adb devices" shows the device just fine. After I run that, the device is no longer displayed.
> We even tried to deploy the app using adb install and it worked (while the device was still connected)
--
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, 5 months
[JBoss JIRA] (JBIDE-13862) server adapter wizard: When creating adapter manually, the deploying project should be added automatically
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13862?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-13862:
-------------------------------------
Workaround Description: manually drag and drop project to the adapter.
> 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, server
> Affects Versions: 4.1.0.Alpha1
> Reporter: Stefan Bunciak
> Assignee: Andre Dietisheim
> 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, 5 months