[JBoss JIRA] (JBTIS-271) Create a smoke test for JBoss Fuse Tooling
by Tomáš Sedmík (JIRA)
[ https://issues.jboss.org/browse/JBTIS-271?page=com.atlassian.jira.plugin.... ]
Tomáš Sedmík closed JBTIS-271.
------------------------------
> Create a smoke test for JBoss Fuse Tooling
> ------------------------------------------
>
> Key: JBTIS-271
> URL: https://issues.jboss.org/browse/JBTIS-271
> Project: JBoss Tools Integration Stack
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: QE
> Affects Versions: 4.1.4.Final
> Reporter: Tomáš Sedmík
> Assignee: Tomáš Sedmík
> Fix For: 4.1.4.Final
>
>
> Create a smoke test for JBoss Fuse Tooling:
> * ensure 100% stability of test on all platforms
> * test should be very simple - verifies only presence of JBoss Fuse Tooling plugins
> Steps:
> # create a new Fuse project (e.g. camel-spring)
> # try to open perspectives and views related to JBoss Fuse Tooling
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (JBIDE-17125) Website: Text in banner/header should not contain "A"
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17125?page=com.atlassian.jira.plugi... ]
Xavier Coulon commented on JBIDE-17125:
---------------------------------------
@nickboldt @maxandersen ok, I understood what was wrong when looking at the PR: we should not modify the content of bootstrap-community.css as we grab it from {{http://static.jboss.org/theme/css/bootstrap-community/2.3.1.4/bootstrap-community}} when deploying on staging and production. So, if we really need to modify a style, it should be done in {{jbt-styles.scss}} which is loaded after {{bootstrap-community.css}}.
> Website: Text in banner/header should not contain "A"
> -----------------------------------------------------
>
> Key: JBIDE-17125
> URL: https://issues.jboss.org/browse/JBIDE-17125
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: website
> Affects Versions: 4.2.0.Beta1
> Reporter: Marián Labuda
> Assignee: Max Rydahl Andersen
> Priority: Minor
> Fix For: 4.2.0.Beta2
>
> Attachments: fixed-17125.png, header.png
>
>
> Banner / header or whatever it is called contain text "A JBoss Project". I think that "A" should not be here - it should be "JBoss Project". !header.png!
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (TOOLSDOC-492) Create new docs landing page on new tools.jboss.org site (moving to asciidoc for docs in process)
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/TOOLSDOC-492?page=com.atlassian.jira.plug... ]
Xavier Coulon commented on TOOLSDOC-492:
----------------------------------------
[~nickboldt],
Rerdgin question e):
{quote}
Is :page-component_version: still used, eg., in [1], or is the filename version itself used to categorize the content by milestone?
{quote}
Neither versions in filenames nor {{:page-component_version:}} are not used (this page attribute was used at some point, but not anymore). The link between any N&N file and a product release is done via the {{:page-product-version:}} attribute.
> Create new docs landing page on new tools.jboss.org site (moving to asciidoc for docs in process)
> -------------------------------------------------------------------------------------------------
>
> Key: TOOLSDOC-492
> URL: https://issues.jboss.org/browse/TOOLSDOC-492
> Project: Documentation for JBoss Tools and Developer Studio
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: User Guide
> Affects Versions: 4.2.0.Beta1
> Reporter: Nick Boldt
> Assignee: Michelle Murray
> Fix For: 4.2.0.Beta2
>
> Attachments: converted-adoc-asciidoc-css-not-github-css.png, converted-adoc-github-css-actual.png, converted-adoc-github-css.png, openshift-chapter-generated-epub.png, openshift-chapter-generated-pdf.png
>
>
> With the release of the new tools.jboss.org site, it's time to migrate the docs to the same skin / format / markup. Docbook is dead, long live Asciidoc!
> What [~mmurray] and I are thinking is that we would have a new landing page similar to one of these:
> http://tools.jboss.org/features/ (with icons that link to projects' latest doc)
> or
> http://tools.jboss.org/documentation/whatsnew/ (with the latest doc linked)
> And then under that landing page we'd have doc for each of projects' contributions to the User Guide, by milestone or Final release.
> Questions:
> a. [~maxandersen] [~burrsutter] [~mmusaji] Do we still need to provide 3 formats of doc - HTML, HTML-single, and PDF? Or can we replace that with this new content, PLUS include inline help doc within Eclipse? (That's another issue - see [~dgolovin] 's https://github.com/dgolovin/jbosstools-eclipse-docs/blob/master/docs/scen... for prototype)
> b. [~maxandersen] Should we include docs for "dead" projects like Freemarker, Portal, etc.? I'm guessing YES, even if the doc becomes out of date (ie., the doc for JBT 4.2 for Freemarker won't have changed much (or at all) since JBT 4.0/4.1).
> c. [~maxandersen] Should we convert old JBT 4.1.x (and/or 4.0.x, 3.3.x) doc to the new adoc format, or just start w/ the JBT 4.2.0.Beta1/2 doc? I'd be OK with 4.1 and maybe 4.0, but can we skip 3.3 since JBDS 5 is no longer fully supported?
> d. Will docbook2asciidoc [0] work for batch-converting docbook docs to adoc? @nick will try. If conversion works easily, then converting older User Guides is definitely more doable / less time consuming.
> [0] https://github.com/oreillymedia/docbook2asciidoc
> e. [~xcoulon] Is :page-component_version: still used, eg., in [1], or is the filename version itself used to categorize the content by milestone?
> [1] https://github.com/jbosstools/jbosstools-website/blob/master/documentatio...
> f. If we decide to continue to include other formats (eg., html-single, pdf) should we link to those from these places [2], [3]?
> [2] http://tools.jboss.org/downloads/overview.html
> [3] http://tools.jboss.org/downloads/jbosstools/luna/4.2.0.Beta1.html
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (JBIDE-17125) Website: Text in banner/header should not contain "A"
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17125?page=com.atlassian.jira.plugi... ]
Xavier Coulon commented on JBIDE-17125:
---------------------------------------
[~maxandersen],
On {{staging}} and {{production}} profiles, we grab the bootstrap-community.css file from {{http://static.jboss.org/theme/css/bootstrap-community/2.3.1.4/bootstrap-community}}, while on local we *should* have an exact copy of that file (to be able to work offline). Maybe this local file is not up-to-date.
> Website: Text in banner/header should not contain "A"
> -----------------------------------------------------
>
> Key: JBIDE-17125
> URL: https://issues.jboss.org/browse/JBIDE-17125
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: website
> Affects Versions: 4.2.0.Beta1
> Reporter: Marián Labuda
> Assignee: Max Rydahl Andersen
> Priority: Minor
> Fix For: 4.2.0.Beta2
>
> Attachments: fixed-17125.png, header.png
>
>
> Banner / header or whatever it is called contain text "A JBoss Project". I think that "A" should not be here - it should be "JBoss Project". !header.png!
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (JBIDE-17202) Importing/building WildFly 8.0.Final into JBTools 4.2.0.Beta1 results in GC faillure with Java 1.7.0
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17202?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen updated JBIDE-17202:
----------------------------------------
Assignee: Len DiMaggio
> Importing/building WildFly 8.0.Final into JBTools 4.2.0.Beta1 results in GC faillure with Java 1.7.0
> ----------------------------------------------------------------------------------------------------
>
> Key: JBIDE-17202
> URL: https://issues.jboss.org/browse/JBIDE-17202
> Project: Tools (JBoss Tools)
> Issue Type: Quality Risk
> Components: build
> Affects Versions: 4.2.0.Beta1
> Environment: Linux 2.6.32-358.23.2.el6.x86_64 #1 SMP Sat Sep 14 05:32:37 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux
> java -version
> java version "1.7.0_25"
> OpenJDK Runtime Environment (rhel-2.3.10.4.el6_4-x86_64)
> OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
> Reporter: Len DiMaggio
> Assignee: Len DiMaggio
> Attachments: jbosstools-diagnostics-20140428140420.zip, log, Screenshot-1.png, Screenshot-2.png, Screenshot.png
>
>
> See attached logs and screenshots - building WildFly causes a GC failure
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (JBIDE-17162) Provide sha hashes for JBT/JBDS files on tools.jboss.org
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17162?page=com.atlassian.jira.plugi... ]
Nick Boldt reassigned JBIDE-17162:
----------------------------------
Assignee: Nick Boldt
> Provide sha hashes for JBT/JBDS files on tools.jboss.org
> --------------------------------------------------------
>
> Key: JBIDE-17162
> URL: https://issues.jboss.org/browse/JBIDE-17162
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: website
> Affects Versions: 4.2.0.Beta1
> Reporter: Marián Labuda
> Assignee: Nick Boldt
> Fix For: 4.2.0.Beta2
>
>
> We are providing md5s hashes for JBT and JBDS files (archives links under Update Site Zip). Bcs. it is long known about md5 security flaws (collisions) it is recommended to use sha hashes instead.
> Question is - do we provide md5 hashes only because of data integrity (if there are any missing bits after download) or we are trying to ensure security? In first case it's enough to use md5 (although there could be also hash collisions but it's unlikely). In second case there could be for example performed MITM attack (or any other...) and our files could be replaced by malformed/infected - there should be provided sha hashes instead of md5, but there still remains question if it would be enough without having not-secured web pages (without certificate) and sha links leading to sourceforge (I think that it would not be enough and hashes would have to be stored on tools.jboss.org domain).
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (JBIDE-17162) Provide sha hashes for JBT/JBDS files on tools.jboss.org
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17162?page=com.atlassian.jira.plugi... ]
Nick Boldt closed JBIDE-17162.
------------------------------
Set assignee and fixversion so that jiralint won't complain. Closing as nothing for QE to verify.
> Provide sha hashes for JBT/JBDS files on tools.jboss.org
> --------------------------------------------------------
>
> Key: JBIDE-17162
> URL: https://issues.jboss.org/browse/JBIDE-17162
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: website
> Affects Versions: 4.2.0.Beta1
> Reporter: Marián Labuda
> Assignee: Nick Boldt
> Fix For: 4.2.0.Beta2
>
>
> We are providing md5s hashes for JBT and JBDS files (archives links under Update Site Zip). Bcs. it is long known about md5 security flaws (collisions) it is recommended to use sha hashes instead.
> Question is - do we provide md5 hashes only because of data integrity (if there are any missing bits after download) or we are trying to ensure security? In first case it's enough to use md5 (although there could be also hash collisions but it's unlikely). In second case there could be for example performed MITM attack (or any other...) and our files could be replaced by malformed/infected - there should be provided sha hashes instead of md5, but there still remains question if it would be enough without having not-secured web pages (without certificate) and sha links leading to sourceforge (I think that it would not be enough and hashes would have to be stored on tools.jboss.org domain).
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (JBIDE-17162) Provide sha hashes for JBT/JBDS files on tools.jboss.org
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17162?page=com.atlassian.jira.plugi... ]
Marián Labuda resolved JBIDE-17162.
-----------------------------------
Assignee: (was: Nick Boldt)
Fix Version/s: (was: 4.2.0.Beta2)
Resolution: Rejected
Rejected because there is no value in this.
> Provide sha hashes for JBT/JBDS files on tools.jboss.org
> --------------------------------------------------------
>
> Key: JBIDE-17162
> URL: https://issues.jboss.org/browse/JBIDE-17162
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: website
> Affects Versions: 4.2.0.Beta1
> Reporter: Marián Labuda
>
> We are providing md5s hashes for JBT and JBDS files (archives links under Update Site Zip). Bcs. it is long known about md5 security flaws (collisions) it is recommended to use sha hashes instead.
> Question is - do we provide md5 hashes only because of data integrity (if there are any missing bits after download) or we are trying to ensure security? In first case it's enough to use md5 (although there could be also hash collisions but it's unlikely). In second case there could be for example performed MITM attack (or any other...) and our files could be replaced by malformed/infected - there should be provided sha hashes instead of md5, but there still remains question if it would be enough without having not-secured web pages (without certificate) and sha links leading to sourceforge (I think that it would not be enough and hashes would have to be stored on tools.jboss.org domain).
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (JBIDE-17162) Provide sha hashes for JBT/JBDS files on tools.jboss.org
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17162?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-17162:
-------------------------------
Fix Version/s: 4.2.0.Beta2
> Provide sha hashes for JBT/JBDS files on tools.jboss.org
> --------------------------------------------------------
>
> Key: JBIDE-17162
> URL: https://issues.jboss.org/browse/JBIDE-17162
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: website
> Affects Versions: 4.2.0.Beta1
> Reporter: Marián Labuda
> Fix For: 4.2.0.Beta2
>
>
> We are providing md5s hashes for JBT and JBDS files (archives links under Update Site Zip). Bcs. it is long known about md5 security flaws (collisions) it is recommended to use sha hashes instead.
> Question is - do we provide md5 hashes only because of data integrity (if there are any missing bits after download) or we are trying to ensure security? In first case it's enough to use md5 (although there could be also hash collisions but it's unlikely). In second case there could be for example performed MITM attack (or any other...) and our files could be replaced by malformed/infected - there should be provided sha hashes instead of md5, but there still remains question if it would be enough without having not-secured web pages (without certificate) and sha links leading to sourceforge (I think that it would not be enough and hashes would have to be stored on tools.jboss.org domain).
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (JBIDE-17162) Provide sha hashes for JBT/JBDS files on tools.jboss.org
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17162?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-17162:
-------------------------------
Fix Version/s: 4.2.0.Beta2
> Provide sha hashes for JBT/JBDS files on tools.jboss.org
> --------------------------------------------------------
>
> Key: JBIDE-17162
> URL: https://issues.jboss.org/browse/JBIDE-17162
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: website
> Affects Versions: 4.2.0.Beta1
> Reporter: Marián Labuda
> Fix For: 4.2.0.Beta2
>
>
> We are providing md5s hashes for JBT and JBDS files (archives links under Update Site Zip). Bcs. it is long known about md5 security flaws (collisions) it is recommended to use sha hashes instead.
> Question is - do we provide md5 hashes only because of data integrity (if there are any missing bits after download) or we are trying to ensure security? In first case it's enough to use md5 (although there could be also hash collisions but it's unlikely). In second case there could be for example performed MITM attack (or any other...) and our files could be replaced by malformed/infected - there should be provided sha hashes instead of md5, but there still remains question if it would be enough without having not-secured web pages (without certificate) and sha links leading to sourceforge (I think that it would not be enough and hashes would have to be stored on tools.jboss.org domain).
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months