[JBoss JIRA] (JBIDE-22275) oc version is not recognized
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22275?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich commented on JBIDE-22275:
-----------------------------------------------
For the message, I think it is not helping user to read 'Your OpenShift client version is 0.0.0' when actually parsing failed. Maybe if matcher.matches() returns false it is better to be logged.
> oc version is not recognized
> ----------------------------
>
> Key: JBIDE-22275
> URL: https://issues.jboss.org/browse/JBIDE-22275
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.0.Alpha1
> Reporter: Marián Labuda
> Labels: openshift_v3
> Fix For: 4.4.0.Alpha2
>
> Attachments: oc_warning.png
>
>
> Using latest oc binary (1.2.0.RC2) there is an invalid warning message in OpenShift 3 preference page. It says my version is 0.0.0 and I need at least 1.1:1, although binary is 1.2.0.
> !oc_warning.png!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBDS-3605) Rebranding to developers.redhat.com
by SJ Cox (JIRA)
[ https://issues.jboss.org/browse/JBDS-3605?page=com.atlassian.jira.plugin.... ]
SJ Cox commented on JBDS-3605:
------------------------------
[~nickboldt] Sure thing! I will get those to you early next week! Im assuming the red circle would be replaced by the Red Hat Developer bracket logo circle that I sent you a while ago?
> Rebranding to developers.redhat.com
> -----------------------------------
>
> Key: JBDS-3605
> URL: https://issues.jboss.org/browse/JBDS-3605
> Project: Red Hat Developer Studio (DevStudio)
> Issue Type: Epic
> Components: installer, p2-product
> Reporter: Max Rydahl Andersen
> Assignee: Catherine Robson
> Priority: Blocker
> Fix For: 10.0.0.Alpha1
>
> Attachments: about-jbds10.png, gettingstarted.png, gs_nav.png, header-jbds10-installer.png, icns.zip, jbds_uninstall.ico, jbeap_edit_wiz.png, jbeap_new_wiz.png, RedHatDevelopersStudio_SplashScreen.zip, RedHatDeveloperStudio-Branding_Final_2016-03-16.pdf, RedHatDeveloperStudio_BrandingDeliverables.zip, splash-jbds10.png
>
>
> Developer Studio, Central and any related installers, website content etc. is requested to be rebranded under http://developers.redhat.com.
> The visual name will change but for JBDS 9.1 we will not change things that risk breaking functionallity (i.e. changing the binary from jbds to rhds will potentially break update path, ini and p2 update mechanisms)
> Thus changing about screen, splash screens etc. are the target - more deeper rebranding will be done in future and on a case-by-base basis if at all necessary.
>
> This jira will be the epic where we add related issues.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBIDE-13671) Replace build timestamp in qualifier by last-mod-timestamp from git
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13671?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-13671 at 4/29/16 1:05 PM:
-------------------------------------------------------------
Any objections to applying my PR next week so we can get this in place for the next sprint and flesh out any problems with it?
[~dgolovin] [~maxandersen] [~akazakov] [~rob.stryker] [~mmalina] WDYT?
I'm thinking for Jenkins CI builds we should use
x.y.z.$\{BUILD_ALIAS}-vyyyyMMdd-HHmm-CI
where the timestamps come from github.
For local builds, so that OSGi sees them as newer and can therefore be installed with priority over anything else online:
x.y.z.$\{BUILD_ALIAS}-wyyyyMMdd-HHmm (note the 'w' instead of 'v')
Running this PR [1] locally I generated these plugins:
[1] https://github.com/jbosstools/jbosstools-build/pull/215
{code}
mvn clean install -DskipTests
...
# site/target/repository/plugins/org.jboss.tools.foundation.ui_1.3.0.Alpha1-w20160429-1628.jar
# site/target/repository/features/org.jboss.tools.openshift.express.feature_3.2.0.Alpha1-w20160429-1630.jar
{code}
{code}
mvn clean install -DskipTests -Phudson -DBUILD_NUMBER=1234
...
# site/target/repository/plugins/org.jboss.tools.foundation.ui_1.3.0.Alpha1-v20160420-1633-CI.jar
# site/target/repository/features/org.jboss.tools.openshift.express.feature_3.2.0.Alpha1-v20160428-2230-CI.jar
{code}
Note that I added jgit.dirtyWorkingTree=ignore. With that, we could ALSO version the locally built stuff using jgit timestamp, if we wanted [2]:
[2] https://github.com/jbosstools/jbosstools-build/pull/216
{code}
# site/target/repository/plugins/org.jboss.tools.foundation.ui_1.3.0.Alpha1-w20160420-1633.jar
{code}
So now we see the same timestamp as when built using the -Phudson profile, 20160420-1633, but with a 'w' prefix so your local bits will always win against the publishes ones.
And if I commit a change locally and rebuild, now I get the current timestamp of the change in from my local github:
{code}
# site/target/repository/plugins/org.jboss.tools.foundation.ui_1.3.0.Alpha1-w20160429-1700.jar{code}
was (Author: nickboldt):
Any objections to applying my PR next week so we can get this in place for the next sprint and flesh out any problems with it?
[~dgolovin] [~maxandersen] [~akazakov] [~rob.stryker] [~mmalina] WDYT?
I'm thinking for Jenkins CI builds we should use
x.y.z.$\{BUILD_ALIAS}-vyyyyMMdd-HHmm-CI
where the timestamps come from github.
For local builds, so that OSGi sees them as newer and can therefore be installed with priority over anything else online:
x.y.z.$\{BUILD_ALIAS}-wyyyyMMdd-HHmm (note the 'w' instead of 'v')
Running this PR [1] locally I generated these plugins:
[1] https://github.com/jbosstools/jbosstools-build/pull/215
{code}
mvn clean install -DskipTests
...
# site/target/repository/plugins/org.jboss.tools.foundation.ui_1.3.0.Alpha1-w20160429-1628.jar
# site/target/repository/features/org.jboss.tools.openshift.express.feature_3.2.0.Alpha1-w20160429-1630.jar
{code}
{code}
mvn clean install -DskipTests -Phudson -DBUILD_NUMBER=1234
...
# site/target/repository/plugins/org.jboss.tools.foundation.ui_1.3.0.Alpha1-v20160420-1633-CI.jar
# site/target/repository/features/org.jboss.tools.openshift.express.feature_3.2.0.Alpha1-v20160428-2230-CI.jar
{code}
Note that I added jgit.dirtyWorkingTree=ignore. With that, we could ALSO version the locally built stuff using jgit timestamp, if we wanted [2]:
[2] https://github.com/jbosstools/jbosstools-build/pull/216
{code}
# site/target/repository/plugins/org.jboss.tools.foundation.ui_1.3.0.Alpha1-w20160420-1633.jar
{code}
So now we see the same timestamp as when built using the -Phudson profile, 20160420-1633, but with a 'w' prefix so your local bits will always win against the publishes ones.
> Replace build timestamp in qualifier by last-mod-timestamp from git
> -------------------------------------------------------------------
>
> Key: JBIDE-13671
> URL: https://issues.jboss.org/browse/JBIDE-13671
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Affects Versions: 4.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Priority: Optional
> Fix For: 4.4.0.Alpha2
>
> Attachments: jbide13671-before-and-after.png
>
>
> This needs to be added to master parent pom:
> {code}
> <plugin>
> <groupId>org.eclipse.tycho</groupId>
> <artifactId>tycho-packaging-plugin</artifactId>
> <version>${tycho.version}</version>
> <dependencies>
> <dependency>
> <groupId>org.eclipse.tycho.extras</groupId>
> <artifactId>tycho-buildtimestamp-jgit</artifactId>
> <version>${tycho-extras.version}</version>
> </dependency>
> </dependencies>
> <configuration>
> <strictBinIncludes>false</strictBinIncludes>
> <format>'v'yyyyMMdd-HHmm</format>
> <timestampProvider>jgit</timestampProvider>
> <jgit.ignore>
> </jgit.ignore>
> </configuration>
> </plugin>
> {code}
> Ref: http://pweclipse.blogspot.ch/2012_09_01_archive.html
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBTIS-686) New Drools/jBPM Project Wizards are broken
by Paul Leacu (JIRA)
[ https://issues.jboss.org/browse/JBTIS-686?page=com.atlassian.jira.plugin.... ]
Paul Leacu commented on JBTIS-686:
----------------------------------
[~bbrodt] [~apodhrad] [~ganandan-Redhat]
Hey - okay - I'll delay respining the 9.0.0.GA until Monday.
re: Hi Andrej,
Yes, DROOLS-1149 is part of the problem. I'm confident I can have a fix before Monday - I'll keep you posted....
Bob
On Fri, Apr 29, 2016 at 10:33 AM, Andrej Podhradsky <apodhrad(a)redhat.com> wrote:
Hi Bob,
is the issue related to the missing dependencies in the project? Like https://issues.jboss.org/browse/DROOLS-1149 ?
If you are able to fix this soon then we can include the fix to the JBDS-IS 9.0.0.GA.
Is it possible to provide the fix till Monday so that QE could verify the new build on Tuesday?
Andrej
> New Drools/jBPM Project Wizards are broken
> ------------------------------------------
>
> Key: JBTIS-686
> URL: https://issues.jboss.org/browse/JBTIS-686
> Project: JBoss Tools Integration Stack
> Issue Type: Bug
> Components: drools/ jBPM
> Affects Versions: 9.0.0.GA
> Environment: Eclipse Mars, all platforms
> Reporter: Robert (Bob) Brodt
> Assignee: Robert (Bob) Brodt
> Priority: Blocker
> Fix For: 9.0.0.GA
>
>
> Regressions were introduced in 6.4.0 of the Drools/jBPM Eclipse plugins (droolsjbpm-tools project) which caused the New Project Wizards to generate sample projects that do not build or run.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBIDE-13671) Replace build timestamp in qualifier by last-mod-timestamp from git
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13671?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-13671 at 4/29/16 12:58 PM:
--------------------------------------------------------------
Any objections to applying my PR next week so we can get this in place for the next sprint and flesh out any problems with it?
[~dgolovin] [~maxandersen] [~akazakov] [~rob.stryker] [~mmalina] WDYT?
I'm thinking for Jenkins CI builds we should use
x.y.z.$\{BUILD_ALIAS}-vyyyyMMdd-HHmm-CI
where the timestamps come from github.
For local builds, so that OSGi sees them as newer and can therefore be installed with priority over anything else online:
x.y.z.$\{BUILD_ALIAS}-wyyyyMMdd-HHmm (note the 'w' instead of 'v')
Running this PR [1] locally I generated these plugins:
[1] https://github.com/jbosstools/jbosstools-build/pull/215
{code}
mvn clean install -DskipTests
...
# site/target/repository/plugins/org.jboss.tools.foundation.ui_1.3.0.Alpha1-w20160429-1628.jar
# site/target/repository/features/org.jboss.tools.openshift.express.feature_3.2.0.Alpha1-w20160429-1630.jar
{code}
{code}
mvn clean install -DskipTests -Phudson -DBUILD_NUMBER=1234
...
# site/target/repository/plugins/org.jboss.tools.foundation.ui_1.3.0.Alpha1-v20160420-1633-CI.jar
# site/target/repository/features/org.jboss.tools.openshift.express.feature_3.2.0.Alpha1-v20160428-2230-CI.jar
{code}
Note that I added jgit.dirtyWorkingTree=ignore. With that, we could ALSO version the locally built stuff using jgit timestamp, if we wanted [2]:
[2] https://github.com/jbosstools/jbosstools-build/pull/216
{code}
# site/target/repository/plugins/org.jboss.tools.foundation.ui_1.3.0.Alpha1-w20160420-1633.jar
{code}
So now we see the same timestamp as when built using the -Phudson profile, 20160420-1633, but with a 'w' prefix so your local bits will always win against the publishes ones.
was (Author: nickboldt):
Any objections to applying my PR next week so we can get this in place for the next sprint and flesh out any problems with it?
[~dgolovin] [~maxandersen] [~akazakov] [~rob.stryker] [~mmalina] WDYT?
I'm thinking for Jenkins CI builds we should use
x.y.z.${BUILD_ALIAS}-vyyyyMMdd-HHmm-CI
where the timestamps come from github.
For local builds, so that OSGi sees them as newer and can therefore be installed with priority over anything else online:
x.y.z.${BUILD_ALIAS}-wyyyyMMdd-HHmm (note the 'w' instead of 'v')
Running this PR [1] locally I generated these plugins:
[1] https://github.com/jbosstools/jbosstools-build/pull/215
{code}
mvn clean install -DskipTests
...
# site/target/repository/plugins/org.jboss.tools.foundation.ui_1.3.0.Alpha1-w20160429-1628.jar
# site/target/repository/features/org.jboss.tools.openshift.express.feature_3.2.0.Alpha1-w20160429-1630.jar
{code}
{code}
mvn clean install -DskipTests -Phudson -DBUILD_NUMBER=1234
...
# site/target/repository/plugins/org.jboss.tools.foundation.ui_1.3.0.Alpha1-v20160420-1633-CI.jar
# site/target/repository/features/org.jboss.tools.openshift.express.feature_3.2.0.Alpha1-v20160428-2230-CI.jar
{code}
Note that I added jgit.dirtyWorkingTree=ignore. With that, we could ALSO version the locally built stuff using jgit timestamp, if we wanted [2]:
[2] https://github.com/jbosstools/jbosstools-build/pull/216
{code}
# site/target/repository/plugins/org.jboss.tools.foundation.ui_1.3.0.Alpha1-w20160420-1633.jar
{code}
So now we see the same timestamp as when built using the -Phudson profile, 20160420-1633, but with a 'w' prefix so your local bits will always win against the publishes ones.
> Replace build timestamp in qualifier by last-mod-timestamp from git
> -------------------------------------------------------------------
>
> Key: JBIDE-13671
> URL: https://issues.jboss.org/browse/JBIDE-13671
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Affects Versions: 4.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Priority: Optional
> Fix For: 4.4.0.Alpha2
>
> Attachments: jbide13671-before-and-after.png
>
>
> This needs to be added to master parent pom:
> {code}
> <plugin>
> <groupId>org.eclipse.tycho</groupId>
> <artifactId>tycho-packaging-plugin</artifactId>
> <version>${tycho.version}</version>
> <dependencies>
> <dependency>
> <groupId>org.eclipse.tycho.extras</groupId>
> <artifactId>tycho-buildtimestamp-jgit</artifactId>
> <version>${tycho-extras.version}</version>
> </dependency>
> </dependencies>
> <configuration>
> <strictBinIncludes>false</strictBinIncludes>
> <format>'v'yyyyMMdd-HHmm</format>
> <timestampProvider>jgit</timestampProvider>
> <jgit.ignore>
> </jgit.ignore>
> </configuration>
> </plugin>
> {code}
> Ref: http://pweclipse.blogspot.ch/2012_09_01_archive.html
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBIDE-13671) Replace build timestamp in qualifier by last-mod-timestamp from git
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13671?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-13671:
------------------------------------
Any objections to applying my PR next week so we can get this in place for the next sprint and flesh out any problems with it?
[~dgolovin] [~maxandersen] [~akazakov] [~rob.stryker] [~mmalina] WDYT?
I'm thinking for Jenkins CI builds we should use
x.y.z.${BUILD_ALIAS}-vyyyyMMdd-HHmm-CI
where the timestamps come from github.
For local builds, so that OSGi sees them as newer and can therefore be installed with priority over anything else online:
x.y.z.${BUILD_ALIAS}-wyyyyMMdd-HHmm (note the 'w' instead of 'v')
Running this PR [1] locally I generated these plugins:
[1] https://github.com/jbosstools/jbosstools-build/pull/215
{code}
mvn clean install -DskipTests
...
# site/target/repository/plugins/org.jboss.tools.foundation.ui_1.3.0.Alpha1-w20160429-1628.jar
# site/target/repository/features/org.jboss.tools.openshift.express.feature_3.2.0.Alpha1-w20160429-1630.jar
{code}
{code}
mvn clean install -DskipTests -Phudson -DBUILD_NUMBER=1234
...
# site/target/repository/plugins/org.jboss.tools.foundation.ui_1.3.0.Alpha1-v20160420-1633-CI.jar
# site/target/repository/features/org.jboss.tools.openshift.express.feature_3.2.0.Alpha1-v20160428-2230-CI.jar
{code}
Note that I added jgit.dirtyWorkingTree=ignore. With that, we could ALSO version the locally built stuff using jgit timestamp, if we wanted [2]:
[2] https://github.com/jbosstools/jbosstools-build/pull/216
{code}
# site/target/repository/plugins/org.jboss.tools.foundation.ui_1.3.0.Alpha1-w20160420-1633.jar
{code}
So now we see the same timestamp as when built using the -Phudson profile, 20160420-1633, but with a 'w' prefix so your local bits will always win against the publishes ones.
> Replace build timestamp in qualifier by last-mod-timestamp from git
> -------------------------------------------------------------------
>
> Key: JBIDE-13671
> URL: https://issues.jboss.org/browse/JBIDE-13671
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Affects Versions: 4.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Priority: Optional
> Fix For: 4.4.0.Alpha2
>
> Attachments: jbide13671-before-and-after.png
>
>
> This needs to be added to master parent pom:
> {code}
> <plugin>
> <groupId>org.eclipse.tycho</groupId>
> <artifactId>tycho-packaging-plugin</artifactId>
> <version>${tycho.version}</version>
> <dependencies>
> <dependency>
> <groupId>org.eclipse.tycho.extras</groupId>
> <artifactId>tycho-buildtimestamp-jgit</artifactId>
> <version>${tycho-extras.version}</version>
> </dependency>
> </dependencies>
> <configuration>
> <strictBinIncludes>false</strictBinIncludes>
> <format>'v'yyyyMMdd-HHmm</format>
> <timestampProvider>jgit</timestampProvider>
> <jgit.ignore>
> </jgit.ignore>
> </configuration>
> </plugin>
> {code}
> Ref: http://pweclipse.blogspot.ch/2012_09_01_archive.html
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBIDE-22277) Auto guess Openshift connections
by Jeff MAURY (JIRA)
Jeff MAURY created JBIDE-22277:
----------------------------------
Summary: Auto guess Openshift connections
Key: JBIDE-22277
URL: https://issues.jboss.org/browse/JBIDE-22277
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: openshift
Affects Versions: 4.4.0.Alpha1
Reporter: Jeff MAURY
Priority: Minor
Fix For: 4.4.x
When creating a new Openshift connection, it would be possible to provide default values for the differents fields by looking at the $HOME/.kube/config YAML files that stores various Openshift installations the user has been connected to through the Openshift oc client.
The same feature exists in the Docker tooling so this might be interesting to have the same at the Openshift side.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBIDE-22272) NPE when using LaunchBar to run an app on WildFly
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22272?page=com.atlassian.jira.plugi... ]
Fred Bricon updated JBIDE-22272:
--------------------------------
Fix Version/s: 4.4.x
> NPE when using LaunchBar to run an app on WildFly
> -------------------------------------------------
>
> Key: JBIDE-22272
> URL: https://issues.jboss.org/browse/JBIDE-22272
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.4.0.Alpha1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.4.x
>
>
> I tried to run jboss java ee web app from Central on WildFly 10 using launchbar. And it did work, but a NPE was thrown:
> {code}
> Plug-in: org.eclipse.debug.core
> An exception occurred during launch change notification.
> java.lang.NullPointerException
> at org.jboss.tools.wtp.server.launchbar.ModuleLaunchConfigurationProvider.getLaunchConfiguration(ModuleLaunchConfigurationProvider.java:84)
> at org.jboss.tools.wtp.server.launchbar.ModuleLaunchConfigurationProvider.launchDescriptorMatches(ModuleLaunchConfigurationProvider.java:128)
> at org.eclipse.launchbar.core.internal.LaunchBarManager.launchDescriptorMatches(LaunchBarManager.java:964)
> at org.eclipse.launchbar.core.internal.LaunchBarManager.getLaunchDescriptor(LaunchBarManager.java:942)
> at org.eclipse.launchbar.core.internal.LaunchBarManager.setActive(LaunchBarManager.java:424)
> at org.eclipse.launchbar.core.internal.LaunchBarManager.access$0(LaunchBarManager.java:423)
> at org.eclipse.launchbar.core.internal.LaunchBarManager$2.launchAdded(LaunchBarManager.java:169)
> at org.eclipse.debug.internal.core.LaunchManager$LaunchNotifier.run(LaunchManager.java:446)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.debug.internal.core.LaunchManager$LaunchNotifier.notify(LaunchManager.java:433)
> at org.eclipse.debug.internal.core.LaunchManager.fireUpdate(LaunchManager.java:1043)
> at org.eclipse.debug.internal.core.LaunchManager.addLaunch(LaunchManager.java:703)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:834)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:739)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:731)
> at org.eclipse.wst.server.core.internal.Server.startImpl2(Server.java:3556)
> at org.eclipse.wst.server.core.internal.Server.startImpl(Server.java:3492)
> at org.eclipse.wst.server.core.internal.Server$StartJob.run(Server.java:367)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBIDE-22276) Server Adapter Wizard, Application Wizard: Browse... button should be Workspace... button
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22276?page=com.atlassian.jira.plugi... ]
Fred Bricon updated JBIDE-22276:
--------------------------------
Fix Version/s: 4.4.x
Story Points: 1
> Server Adapter Wizard, Application Wizard: Browse... button should be Workspace... button
> -----------------------------------------------------------------------------------------
>
> Key: JBIDE-22276
> URL: https://issues.jboss.org/browse/JBIDE-22276
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.0.Alpha1
> Reporter: Marián Labuda
> Priority: Minor
> Labels: application_wizard, openshift_v3, server_adapter_wizard
> Fix For: 4.4.x
>
>
> In New OpenShift Server Adapter wizard there is a text widget for Eclipse project. Next to it there is a Browse... button which allow to select an eclipse project from workspace.
> IN New OpenShift Application Wizard there is a text widget for Eclipse project to be used for a new application. Next to it there is a Browse... button which allow to select an eclipse project from workspace. (On the same wizard page user can select a template from local file system/workspace and there we use correct buttons.)
> Earlier we were using Browse... button for real browsing using native file browser/chooser. Now we use it for selecting a project from workspace.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months