[JBoss JIRA] (JBIDE-21171) Need to remove bower / npm from jboss.tools.jsdt
by Victor Rubezhny (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21171?page=com.atlassian.jira.plugi... ]
Victor Rubezhny commented on JBIDE-21171:
-----------------------------------------
[~ibuziuk] Not sure this URL is to be used for TP (it's not official M4, but an integration build), but for sure we can use it somehow in master in order to test the functionality
> Need to remove bower / npm from jboss.tools.jsdt
> ------------------------------------------------
>
> Key: JBIDE-21171
> URL: https://issues.jboss.org/browse/JBIDE-21171
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: build, nodejs
> Affects Versions: 4.3.0.Final
> Reporter: Ilya Buziuk
> Assignee: Ilya Buziuk
> Labels: new_and_noteworthy
> Fix For: 4.4.0.Alpha1
>
>
> Assuming that bower / npm were moved to eclipse jsdt - https://git.eclipse.org/r/#/c/61336/
> Need to perform a cleanup in jboss.tools.jst.jsdt repo and remove related plugins / tests / features
> Bower is in eclipse upstream and we probably will need reflect it in new & noteworthy
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBDS-3562) Prepare for 9.0.1 (9.0.0 with patched EAP 6.4.0 BZ1281963 / CVE-2015-7501)
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3562?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-3562:
-------------------------------------
The build is "Live on the production CSP" according to the ticket.
> Prepare for 9.0.1 (9.0.0 with patched EAP 6.4.0 BZ1281963 / CVE-2015-7501)
> --------------------------------------------------------------------------
>
> Key: JBDS-3562
> URL: https://issues.jboss.org/browse/JBDS-3562
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: build
> Affects Versions: 9.0.0.CVE-2015-7501-GA
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 9.0.0.CVE-2015-7501-GA
>
> Attachments: 900GAvs901GA_B6.p2diff.txt, JBDS900GA-respin_diffs__EAP640-BZ1281963.png, JBDS900GA-respin_diffs__EAP640patched-looks-the-same-as-EAP640.png, JBDS900GA-respin_diffs__EAP640patched-looks-the-same-as-EAP640__002.png, JBDS900GA-respin_diffs__google.gson_JBDSTPvsJBDSCentralTP.png, JBDS900GA-respin_diffs__google.gson_JBDSTPvsJBDSCentralTP_210_refs.png, JBDS900GA-respin_diffs__google.gson_JBDSTPvsJBDSCentralTP_224_refs.png, JBDS900GA-respin_diffs__o.e.jst.plugins.manifest.mf.png, JBDS900GA-respin_diffs__p2director.manifest.mf.png, JBDS900GA-respin_diffs__plugins_including_gson2.1.0vs.2.2.4.png, JBDS900GA-respin_diffs__readme.txt.png
>
>
> Tracker JIRA to house things to do to prepare for 9.0.1 / 9.1.0 branches & builds.
> Because JBDS 9.0.0 includes the compromised version of
> apache.commons.collections (JBDS-3560, JBDS-3561), we need to at some point respin it, which
> will include:
> a) updated JBT/JBDS target platforms 4.50.1.* and 4.51.1.*
> b) repin of JBDS update sites and installer jars
> To that end, I've created the following new branches:
> https://github.com/jbosstools/jbosstools-target-platforms/commits/4.50.1.x
> https://github.com/jbosstools/jbosstools-target-platforms/commits/4.51.1.x
> And I've bumped the version of the target platforms in the 4.50.x and
> 4.51.x branches to 4.50.2.Beta1-SNAPSHOT and 4.51.2.Beta1-SNAPSHOT,
> respectively.
> JBDS is now at version 9.1.0 in the 4.3.x branch and 9.0.1 in the
> 4.3.1.x branch.
> https://github.com/jbdevstudio/jbdevstudio-product/commits/jbosstools-4.3...
> (new, 9.0.1)
> https://github.com/jbdevstudio/jbdevstudio-product/commits/jbosstools-4.3.x
> (updated to 9.1.0)
> So, now we just need to ensure that the correct BUILD_ALIAS (CR1 for
> 9.0.1, Beta1 for 9.1.0) and target platforms are used.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBDS-3562) Prepare for 9.0.1 (9.0.0 with patched EAP 6.4.0 BZ1281963 / CVE-2015-7501)
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-3562?page=com.atlassian.jira.plugin.... ]
Nick Boldt edited comment on JBDS-3562 at 12/8/15 1:11 PM:
-----------------------------------------------------------
If the build currently staged in CSP / GG is no longer considered acceptable, I can respin it using a different JBDS update site as input to the installer build process. (I'll have to create a composite site exclusively for this process, because as has been noted already, we've never done this whole "just build the installer using previous GA bits as input" before.)
Please advise here or in DEVELOPER-1435.
I'm also unclear how we want to display this new build on tools.jboss.org. Is is a whole new release, or just a drop-in replacement for the existing JBDS 9.0.0.GA installer jar link?
was (Author: nickboldt):
TL;DR:
after spending a few days to concoct a special, one-off solution to doing a rebuild of JUST the installers (first time ever) based on a previous GA release...
even when there's an explanation in a JIRA for slight deviations from 100% identicalness, and QE accepts it and signs off on it...
some people are not satisfied and feel compelled to post snarky comments.
It would have taken less effort and time to simply state "The staged build for QE is unacceptable; we need a respin."
> Prepare for 9.0.1 (9.0.0 with patched EAP 6.4.0 BZ1281963 / CVE-2015-7501)
> --------------------------------------------------------------------------
>
> Key: JBDS-3562
> URL: https://issues.jboss.org/browse/JBDS-3562
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: build
> Affects Versions: 9.0.0.CVE-2015-7501-GA
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 9.0.0.CVE-2015-7501-GA
>
> Attachments: 900GAvs901GA_B6.p2diff.txt, JBDS900GA-respin_diffs__EAP640-BZ1281963.png, JBDS900GA-respin_diffs__EAP640patched-looks-the-same-as-EAP640.png, JBDS900GA-respin_diffs__EAP640patched-looks-the-same-as-EAP640__002.png, JBDS900GA-respin_diffs__google.gson_JBDSTPvsJBDSCentralTP.png, JBDS900GA-respin_diffs__google.gson_JBDSTPvsJBDSCentralTP_210_refs.png, JBDS900GA-respin_diffs__google.gson_JBDSTPvsJBDSCentralTP_224_refs.png, JBDS900GA-respin_diffs__o.e.jst.plugins.manifest.mf.png, JBDS900GA-respin_diffs__p2director.manifest.mf.png, JBDS900GA-respin_diffs__plugins_including_gson2.1.0vs.2.2.4.png, JBDS900GA-respin_diffs__readme.txt.png
>
>
> Tracker JIRA to house things to do to prepare for 9.0.1 / 9.1.0 branches & builds.
> Because JBDS 9.0.0 includes the compromised version of
> apache.commons.collections (JBDS-3560, JBDS-3561), we need to at some point respin it, which
> will include:
> a) updated JBT/JBDS target platforms 4.50.1.* and 4.51.1.*
> b) repin of JBDS update sites and installer jars
> To that end, I've created the following new branches:
> https://github.com/jbosstools/jbosstools-target-platforms/commits/4.50.1.x
> https://github.com/jbosstools/jbosstools-target-platforms/commits/4.51.1.x
> And I've bumped the version of the target platforms in the 4.50.x and
> 4.51.x branches to 4.50.2.Beta1-SNAPSHOT and 4.51.2.Beta1-SNAPSHOT,
> respectively.
> JBDS is now at version 9.1.0 in the 4.3.x branch and 9.0.1 in the
> 4.3.1.x branch.
> https://github.com/jbdevstudio/jbdevstudio-product/commits/jbosstools-4.3...
> (new, 9.0.1)
> https://github.com/jbdevstudio/jbdevstudio-product/commits/jbosstools-4.3.x
> (updated to 9.1.0)
> So, now we just need to ensure that the correct BUILD_ALIAS (CR1 for
> 9.0.1, Beta1 for 9.1.0) and target platforms are used.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-21194) Result from adbinfo on windows has different syntax
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21194?page=com.atlassian.jira.plugi... ]
Rob Stryker resolved JBIDE-21194.
---------------------------------
Resolution: Done
I'm not exactly sure how to answer this question. We're running "vagrant adbinfo" which does not actually export the environment variables. It instructs the USER to export them. Otherwise we'd need to run something like "vagrant adbinfo | sh"
Furthermore, this won't modify the environment variables of already running processes. So the eclipse environment wont ever actually be updated at any point, and the "vagrant adbinfo" or "vagrant adbinfo | sh" type processes will already be terminated and thus have no environment.
I suppose I *could* run "vagrant adbinfo | sh" and then run a NEW simple java program which sysouts all environment variables, the way jdt launching does to determine what version fo the VM belongs to what execution envuronment, but that seems extremely circular logic and very wrong to me.
The fact is, there's no way for me to simply execute adbinfo and have the eclipse environment updated. It will only update new processes, not processes that already have an enviuronment.
> Result from adbinfo on windows has different syntax
> ---------------------------------------------------
>
> Key: JBIDE-21194
> URL: https://issues.jboss.org/browse/JBIDE-21194
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: openshift, server
> Affects Versions: 4.3.0.Beta1
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.3.1.Beta1, 4.4.0.Alpha1
>
>
> The result from adbinfo on linux is:
> {code}
> export key=value
> {code}
> The result on Windows is:
> {code}
> setx key value
> {code}
> The adbinfo runner needs to be aware of this difference and react accordingly when creating the openshift connection.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBDS-3562) Prepare for 9.0.1 (9.0.0 with patched EAP 6.4.0 BZ1281963 / CVE-2015-7501)
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3562?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-3562:
-------------------------------------------
The satire comment was not meant to be snarky. It was to illustrate the point of if builds were 100% good we would not have these back and forth discussions.
[~mmalina] next time we are in a similar suggestion I recommend QE to reject such a release and let engineering take a second look to see if we can make it proper. If there then are issues that either are unsolvable or too expensive to fix then lets consider doing the release for it.
> Prepare for 9.0.1 (9.0.0 with patched EAP 6.4.0 BZ1281963 / CVE-2015-7501)
> --------------------------------------------------------------------------
>
> Key: JBDS-3562
> URL: https://issues.jboss.org/browse/JBDS-3562
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: build
> Affects Versions: 9.0.0.CVE-2015-7501-GA
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 9.0.0.CVE-2015-7501-GA
>
> Attachments: 900GAvs901GA_B6.p2diff.txt, JBDS900GA-respin_diffs__EAP640-BZ1281963.png, JBDS900GA-respin_diffs__EAP640patched-looks-the-same-as-EAP640.png, JBDS900GA-respin_diffs__EAP640patched-looks-the-same-as-EAP640__002.png, JBDS900GA-respin_diffs__google.gson_JBDSTPvsJBDSCentralTP.png, JBDS900GA-respin_diffs__google.gson_JBDSTPvsJBDSCentralTP_210_refs.png, JBDS900GA-respin_diffs__google.gson_JBDSTPvsJBDSCentralTP_224_refs.png, JBDS900GA-respin_diffs__o.e.jst.plugins.manifest.mf.png, JBDS900GA-respin_diffs__p2director.manifest.mf.png, JBDS900GA-respin_diffs__plugins_including_gson2.1.0vs.2.2.4.png, JBDS900GA-respin_diffs__readme.txt.png
>
>
> Tracker JIRA to house things to do to prepare for 9.0.1 / 9.1.0 branches & builds.
> Because JBDS 9.0.0 includes the compromised version of
> apache.commons.collections (JBDS-3560, JBDS-3561), we need to at some point respin it, which
> will include:
> a) updated JBT/JBDS target platforms 4.50.1.* and 4.51.1.*
> b) repin of JBDS update sites and installer jars
> To that end, I've created the following new branches:
> https://github.com/jbosstools/jbosstools-target-platforms/commits/4.50.1.x
> https://github.com/jbosstools/jbosstools-target-platforms/commits/4.51.1.x
> And I've bumped the version of the target platforms in the 4.50.x and
> 4.51.x branches to 4.50.2.Beta1-SNAPSHOT and 4.51.2.Beta1-SNAPSHOT,
> respectively.
> JBDS is now at version 9.1.0 in the 4.3.x branch and 9.0.1 in the
> 4.3.1.x branch.
> https://github.com/jbdevstudio/jbdevstudio-product/commits/jbosstools-4.3...
> (new, 9.0.1)
> https://github.com/jbdevstudio/jbdevstudio-product/commits/jbosstools-4.3.x
> (updated to 9.1.0)
> So, now we just need to ensure that the correct BUILD_ALIAS (CR1 for
> 9.0.1, Beta1 for 9.1.0) and target platforms are used.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBDS-3562) Prepare for 9.0.1 (9.0.0 with patched EAP 6.4.0 BZ1281963 / CVE-2015-7501)
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3562?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen updated JBDS-3562:
--------------------------------------
Comment: was deleted
(was:
I asked for clarification since the jira comments was ambigious.
QE/Martin clarified.
I and Denis outlined why we should go for 100% instead of being okey with 99.99%
No snarky comments in here.)
> Prepare for 9.0.1 (9.0.0 with patched EAP 6.4.0 BZ1281963 / CVE-2015-7501)
> --------------------------------------------------------------------------
>
> Key: JBDS-3562
> URL: https://issues.jboss.org/browse/JBDS-3562
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: build
> Affects Versions: 9.0.0.CVE-2015-7501-GA
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 9.0.0.CVE-2015-7501-GA
>
> Attachments: 900GAvs901GA_B6.p2diff.txt, JBDS900GA-respin_diffs__EAP640-BZ1281963.png, JBDS900GA-respin_diffs__EAP640patched-looks-the-same-as-EAP640.png, JBDS900GA-respin_diffs__EAP640patched-looks-the-same-as-EAP640__002.png, JBDS900GA-respin_diffs__google.gson_JBDSTPvsJBDSCentralTP.png, JBDS900GA-respin_diffs__google.gson_JBDSTPvsJBDSCentralTP_210_refs.png, JBDS900GA-respin_diffs__google.gson_JBDSTPvsJBDSCentralTP_224_refs.png, JBDS900GA-respin_diffs__o.e.jst.plugins.manifest.mf.png, JBDS900GA-respin_diffs__p2director.manifest.mf.png, JBDS900GA-respin_diffs__plugins_including_gson2.1.0vs.2.2.4.png, JBDS900GA-respin_diffs__readme.txt.png
>
>
> Tracker JIRA to house things to do to prepare for 9.0.1 / 9.1.0 branches & builds.
> Because JBDS 9.0.0 includes the compromised version of
> apache.commons.collections (JBDS-3560, JBDS-3561), we need to at some point respin it, which
> will include:
> a) updated JBT/JBDS target platforms 4.50.1.* and 4.51.1.*
> b) repin of JBDS update sites and installer jars
> To that end, I've created the following new branches:
> https://github.com/jbosstools/jbosstools-target-platforms/commits/4.50.1.x
> https://github.com/jbosstools/jbosstools-target-platforms/commits/4.51.1.x
> And I've bumped the version of the target platforms in the 4.50.x and
> 4.51.x branches to 4.50.2.Beta1-SNAPSHOT and 4.51.2.Beta1-SNAPSHOT,
> respectively.
> JBDS is now at version 9.1.0 in the 4.3.x branch and 9.0.1 in the
> 4.3.1.x branch.
> https://github.com/jbdevstudio/jbdevstudio-product/commits/jbosstools-4.3...
> (new, 9.0.1)
> https://github.com/jbdevstudio/jbdevstudio-product/commits/jbosstools-4.3.x
> (updated to 9.1.0)
> So, now we just need to ensure that the correct BUILD_ALIAS (CR1 for
> 9.0.1, Beta1 for 9.1.0) and target platforms are used.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-21205) Modify runtime detection to ensure a detector is only asked to initialize runtime definitions it created
by Rob Stryker (JIRA)
Rob Stryker created JBIDE-21205:
-----------------------------------
Summary: Modify runtime detection to ensure a detector is only asked to initialize runtime definitions it created
Key: JBIDE-21205
URL: https://issues.jboss.org/browse/JBIDE-21205
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: runtime-detection
Affects Versions: 4.3.0.Beta2
Reporter: Rob Stryker
Priority: Minor
See https://issues.jboss.org/browse/JBIDE-21193 for some background.
A runtime detector is asked to initialize all RuntimeDefinition objects, not just ones it created. While this "works" if you expect a detector to know all type-strings that it creates RuntimeDefinition objects using, it is still less than optimal and the workflow is a bit counter-intuitive.
Suggestion is to add a new constructor to RuntimeDefinition and add abstract method for creating those definitions to AbstractRuntimeDetectorDelegate to instantiate these definitions.
Care should be taken since this is all public API and used in Fuse, cdk, servertools, and other locations. It may not be possible to compel consumers to use the new API at all, and so the benefit may be zero.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBDS-3562) Prepare for 9.0.1 (9.0.0 with patched EAP 6.4.0 BZ1281963 / CVE-2015-7501)
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3562?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-3562:
-------------------------------------------
I asked for clarification since the jira comments was ambigious.
QE/Martin clarified.
I and Denis outlined why we should go for 100% instead of being okey with 99.99%
No snarky comments in here.
> Prepare for 9.0.1 (9.0.0 with patched EAP 6.4.0 BZ1281963 / CVE-2015-7501)
> --------------------------------------------------------------------------
>
> Key: JBDS-3562
> URL: https://issues.jboss.org/browse/JBDS-3562
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: build
> Affects Versions: 9.0.0.CVE-2015-7501-GA
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 9.0.0.CVE-2015-7501-GA
>
> Attachments: 900GAvs901GA_B6.p2diff.txt, JBDS900GA-respin_diffs__EAP640-BZ1281963.png, JBDS900GA-respin_diffs__EAP640patched-looks-the-same-as-EAP640.png, JBDS900GA-respin_diffs__EAP640patched-looks-the-same-as-EAP640__002.png, JBDS900GA-respin_diffs__google.gson_JBDSTPvsJBDSCentralTP.png, JBDS900GA-respin_diffs__google.gson_JBDSTPvsJBDSCentralTP_210_refs.png, JBDS900GA-respin_diffs__google.gson_JBDSTPvsJBDSCentralTP_224_refs.png, JBDS900GA-respin_diffs__o.e.jst.plugins.manifest.mf.png, JBDS900GA-respin_diffs__p2director.manifest.mf.png, JBDS900GA-respin_diffs__plugins_including_gson2.1.0vs.2.2.4.png, JBDS900GA-respin_diffs__readme.txt.png
>
>
> Tracker JIRA to house things to do to prepare for 9.0.1 / 9.1.0 branches & builds.
> Because JBDS 9.0.0 includes the compromised version of
> apache.commons.collections (JBDS-3560, JBDS-3561), we need to at some point respin it, which
> will include:
> a) updated JBT/JBDS target platforms 4.50.1.* and 4.51.1.*
> b) repin of JBDS update sites and installer jars
> To that end, I've created the following new branches:
> https://github.com/jbosstools/jbosstools-target-platforms/commits/4.50.1.x
> https://github.com/jbosstools/jbosstools-target-platforms/commits/4.51.1.x
> And I've bumped the version of the target platforms in the 4.50.x and
> 4.51.x branches to 4.50.2.Beta1-SNAPSHOT and 4.51.2.Beta1-SNAPSHOT,
> respectively.
> JBDS is now at version 9.1.0 in the 4.3.x branch and 9.0.1 in the
> 4.3.1.x branch.
> https://github.com/jbdevstudio/jbdevstudio-product/commits/jbosstools-4.3...
> (new, 9.0.1)
> https://github.com/jbdevstudio/jbdevstudio-product/commits/jbosstools-4.3.x
> (updated to 9.1.0)
> So, now we just need to ensure that the correct BUILD_ALIAS (CR1 for
> 9.0.1, Beta1 for 9.1.0) and target platforms are used.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-21193) runtime detection detects *any* folder as a CDK and jboss multiple times
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21193?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-21193:
-------------------------------------
I have no idea, Max ;) The API asks a given runtime detector for a "RuntimeDefinition" given some file / folder. The RuntimeDefinition that's returned has a name, version, type, etc. But there's no clear mechanism that links it to a specific runtime detector.
So, if there's a given workspace with two runtime detectors, WonkaDetector and JBossDetector, and it's provided two paths (~/wonka, ~/jboss), both will be asked to create a RuntimeDefinition for each path. The wonka detector will return one for wonka, the jboss detector one for jboss. But, it should be noted, there's no 1:1 mapping between the runtime definition type and a given detector. So the jboss detector can return a RuntimeDefinition of type EAP, or type JPP, or type EWP, etc etc. The type is just an identifying string. There's no reference to the detector that instantiated it.
Anyway, it's expected that a given detector knows what "types" it made, and handles them. So a wonka detector knows it only creates wonka type runtime definitions, and if its given anything else, it should ignore it.
I'm sure changes could be made to AbstractRuntimeDetectorDelegate to add some protected methods and add a constructor to RuntimeDefinition to include the given detector and optimize the behavior... but it's not really a huge priority since every detector knows what types htey create. But it'd definitely make the api nicer.
> runtime detection detects *any* folder as a CDK and jboss multiple times
> ------------------------------------------------------------------------
>
> Key: JBIDE-21193
> URL: https://issues.jboss.org/browse/JBIDE-21193
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: runtime-detection
> Reporter: Max Rydahl Andersen
> Assignee: Rob Stryker
> Priority: Blocker
> Fix For: 4.3.1.Beta1
>
> Attachments: Java_EE_-_jboss-eap-6_1_CDK_Server_-_Eclipse.png
>
>
> with build from last week I now get this list of runtime detected in my folder of servers.
> At first I thought it was the CDK being weird but something is also very weird about the basic runtime detection since I seem to have multiple WildFly 8.0's...as opposed to using the folder name.
> Here is the content of my folder
> {code}
> apache-karaf-2.3.5
> apache-tomcat-7.0.35
> app.js
> app.js.1
> fsw-6
> jboss as 7
> jboss-5.1.0.GA
> jboss-as-7.0.1.Final
> jboss-as-7.1.0.Final
> jboss-as-7.1.1.Final
> jboss-as-web-7.0.0.Final
> jboss-as-web-7.0.2.Final
> jboss-eap-6.0.1
> jboss-eap-6.1
> weld-1.1.0.Final
> weld-1.1.5.Final
> wildfly-10.0.0.CR4
> wildfly-8.0.0.Beta1
> wildfly-8.0.0.Final
> wildfly-8.1.0.Final
> wildfly-8.2.0
> wildfly-core-8.0.0.Final
> {code}
> and attached is the list I get.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months