[JBoss JIRA] (JBIDE-18950) New Batch Artifact wizard
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18950?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich commented on JBIDE-18950:
-----------------------------------------------
[~dazarov], please create icon for list of wizards and wizard banner.
> New Batch Artifact wizard
> -------------------------
>
> Key: JBIDE-18950
> URL: https://issues.jboss.org/browse/JBIDE-18950
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: batch
> Affects Versions: 4.3.0.Alpha1
> Reporter: Viacheslav Kabanovich
> Assignee: Viacheslav Kabanovich
> Labels: new_and_noteworthy
> Fix For: 4.3.0.Beta1
>
>
> There are about 20 artifacts in Java EE Batch:
> Batchlet; Checkpoint Algorithm; Decider; Item Reader; Item Writer; Item Processor; Partition Analyzer; Partition Reducer; Partition Collector; Partition Mapper; Partition Plan; Chunk Listener; Item Process Listener; Item Reader Listener; Item Writer Listener; Job Listener; Step Listener; Retry Process Listener; Retry Read Listener; Retry Write Listener; Skip Process Listener; Skip Listener; Skip Write Listener.
> We may have one wizard for each, or some of this artifacts. However, there is so much common in them that it makes sense also (or instead) to have one wizard with list choice of artifact. When a specific artifact should be created from the context of Batch XML editor, this wizard can be invoked with selection of that artifact (list of artifacts may be disabled or hidden).
> 1. Artifact implements a specific Java interface (for interfaces that have more than 1 method, there is optional abstract class to extend that implements rarely overridden methods);
> 2. Reference name should be provided for each artifact. There are 3 options:
> - An implementation of Batch runtime may define its own way of matching class to name. For example, CDI uses javax.inject.Named;
> - META-INF/batch.xml
> - by default, when first 2 options failed reference name is tried as the qualified class name.
> 3. Artifact class may declare fields, with values to be injected from properties set in job xml element referencing that artifact:
> {code}
> @Inject @BatchProperty(name="property1") String property;
> @Inject @BatchProperty String property2;
> {code}
> Thus, the wizard will have inputs as follows:
> - Artifact: [combo]
> - Source folder: [as in New Java Class wizard]
> - Package: [as in New Java Class wizard]
> - Class name: [text]
> - [radio] implement interface [radio] extend abstract class (if class is not available, the option is disabled)
> - Reference name: (block of inputs)
> | - [radio] Annotation Named [radio] batch.xml [radio] Qualified name
> | - Name: [text] (for first 2 options filled with default value; for the last option disabled)
> - Properties: [table editor with 'Property name' and 'Field name' columns]
> Some more inputs may be inherited from New Java Class wizard, if default values are not enough.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19536) Infinite job loop when creating project
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19536?page=com.atlassian.jira.plugi... ]
Alexey Kazakov commented on JBIDE-19536:
----------------------------------------
[~rawagner], could you then attach a stack trace when you are reproducing it manually? Or maybe even better if you will create a few stacks. Thanks.
> Infinite job loop when creating project
> ---------------------------------------
>
> Key: JBIDE-19536
> URL: https://issues.jboss.org/browse/JBIDE-19536
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi
> Affects Versions: 4.3.0.Alpha1
> Reporter: Rastislav Wagner
> Assignee: Viacheslav Kabanovich
> Fix For: 4.3.0.Beta1
>
> Attachments: cdi_jstack
>
>
> Sometimes i end up in infinite job loop after creating a CDI project. There's no description of what jobs are running, not exception in log. In progress view I can see only "Building workspace (sleeping)" -see on video https://vimeo.com/123634974
> I was able to reproduce on CDI projects (1.0,1.2) but not on any other (Dynamic Web..)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3410) devstudio not reading jbdevstudio.ini on osx
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3410?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-3410:
-------------------------------------
It doesn't help me fix out of memory exception though. There seems new parameter was added --launcher.appendVmargs, but that doesn't help me ether.
> devstudio not reading jbdevstudio.ini on osx
> --------------------------------------------
>
> Key: JBDS-3410
> URL: https://issues.jboss.org/browse/JBDS-3410
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer
> Reporter: Max Rydahl Andersen
> Assignee: Denis Golovin
> Priority: Critical
>
> When starting on OSX it has noticable larger fonts than previous versions.
> It seems to be ignoring -Dorg.eclipse.swt.internal.carbon.smallFonts set in jbdevstudio.ini.
> comparing jbdevstudio8 vs 9 I see that in 8 the location was:
> studio/jbdevstudio.app/Contents/MacOS/jbdevstudio.ini
> but in 9 we have it at
> studio/jbdevstudio.ini
> so that could explain why it wont get picked up ?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3411) have installer build actually use M6 p2 product build
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3411?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-3411:
-------------------------------------
I got this tested as well. I used p2.director application from M6 Eclipse.app and materialized JBDS out of p2repo built with proposed PR, still have the same problems.
> have installer build actually use M6 p2 product build
> -----------------------------------------------------
>
> Key: JBDS-3411
> URL: https://issues.jboss.org/browse/JBDS-3411
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer, updatesite
> Reporter: Max Rydahl Andersen
> Assignee: Denis Golovin
> Priority: Critical
> Fix For: 9.0.0.Alpha2
>
>
> talking with [~prapicault] I learned that since M6 the following changes are required for proper working p2 product/osx build:
> {code}
> <products>
> <product>
> ...
> <rootFolders>
> <macosx>MyProduct.app</macosx>
> </rootFolders>
> </product>
> {code}
> And to use tycho 0.23-snapshot
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3285) Easy Import of non-eclipse projects
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBDS-3285?page=com.atlassian.jira.plugin.... ]
Mickael Istria commented on JBDS-3285:
--------------------------------------
[~maxandersen] Which category would fit this feature the best? Core Tools or Additional Tools?
> Easy Import of non-eclipse projects
> -----------------------------------
>
> Key: JBDS-3285
> URL: https://issues.jboss.org/browse/JBDS-3285
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: requirements, upstream
> Affects Versions: 8.0.0.GA
> Reporter: Burr Sutter
> Assignee: Mickael Istria
> Labels: usability
> Fix For: 9.0.0.Alpha2
>
> Attachments: import-me.zip
>
>
> As a Java EE developer, in some cases using Git for the first time (or only familiar with command line git), I find it very difficult to clone and import a project correctly into JBDS, having the appropriate facets configured, if it has a maven pom.xml, correctly setting the build path, where it is easily deployable to a localhost EAP instance.
> The mission here is to make the Git experience much more user friendly.
> Progress/Status (updated progressively): https://wiki.eclipse.org/E4/UI/Smart_Import
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3411) have installer build actually use M6 p2 product build
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3411?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-3411:
-------------------------------------------
I think the problem is that we are not actually using the latest p2 director to build the product, rigth ? it is done with our custom version.
We need to update that is my guess.
> have installer build actually use M6 p2 product build
> -----------------------------------------------------
>
> Key: JBDS-3411
> URL: https://issues.jboss.org/browse/JBDS-3411
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer, updatesite
> Reporter: Max Rydahl Andersen
> Assignee: Denis Golovin
> Priority: Critical
> Fix For: 9.0.0.Alpha2
>
>
> talking with [~prapicault] I learned that since M6 the following changes are required for proper working p2 product/osx build:
> {code}
> <products>
> <product>
> ...
> <rootFolders>
> <macosx>MyProduct.app</macosx>
> </rootFolders>
> </product>
> {code}
> And to use tycho 0.23-snapshot
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3404) Cannot update from JBDS 9.0.0.Alpha1 to Alpha2 (nightly)
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3404?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-3404:
-------------------------------------------
Found it. Took a while since it was wrongfully closed (the bug was ignored for 8.1, but the actual issue still exist).
JBDS-3359 - problem is afaik the Tern version lockdown we've made to ensure it does not get updated - but seems this is causing more problems than solutions now.
> Cannot update from JBDS 9.0.0.Alpha1 to Alpha2 (nightly)
> --------------------------------------------------------
>
> Key: JBDS-3404
> URL: https://issues.jboss.org/browse/JBDS-3404
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: build
> Affects Versions: 9.0.0.Alpha1
> Reporter: Pavol Srna
> Priority: Blocker
> Fix For: 9.0.0.Alpha2
>
> Attachments: Screenshot 2015-04-13 14.03.50.png, Screenshot 2015-04-13 14.12.04.png
>
>
> When you do Check for update, only thym update is offered:
> !Screenshot 2015-04-13 14.03.50.png!
> Output when you do Install/Check All
> {code}
> Your original request has been modified.
> "Java EE Batch Configuration Tools" is already installed, so an update will be performed instead.
> "JBoss JAX-RS Tools" is already installed, so an update will be performed instead.
> "JBoss Maven Hibernate Configurator" is already installed, so an update will be performed instead.
> "Apache Deltaspike Tools" is already installed, so an update will be performed instead.
> "JBoss Developer Studio (Core Features)" is already installed, so an update will be performed instead.
> "JBoss Tools Foundation" is already installed, so an update will be performed instead.
> "JBoss Tools JDT Extensions" is already installed, so an update will be performed instead.
> "JBoss Maven CDI Configurator" is already installed, so an update will be performed instead.
> "JBoss Maven Portlet Configurator" is already installed, so an update will be performed instead.
> "JBoss Tools RichFaces" is already installed, so an update will be performed instead.
> "JBoss Maven Endorsed Libraries Configurator" is already installed, so an update will be performed instead.
> "JBoss Tools Foundation Security for Linux" is already installed, so an update will be performed instead.
> "JBoss Maven Project Examples" is already installed, so an update will be performed instead.
> "JBoss Tools Java Standard Tools Tern.java Adapter" is already installed, so an update will be performed instead.
> "JMX Console" is already installed, so an update will be performed instead.
> "JBoss OpenShift v2 Tools" is already installed, so an update will be performed instead.
> "JBoss Tools JSF" is already installed, so an update will be performed instead.
> "Seam Tools" is already installed, so an update will be performed instead.
> "Hybrid Mobile Application Development Tools" is already installed, so an update will be performed instead.
> "JBoss Archives Tools" is already installed, so an update will be performed instead.
> "JBoss Stacks Tools" is already installed, so an update will be performed instead.
> "JBoss Tools Java Standard Tools" is already installed, so an update will be performed instead.
> "JBoss Tools Visual Page Editor" is already installed, so an update will be performed instead.
> "Project Examples" is already installed, so an update will be performed instead.
> "JBoss Maven Integration" is already installed, so an update will be performed instead.
> "JBoss Runtime Detection Core" is already installed, so an update will be performed instead.
> "JBoss Tools Apache Tomcat Integration" is already installed, so an update will be performed instead.
> "JBoss WebServices Tools" is already installed, so an update will be performed instead.
> "Hibernate Tools" is already installed, so an update will be performed instead.
> "JBoss Tools LiveReload" is already installed, so an update will be performed instead.
> "JBoss Tools Eclipse Thym Integration" is already installed, so an update will be performed instead.
> "JBoss Tools EGit Integration" is already installed, so an update will be performed instead.
> "JBoss Tools Maven Source Lookup" is already installed, so an update will be performed instead.
> "Forge Tools" is already installed, so an update will be performed instead.
> "Context and Dependency Injection Tools" is already installed, so an update will be performed instead.
> "JBossAS Tools" is already installed, so an update will be performed instead.
> Cannot complete the install because of a conflicting dependency.
> Software being installed: JBoss Tools Java Standard Tools Tern.java Adapter 3.7.0.Alpha2-v20150322-0547-B822 (org.jboss.tools.jst.jsdt.feature.feature.group 3.7.0.Alpha2-v20150322-0547-B822)
> Software currently installed: JBoss Tools Java Standard Tools AngularJS 3.7.0.Alpha1-v20150213-0215-B3 (org.jboss.tools.jst.angularjs.feature.feature.group 3.7.0.Alpha1-v20150213-0215-B3)
> Only one of the following can be installed at once:
> JBoss Tools Java Standard Tools - Tern Project Adapter 3.7.0.Alpha2-v20150322-0547-B822 (org.jboss.tools.jst.jsdt 3.7.0.Alpha2-v20150322-0547-B822)
> JBoss Tools Java Standard Tools - Tern Project Adapter 3.7.0.Alpha1-v20150213-0215-B3 (org.jboss.tools.jst.jsdt 3.7.0.Alpha1-v20150213-0215-B3)
> Cannot satisfy dependency:
> From: JBoss Tools Java Standard Tools AngularJS 3.7.0.Alpha1-v20150213-0215-B3 (org.jboss.tools.jst.angularjs.feature.feature.group 3.7.0.Alpha1-v20150213-0215-B3)
> To: org.jboss.tools.jst.jsdt.feature.feature.group [3.7.0.Alpha1-v20150213-0215-B3]
> Cannot satisfy dependency:
> From: JBoss Tools Java Standard Tools Tern.java Adapter 3.7.0.Alpha1-v20150213-0215-B3 (org.jboss.tools.jst.jsdt.feature.feature.group 3.7.0.Alpha1-v20150213-0215-B3)
> To: org.jboss.tools.jst.jsdt [3.7.0.Alpha1-v20150213-0215-B3]
> Cannot satisfy dependency:
> From: JBoss Tools Java Standard Tools Tern.java Adapter 3.7.0.Alpha2-v20150322-0547-B822 (org.jboss.tools.jst.jsdt.feature.feature.group 3.7.0.Alpha2-v20150322-0547-B822)
> To: org.jboss.tools.jst.jsdt [3.7.0.Alpha2-v20150322-0547-B822]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3410) devstudio not reading jbdevstudio.ini on osx
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3410?page=com.atlassian.jira.plugin.... ]
Denis Golovin reassigned JBDS-3410:
-----------------------------------
Assignee: Denis Golovin
> devstudio not reading jbdevstudio.ini on osx
> --------------------------------------------
>
> Key: JBDS-3410
> URL: https://issues.jboss.org/browse/JBDS-3410
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer
> Reporter: Max Rydahl Andersen
> Assignee: Denis Golovin
> Priority: Critical
>
> When starting on OSX it has noticable larger fonts than previous versions.
> It seems to be ignoring -Dorg.eclipse.swt.internal.carbon.smallFonts set in jbdevstudio.ini.
> comparing jbdevstudio8 vs 9 I see that in 8 the location was:
> studio/jbdevstudio.app/Contents/MacOS/jbdevstudio.ini
> but in 9 we have it at
> studio/jbdevstudio.ini
> so that could explain why it wont get picked up ?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3411) have installer build actually use M6 p2 product build
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3411?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-3411:
-------------------------------------
This PR might affect p2 metadata, but I don't see any improvements for my Mac OS X installation. Still have OOM exception, no workspace selection dialog and target directory structure the same as it was before.
> have installer build actually use M6 p2 product build
> -----------------------------------------------------
>
> Key: JBDS-3411
> URL: https://issues.jboss.org/browse/JBDS-3411
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer, updatesite
> Reporter: Max Rydahl Andersen
> Assignee: Denis Golovin
> Priority: Critical
> Fix For: 9.0.0.Alpha2
>
>
> talking with [~prapicault] I learned that since M6 the following changes are required for proper working p2 product/osx build:
> {code}
> <products>
> <product>
> ...
> <rootFolders>
> <macosx>MyProduct.app</macosx>
> </rootFolders>
> </product>
> {code}
> And to use tycho 0.23-snapshot
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3404) Cannot update from JBDS 9.0.0.Alpha1 to Alpha2 (nightly)
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBDS-3404?page=com.atlassian.jira.plugin.... ]
Mickael Istria commented on JBDS-3404:
--------------------------------------
Do you know whether this org.jboss.tools.jst.jsdt.feature.feature.group is also. requested/included transitively from other features? As I read it, it seems like something is locking the older feature version which prevents update to happen.
cc [~vrubezhny]
> Cannot update from JBDS 9.0.0.Alpha1 to Alpha2 (nightly)
> --------------------------------------------------------
>
> Key: JBDS-3404
> URL: https://issues.jboss.org/browse/JBDS-3404
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: build
> Affects Versions: 9.0.0.Alpha1
> Reporter: Pavol Srna
> Priority: Blocker
> Fix For: 9.0.0.Alpha2
>
> Attachments: Screenshot 2015-04-13 14.03.50.png, Screenshot 2015-04-13 14.12.04.png
>
>
> When you do Check for update, only thym update is offered:
> !Screenshot 2015-04-13 14.03.50.png!
> Output when you do Install/Check All
> {code}
> Your original request has been modified.
> "Java EE Batch Configuration Tools" is already installed, so an update will be performed instead.
> "JBoss JAX-RS Tools" is already installed, so an update will be performed instead.
> "JBoss Maven Hibernate Configurator" is already installed, so an update will be performed instead.
> "Apache Deltaspike Tools" is already installed, so an update will be performed instead.
> "JBoss Developer Studio (Core Features)" is already installed, so an update will be performed instead.
> "JBoss Tools Foundation" is already installed, so an update will be performed instead.
> "JBoss Tools JDT Extensions" is already installed, so an update will be performed instead.
> "JBoss Maven CDI Configurator" is already installed, so an update will be performed instead.
> "JBoss Maven Portlet Configurator" is already installed, so an update will be performed instead.
> "JBoss Tools RichFaces" is already installed, so an update will be performed instead.
> "JBoss Maven Endorsed Libraries Configurator" is already installed, so an update will be performed instead.
> "JBoss Tools Foundation Security for Linux" is already installed, so an update will be performed instead.
> "JBoss Maven Project Examples" is already installed, so an update will be performed instead.
> "JBoss Tools Java Standard Tools Tern.java Adapter" is already installed, so an update will be performed instead.
> "JMX Console" is already installed, so an update will be performed instead.
> "JBoss OpenShift v2 Tools" is already installed, so an update will be performed instead.
> "JBoss Tools JSF" is already installed, so an update will be performed instead.
> "Seam Tools" is already installed, so an update will be performed instead.
> "Hybrid Mobile Application Development Tools" is already installed, so an update will be performed instead.
> "JBoss Archives Tools" is already installed, so an update will be performed instead.
> "JBoss Stacks Tools" is already installed, so an update will be performed instead.
> "JBoss Tools Java Standard Tools" is already installed, so an update will be performed instead.
> "JBoss Tools Visual Page Editor" is already installed, so an update will be performed instead.
> "Project Examples" is already installed, so an update will be performed instead.
> "JBoss Maven Integration" is already installed, so an update will be performed instead.
> "JBoss Runtime Detection Core" is already installed, so an update will be performed instead.
> "JBoss Tools Apache Tomcat Integration" is already installed, so an update will be performed instead.
> "JBoss WebServices Tools" is already installed, so an update will be performed instead.
> "Hibernate Tools" is already installed, so an update will be performed instead.
> "JBoss Tools LiveReload" is already installed, so an update will be performed instead.
> "JBoss Tools Eclipse Thym Integration" is already installed, so an update will be performed instead.
> "JBoss Tools EGit Integration" is already installed, so an update will be performed instead.
> "JBoss Tools Maven Source Lookup" is already installed, so an update will be performed instead.
> "Forge Tools" is already installed, so an update will be performed instead.
> "Context and Dependency Injection Tools" is already installed, so an update will be performed instead.
> "JBossAS Tools" is already installed, so an update will be performed instead.
> Cannot complete the install because of a conflicting dependency.
> Software being installed: JBoss Tools Java Standard Tools Tern.java Adapter 3.7.0.Alpha2-v20150322-0547-B822 (org.jboss.tools.jst.jsdt.feature.feature.group 3.7.0.Alpha2-v20150322-0547-B822)
> Software currently installed: JBoss Tools Java Standard Tools AngularJS 3.7.0.Alpha1-v20150213-0215-B3 (org.jboss.tools.jst.angularjs.feature.feature.group 3.7.0.Alpha1-v20150213-0215-B3)
> Only one of the following can be installed at once:
> JBoss Tools Java Standard Tools - Tern Project Adapter 3.7.0.Alpha2-v20150322-0547-B822 (org.jboss.tools.jst.jsdt 3.7.0.Alpha2-v20150322-0547-B822)
> JBoss Tools Java Standard Tools - Tern Project Adapter 3.7.0.Alpha1-v20150213-0215-B3 (org.jboss.tools.jst.jsdt 3.7.0.Alpha1-v20150213-0215-B3)
> Cannot satisfy dependency:
> From: JBoss Tools Java Standard Tools AngularJS 3.7.0.Alpha1-v20150213-0215-B3 (org.jboss.tools.jst.angularjs.feature.feature.group 3.7.0.Alpha1-v20150213-0215-B3)
> To: org.jboss.tools.jst.jsdt.feature.feature.group [3.7.0.Alpha1-v20150213-0215-B3]
> Cannot satisfy dependency:
> From: JBoss Tools Java Standard Tools Tern.java Adapter 3.7.0.Alpha1-v20150213-0215-B3 (org.jboss.tools.jst.jsdt.feature.feature.group 3.7.0.Alpha1-v20150213-0215-B3)
> To: org.jboss.tools.jst.jsdt [3.7.0.Alpha1-v20150213-0215-B3]
> Cannot satisfy dependency:
> From: JBoss Tools Java Standard Tools Tern.java Adapter 3.7.0.Alpha2-v20150322-0547-B822 (org.jboss.tools.jst.jsdt.feature.feature.group 3.7.0.Alpha2-v20150322-0547-B822)
> To: org.jboss.tools.jst.jsdt [3.7.0.Alpha2-v20150322-0547-B822]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3404) Cannot update from JBDS 9.0.0.Alpha1 to Alpha2 (nightly)
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3404?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-3404:
-------------------------------------------
this is not related to OSX M6 changes. its releated to same issue we have from not being able to update from 8.0.x to 8.1.0.
> Cannot update from JBDS 9.0.0.Alpha1 to Alpha2 (nightly)
> --------------------------------------------------------
>
> Key: JBDS-3404
> URL: https://issues.jboss.org/browse/JBDS-3404
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: build
> Affects Versions: 9.0.0.Alpha1
> Reporter: Pavol Srna
> Priority: Blocker
> Fix For: 9.0.0.Alpha2
>
> Attachments: Screenshot 2015-04-13 14.03.50.png, Screenshot 2015-04-13 14.12.04.png
>
>
> When you do Check for update, only thym update is offered:
> !Screenshot 2015-04-13 14.03.50.png!
> Output when you do Install/Check All
> {code}
> Your original request has been modified.
> "Java EE Batch Configuration Tools" is already installed, so an update will be performed instead.
> "JBoss JAX-RS Tools" is already installed, so an update will be performed instead.
> "JBoss Maven Hibernate Configurator" is already installed, so an update will be performed instead.
> "Apache Deltaspike Tools" is already installed, so an update will be performed instead.
> "JBoss Developer Studio (Core Features)" is already installed, so an update will be performed instead.
> "JBoss Tools Foundation" is already installed, so an update will be performed instead.
> "JBoss Tools JDT Extensions" is already installed, so an update will be performed instead.
> "JBoss Maven CDI Configurator" is already installed, so an update will be performed instead.
> "JBoss Maven Portlet Configurator" is already installed, so an update will be performed instead.
> "JBoss Tools RichFaces" is already installed, so an update will be performed instead.
> "JBoss Maven Endorsed Libraries Configurator" is already installed, so an update will be performed instead.
> "JBoss Tools Foundation Security for Linux" is already installed, so an update will be performed instead.
> "JBoss Maven Project Examples" is already installed, so an update will be performed instead.
> "JBoss Tools Java Standard Tools Tern.java Adapter" is already installed, so an update will be performed instead.
> "JMX Console" is already installed, so an update will be performed instead.
> "JBoss OpenShift v2 Tools" is already installed, so an update will be performed instead.
> "JBoss Tools JSF" is already installed, so an update will be performed instead.
> "Seam Tools" is already installed, so an update will be performed instead.
> "Hybrid Mobile Application Development Tools" is already installed, so an update will be performed instead.
> "JBoss Archives Tools" is already installed, so an update will be performed instead.
> "JBoss Stacks Tools" is already installed, so an update will be performed instead.
> "JBoss Tools Java Standard Tools" is already installed, so an update will be performed instead.
> "JBoss Tools Visual Page Editor" is already installed, so an update will be performed instead.
> "Project Examples" is already installed, so an update will be performed instead.
> "JBoss Maven Integration" is already installed, so an update will be performed instead.
> "JBoss Runtime Detection Core" is already installed, so an update will be performed instead.
> "JBoss Tools Apache Tomcat Integration" is already installed, so an update will be performed instead.
> "JBoss WebServices Tools" is already installed, so an update will be performed instead.
> "Hibernate Tools" is already installed, so an update will be performed instead.
> "JBoss Tools LiveReload" is already installed, so an update will be performed instead.
> "JBoss Tools Eclipse Thym Integration" is already installed, so an update will be performed instead.
> "JBoss Tools EGit Integration" is already installed, so an update will be performed instead.
> "JBoss Tools Maven Source Lookup" is already installed, so an update will be performed instead.
> "Forge Tools" is already installed, so an update will be performed instead.
> "Context and Dependency Injection Tools" is already installed, so an update will be performed instead.
> "JBossAS Tools" is already installed, so an update will be performed instead.
> Cannot complete the install because of a conflicting dependency.
> Software being installed: JBoss Tools Java Standard Tools Tern.java Adapter 3.7.0.Alpha2-v20150322-0547-B822 (org.jboss.tools.jst.jsdt.feature.feature.group 3.7.0.Alpha2-v20150322-0547-B822)
> Software currently installed: JBoss Tools Java Standard Tools AngularJS 3.7.0.Alpha1-v20150213-0215-B3 (org.jboss.tools.jst.angularjs.feature.feature.group 3.7.0.Alpha1-v20150213-0215-B3)
> Only one of the following can be installed at once:
> JBoss Tools Java Standard Tools - Tern Project Adapter 3.7.0.Alpha2-v20150322-0547-B822 (org.jboss.tools.jst.jsdt 3.7.0.Alpha2-v20150322-0547-B822)
> JBoss Tools Java Standard Tools - Tern Project Adapter 3.7.0.Alpha1-v20150213-0215-B3 (org.jboss.tools.jst.jsdt 3.7.0.Alpha1-v20150213-0215-B3)
> Cannot satisfy dependency:
> From: JBoss Tools Java Standard Tools AngularJS 3.7.0.Alpha1-v20150213-0215-B3 (org.jboss.tools.jst.angularjs.feature.feature.group 3.7.0.Alpha1-v20150213-0215-B3)
> To: org.jboss.tools.jst.jsdt.feature.feature.group [3.7.0.Alpha1-v20150213-0215-B3]
> Cannot satisfy dependency:
> From: JBoss Tools Java Standard Tools Tern.java Adapter 3.7.0.Alpha1-v20150213-0215-B3 (org.jboss.tools.jst.jsdt.feature.feature.group 3.7.0.Alpha1-v20150213-0215-B3)
> To: org.jboss.tools.jst.jsdt [3.7.0.Alpha1-v20150213-0215-B3]
> Cannot satisfy dependency:
> From: JBoss Tools Java Standard Tools Tern.java Adapter 3.7.0.Alpha2-v20150322-0547-B822 (org.jboss.tools.jst.jsdt.feature.feature.group 3.7.0.Alpha2-v20150322-0547-B822)
> To: org.jboss.tools.jst.jsdt [3.7.0.Alpha2-v20150322-0547-B822]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3404) Cannot update from JBDS 9.0.0.Alpha1 to Alpha2 (nightly)
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-3404?page=com.atlassian.jira.plugin.... ]
Nick Boldt commented on JBDS-3404:
----------------------------------
Due to changes in Mars M6, I suspect we'll never be able to update from Alpha1 to Alpha2.
[~maxandersen] [~mickael_istria] [~fbricon] Can you provide details about what's changed in M6 which would block doing a simple update?
Pavol: Are you on OSX? If so, see JBDS-3411.
> Cannot update from JBDS 9.0.0.Alpha1 to Alpha2 (nightly)
> --------------------------------------------------------
>
> Key: JBDS-3404
> URL: https://issues.jboss.org/browse/JBDS-3404
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: build
> Affects Versions: 9.0.0.Alpha1
> Reporter: Pavol Srna
> Priority: Blocker
> Fix For: 9.0.0.Alpha2
>
> Attachments: Screenshot 2015-04-13 14.03.50.png, Screenshot 2015-04-13 14.12.04.png
>
>
> When you do Check for update, only thym update is offered:
> !Screenshot 2015-04-13 14.03.50.png!
> Output when you do Install/Check All
> {code}
> Your original request has been modified.
> "Java EE Batch Configuration Tools" is already installed, so an update will be performed instead.
> "JBoss JAX-RS Tools" is already installed, so an update will be performed instead.
> "JBoss Maven Hibernate Configurator" is already installed, so an update will be performed instead.
> "Apache Deltaspike Tools" is already installed, so an update will be performed instead.
> "JBoss Developer Studio (Core Features)" is already installed, so an update will be performed instead.
> "JBoss Tools Foundation" is already installed, so an update will be performed instead.
> "JBoss Tools JDT Extensions" is already installed, so an update will be performed instead.
> "JBoss Maven CDI Configurator" is already installed, so an update will be performed instead.
> "JBoss Maven Portlet Configurator" is already installed, so an update will be performed instead.
> "JBoss Tools RichFaces" is already installed, so an update will be performed instead.
> "JBoss Maven Endorsed Libraries Configurator" is already installed, so an update will be performed instead.
> "JBoss Tools Foundation Security for Linux" is already installed, so an update will be performed instead.
> "JBoss Maven Project Examples" is already installed, so an update will be performed instead.
> "JBoss Tools Java Standard Tools Tern.java Adapter" is already installed, so an update will be performed instead.
> "JMX Console" is already installed, so an update will be performed instead.
> "JBoss OpenShift v2 Tools" is already installed, so an update will be performed instead.
> "JBoss Tools JSF" is already installed, so an update will be performed instead.
> "Seam Tools" is already installed, so an update will be performed instead.
> "Hybrid Mobile Application Development Tools" is already installed, so an update will be performed instead.
> "JBoss Archives Tools" is already installed, so an update will be performed instead.
> "JBoss Stacks Tools" is already installed, so an update will be performed instead.
> "JBoss Tools Java Standard Tools" is already installed, so an update will be performed instead.
> "JBoss Tools Visual Page Editor" is already installed, so an update will be performed instead.
> "Project Examples" is already installed, so an update will be performed instead.
> "JBoss Maven Integration" is already installed, so an update will be performed instead.
> "JBoss Runtime Detection Core" is already installed, so an update will be performed instead.
> "JBoss Tools Apache Tomcat Integration" is already installed, so an update will be performed instead.
> "JBoss WebServices Tools" is already installed, so an update will be performed instead.
> "Hibernate Tools" is already installed, so an update will be performed instead.
> "JBoss Tools LiveReload" is already installed, so an update will be performed instead.
> "JBoss Tools Eclipse Thym Integration" is already installed, so an update will be performed instead.
> "JBoss Tools EGit Integration" is already installed, so an update will be performed instead.
> "JBoss Tools Maven Source Lookup" is already installed, so an update will be performed instead.
> "Forge Tools" is already installed, so an update will be performed instead.
> "Context and Dependency Injection Tools" is already installed, so an update will be performed instead.
> "JBossAS Tools" is already installed, so an update will be performed instead.
> Cannot complete the install because of a conflicting dependency.
> Software being installed: JBoss Tools Java Standard Tools Tern.java Adapter 3.7.0.Alpha2-v20150322-0547-B822 (org.jboss.tools.jst.jsdt.feature.feature.group 3.7.0.Alpha2-v20150322-0547-B822)
> Software currently installed: JBoss Tools Java Standard Tools AngularJS 3.7.0.Alpha1-v20150213-0215-B3 (org.jboss.tools.jst.angularjs.feature.feature.group 3.7.0.Alpha1-v20150213-0215-B3)
> Only one of the following can be installed at once:
> JBoss Tools Java Standard Tools - Tern Project Adapter 3.7.0.Alpha2-v20150322-0547-B822 (org.jboss.tools.jst.jsdt 3.7.0.Alpha2-v20150322-0547-B822)
> JBoss Tools Java Standard Tools - Tern Project Adapter 3.7.0.Alpha1-v20150213-0215-B3 (org.jboss.tools.jst.jsdt 3.7.0.Alpha1-v20150213-0215-B3)
> Cannot satisfy dependency:
> From: JBoss Tools Java Standard Tools AngularJS 3.7.0.Alpha1-v20150213-0215-B3 (org.jboss.tools.jst.angularjs.feature.feature.group 3.7.0.Alpha1-v20150213-0215-B3)
> To: org.jboss.tools.jst.jsdt.feature.feature.group [3.7.0.Alpha1-v20150213-0215-B3]
> Cannot satisfy dependency:
> From: JBoss Tools Java Standard Tools Tern.java Adapter 3.7.0.Alpha1-v20150213-0215-B3 (org.jboss.tools.jst.jsdt.feature.feature.group 3.7.0.Alpha1-v20150213-0215-B3)
> To: org.jboss.tools.jst.jsdt [3.7.0.Alpha1-v20150213-0215-B3]
> Cannot satisfy dependency:
> From: JBoss Tools Java Standard Tools Tern.java Adapter 3.7.0.Alpha2-v20150322-0547-B822 (org.jboss.tools.jst.jsdt.feature.feature.group 3.7.0.Alpha2-v20150322-0547-B822)
> To: org.jboss.tools.jst.jsdt [3.7.0.Alpha2-v20150322-0547-B822]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3411) have installer build actually use M6 p2 product build
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-3411?page=com.atlassian.jira.plugin.... ]
Nick Boldt updated JBDS-3411:
-----------------------------
Fix Version/s: 9.0.0.Alpha2
> have installer build actually use M6 p2 product build
> -----------------------------------------------------
>
> Key: JBDS-3411
> URL: https://issues.jboss.org/browse/JBDS-3411
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer, updatesite
> Reporter: Max Rydahl Andersen
> Assignee: Denis Golovin
> Priority: Critical
> Fix For: 9.0.0.Alpha2
>
>
> talking with [~prapicault] I learned that since M6 the following changes are required for proper working p2 product/osx build:
> {code}
> <products>
> <product>
> ...
> <rootFolders>
> <macosx>MyProduct.app</macosx>
> </rootFolders>
> </product>
> {code}
> And to use tycho 0.23-snapshot
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19598) Use "Build other project (extended)" to cascade aggregation
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19598?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-19598:
-------------------------------
Description:
In order to decide whether to cascade aggregation when components are build, we could use the "Build other project (extended)" plugin in order to trigger 2 aggregate jobs (site, coretests-site) when component has SCM changes.
This would require changing all 17 component jobs (per stream = 34 jobs), but would eliminate the need for the composite-install test jobs [1].
[1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite...
was:
In order to decide whether to cascade aggregation when components are build, we could use the "Build other project (extended)" plugin in order to trigger aggregate when component has SCM changes.
This could be a replacement for the p2director job.
> Use "Build other project (extended)" to cascade aggregation
> -----------------------------------------------------------
>
> Key: JBIDE-19598
> URL: https://issues.jboss.org/browse/JBIDE-19598
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Affects Versions: 4.3.0.Alpha2
> Reporter: Mickael Istria
> Fix For: 4.3.0.Beta1
>
>
> In order to decide whether to cascade aggregation when components are build, we could use the "Build other project (extended)" plugin in order to trigger 2 aggregate jobs (site, coretests-site) when component has SCM changes.
> This would require changing all 17 component jobs (per stream = 34 jobs), but would eliminate the need for the composite-install test jobs [1].
> [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3276) JBDS-IS Installer
by Burr Sutter (JIRA)
[ https://issues.jboss.org/browse/JBDS-3276?page=com.atlassian.jira.plugin.... ]
Burr Sutter commented on JBDS-3276:
-----------------------------------
The original thinking was that there would be a single installer .jar that introduced another step in the wizard to ask the end-user if they wanted the JBDS-IS tools (Fuse, etc). I am still more interested in a single installer .jar...that gets updated whenever JBDS core OR JBDS-IS ships...when there is no JBDS-IS available...the step in the wizard is either skipped over or disabled.
Bottom Line: we will need to spend some meeting time on this topic and socialize it with the various stakeholders.
> JBDS-IS Installer
> -----------------
>
> Key: JBDS-3276
> URL: https://issues.jboss.org/browse/JBDS-3276
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: installer, integration-platform, requirements
> Affects Versions: 8.0.0.GA
> Reporter: Burr Sutter
> Assignee: Denis Golovin
> Attachments: Red Hat JBoss Developer Studio 9.0.0.Alpha2_105.png
>
>
> As a Fuse, integration-focused developer, I need a downloadable installer that will allow me to quickly and easily install JBDS with Fuse capabilities.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19598) Use "Build other project (extended)" to cascade aggregation
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19598?page=com.atlassian.jira.plugi... ]
Mickael Istria updated JBIDE-19598:
-----------------------------------
Description:
In order to decide whether to cascade aggregation when components are build, we could use the "Build other project (extended)" plugin in order to trigger aggregate when component has SCM changes.
This could be a replacement for the p2director job.
was:In order to decide whether to cascade aggregation when components are build, we could use the "Build other project (extended)" plugin in order to trigger aggregate when component has SCM changes.
> Use "Build other project (extended)" to cascade aggregation
> -----------------------------------------------------------
>
> Key: JBIDE-19598
> URL: https://issues.jboss.org/browse/JBIDE-19598
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Affects Versions: 4.3.0.Alpha2
> Reporter: Mickael Istria
>
> In order to decide whether to cascade aggregation when components are build, we could use the "Build other project (extended)" plugin in order to trigger aggregate when component has SCM changes.
> This could be a replacement for the p2director job.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3276) JBDS-IS Installer
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3276?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-3276:
-------------------------------------------
UX wise I just referred to the table shown in screenshot is very squished and very "crowded". Should be made to take up the whole space and width to be really usable. Also maybe make the text wrap so its viewable without scrolling.
> JBDS-IS Installer
> -----------------
>
> Key: JBDS-3276
> URL: https://issues.jboss.org/browse/JBDS-3276
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: installer, integration-platform, requirements
> Affects Versions: 8.0.0.GA
> Reporter: Burr Sutter
> Assignee: Denis Golovin
> Attachments: Red Hat JBoss Developer Studio 9.0.0.Alpha2_105.png
>
>
> As a Fuse, integration-focused developer, I need a downloadable installer that will allow me to quickly and easily install JBDS with Fuse capabilities.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19598) Use "Build other project (extended)" to cascade aggregation
by Mickael Istria (JIRA)
Mickael Istria created JBIDE-19598:
--------------------------------------
Summary: Use "Build other project (extended)" to cascade aggregation
Key: JBIDE-19598
URL: https://issues.jboss.org/browse/JBIDE-19598
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: build
Affects Versions: 4.3.0.Alpha2
Reporter: Mickael Istria
In order to decide whether to cascade aggregation when components are build, we could use the "Build other project (extended)" plugin in order to trigger aggregate when component has SCM changes.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19597) add google tag manager to website
by Max Rydahl Andersen (JIRA)
Max Rydahl Andersen created JBIDE-19597:
-------------------------------------------
Summary: add google tag manager to website
Key: JBIDE-19597
URL: https://issues.jboss.org/browse/JBIDE-19597
Project: Tools (JBoss Tools)
Issue Type: Task
Components: website
Reporter: Max Rydahl Andersen
Assignee: Max Rydahl Andersen
Asked by jboss.org to add the following:
{code}
Option 1: You have an existing GA (Google Analytics) account you want to keep using. You should upgrade your GA account to use UA (Universal Analytics).
<script>dataLayer = [{'channel' : ‘<insert project name here>’, ‘additional_tracking_code’ : ‘<insert optional additional GA tracking code here>'}];</script>
<!-- Google Tag Manager -->
<noscript><iframe src="//www.googletagmanager.com/ns.html?id=GTM-NJWS5L"
height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>
<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'//www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-NJWS5L');</script>
<!-- End Google Tag Manager —>
{code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-18742) Only rely on rsync to publish new aggregate (remove other comparators and checks)
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18742?page=com.atlassian.jira.plugi... ]
Mickael Istria updated JBIDE-18742:
-----------------------------------
Summary: Only rely on rsync to publish new aggregate (remove other comparators and checks) (was: Only rely on rsync to publish new aggregate (remove other comparators))
> Only rely on rsync to publish new aggregate (remove other comparators and checks)
> ---------------------------------------------------------------------------------
>
> Key: JBIDE-18742
> URL: https://issues.jboss.org/browse/JBIDE-18742
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Fix For: 4.3.0.Beta1
>
>
> Instead of the composite-install test to decide whether we aggregate or not, it would be simpler to build aggregation in any case and then use p2diff (or other smart mechanism) to decide whether we want to publish the new composite or not.
> It's more or less just a matter of scripting
> {code:none}
> p2diff file:${WORKSPACE}/results/${JOB_NAME}/all/repo/ http://download.jboss.org/jbosstools/builds/staging/${JOB_NAME}/all/repo/ | grep -e ^\< -e ^\> > p2diff_snapshot
> if [[ -s p2diff_snapshot ]]; then
> ./publish.sh
> fi
> {code}
> Another benefit is that it allows us to get rid of the composite (1 less couple of files to maintain)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-17836) Arquillian: error logged when deselecting JBOSS_AS_REMOTE_7.X maven profile
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17836?page=com.atlassian.jira.plugi... ]
Fred Bricon updated JBIDE-17836:
--------------------------------
Fix Version/s: 4.3.0.Beta1
(was: 4.3.0.Alpha2)
> Arquillian: error logged when deselecting JBOSS_AS_REMOTE_7.X maven profile
> ---------------------------------------------------------------------------
>
> Key: JBIDE-17836
> URL: https://issues.jboss.org/browse/JBIDE-17836
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: maven, upstream
> Affects Versions: 4.2.0.Beta3
> Reporter: Lucia Jelinkova
> Assignee: Fred Bricon
> Fix For: 4.3.0.Beta1
>
> Attachments: jbide-17836.patch, screencast.ogv
>
>
> When I have JBOSS_AS_REMOTE_7.X profile selected in the launch configuration and I deselect it and select some other profile, the following error is logged in error log:
> {code}
> /home/ljelinko/.m2/repository/org/jboss/as/jboss-as-build-config/7.1.1.Final/jboss-as-build-config-7.1.1.Final.jar does not exist
> Java Model Exception: Java Model Status [/home/ljelinko/.m2/repository/org/jboss/as/jboss-as-build-config/7.1.1.Final/jboss-as-build-config-7.1.1.Final.jar does not exist]
> at org.eclipse.jdt.internal.core.JavaElement.newNotPresentException(JavaElement.java:534)
> at org.eclipse.jdt.internal.core.JarPackageFragmentRoot.getUnderlyingResource(JarPackageFragmentRoot.java:215)
> at org.eclipse.jpt.common.core.internal.utility.PackageFragmentRootTools.isFolder_(PackageFragmentRootTools.java:82)
> at org.eclipse.jpt.common.core.internal.utility.PackageFragmentRootTools.isFolder(PackageFragmentRootTools.java:74)
> at org.eclipse.jpt.common.core.internal.utility.PackageFragmentRootTools$IsFolder.evaluate(PackageFragmentRootTools.java:65)
> at org.eclipse.jpt.common.core.internal.utility.PackageFragmentRootTools$IsFolder.evaluate(PackageFragmentRootTools.java:1)
> at org.eclipse.jpt.common.utility.internal.iterator.FilteringIterator.loadNext(FilteringIterator.java:80)
> at org.eclipse.jpt.common.utility.internal.iterator.FilteringIterator.next(FilteringIterator.java:68)
> at org.eclipse.jpt.common.utility.internal.iterator.TransformationIterator.next(TransformationIterator.java:54)
> at org.eclipse.jpt.common.core.internal.resource.SimpleJavaResourceLocator.getWorkspacePath_(SimpleJavaResourceLocator.java:144)
> at org.eclipse.jpt.common.core.internal.resource.SimpleJavaResourceLocator.getWorkspacePath(SimpleJavaResourceLocator.java:135)
> at org.eclipse.m2e.wtp.jpa.internal.configurators.MavenResourceLocator.getWorkspacePath(MavenResourceLocator.java:137)
> at org.eclipse.m2e.wtp.jpa.internal.configurators.JpaProjectConfigurator.getPersistenceXml(JpaProjectConfigurator.java:119)
> at org.eclipse.m2e.wtp.jpa.internal.configurators.JpaProjectConfigurator.configure(JpaProjectConfigurator.java:92)
> at org.eclipse.m2e.core.project.configurator.AbstractLifecycleMapping.configure(AbstractLifecycleMapping.java:120)
> at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager$3.call(ProjectConfigurationManager.java:477)
> at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager$3.call(ProjectConfigurationManager.java:1)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:166)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:142)
> at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.updateProjectConfiguration(ProjectConfigurationManager.java:470)
> at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.updateProjectConfiguration0(ProjectConfigurationManager.java:408)
> at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager$2.call(ProjectConfigurationManager.java:321)
> at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager$2.call(ProjectConfigurationManager.java:1)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:166)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:142)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:96)
> at org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:1344)
> at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.updateProjectConfiguration(ProjectConfigurationManager.java:318)
> at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.updateProjectConfiguration(ProjectConfigurationManager.java:304)
> at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.updateProjectConfiguration(ProjectConfigurationManager.java:286)
> at org.eclipse.m2e.profiles.core.internal.management.ProfileManager.updateActiveProfiles(ProfileManager.java:87)
> at org.eclipse.m2e.profiles.ui.internal.actions.ProfileSelectionHandler$UpdateProfilesJob.runInWorkspace(ProfileSelectionHandler.java:319)
> at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-17836) Arquillian: error logged when deselecting JBOSS_AS_REMOTE_7.X maven profile
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17836?page=com.atlassian.jira.plugi... ]
Fred Bricon commented on JBIDE-17836:
-------------------------------------
Snjeza, if anything, that should be fixed within the MavenResourceLocator.
How did you manage to reproduce the issue with a non WTP project?
> Arquillian: error logged when deselecting JBOSS_AS_REMOTE_7.X maven profile
> ---------------------------------------------------------------------------
>
> Key: JBIDE-17836
> URL: https://issues.jboss.org/browse/JBIDE-17836
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: maven, upstream
> Affects Versions: 4.2.0.Beta3
> Reporter: Lucia Jelinkova
> Assignee: Fred Bricon
> Fix For: 4.3.0.Alpha2
>
> Attachments: jbide-17836.patch, screencast.ogv
>
>
> When I have JBOSS_AS_REMOTE_7.X profile selected in the launch configuration and I deselect it and select some other profile, the following error is logged in error log:
> {code}
> /home/ljelinko/.m2/repository/org/jboss/as/jboss-as-build-config/7.1.1.Final/jboss-as-build-config-7.1.1.Final.jar does not exist
> Java Model Exception: Java Model Status [/home/ljelinko/.m2/repository/org/jboss/as/jboss-as-build-config/7.1.1.Final/jboss-as-build-config-7.1.1.Final.jar does not exist]
> at org.eclipse.jdt.internal.core.JavaElement.newNotPresentException(JavaElement.java:534)
> at org.eclipse.jdt.internal.core.JarPackageFragmentRoot.getUnderlyingResource(JarPackageFragmentRoot.java:215)
> at org.eclipse.jpt.common.core.internal.utility.PackageFragmentRootTools.isFolder_(PackageFragmentRootTools.java:82)
> at org.eclipse.jpt.common.core.internal.utility.PackageFragmentRootTools.isFolder(PackageFragmentRootTools.java:74)
> at org.eclipse.jpt.common.core.internal.utility.PackageFragmentRootTools$IsFolder.evaluate(PackageFragmentRootTools.java:65)
> at org.eclipse.jpt.common.core.internal.utility.PackageFragmentRootTools$IsFolder.evaluate(PackageFragmentRootTools.java:1)
> at org.eclipse.jpt.common.utility.internal.iterator.FilteringIterator.loadNext(FilteringIterator.java:80)
> at org.eclipse.jpt.common.utility.internal.iterator.FilteringIterator.next(FilteringIterator.java:68)
> at org.eclipse.jpt.common.utility.internal.iterator.TransformationIterator.next(TransformationIterator.java:54)
> at org.eclipse.jpt.common.core.internal.resource.SimpleJavaResourceLocator.getWorkspacePath_(SimpleJavaResourceLocator.java:144)
> at org.eclipse.jpt.common.core.internal.resource.SimpleJavaResourceLocator.getWorkspacePath(SimpleJavaResourceLocator.java:135)
> at org.eclipse.m2e.wtp.jpa.internal.configurators.MavenResourceLocator.getWorkspacePath(MavenResourceLocator.java:137)
> at org.eclipse.m2e.wtp.jpa.internal.configurators.JpaProjectConfigurator.getPersistenceXml(JpaProjectConfigurator.java:119)
> at org.eclipse.m2e.wtp.jpa.internal.configurators.JpaProjectConfigurator.configure(JpaProjectConfigurator.java:92)
> at org.eclipse.m2e.core.project.configurator.AbstractLifecycleMapping.configure(AbstractLifecycleMapping.java:120)
> at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager$3.call(ProjectConfigurationManager.java:477)
> at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager$3.call(ProjectConfigurationManager.java:1)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:166)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:142)
> at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.updateProjectConfiguration(ProjectConfigurationManager.java:470)
> at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.updateProjectConfiguration0(ProjectConfigurationManager.java:408)
> at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager$2.call(ProjectConfigurationManager.java:321)
> at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager$2.call(ProjectConfigurationManager.java:1)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:166)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:142)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:96)
> at org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:1344)
> at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.updateProjectConfiguration(ProjectConfigurationManager.java:318)
> at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.updateProjectConfiguration(ProjectConfigurationManager.java:304)
> at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.updateProjectConfiguration(ProjectConfigurationManager.java:286)
> at org.eclipse.m2e.profiles.core.internal.management.ProfileManager.updateActiveProfiles(ProfileManager.java:87)
> at org.eclipse.m2e.profiles.ui.internal.actions.ProfileSelectionHandler$UpdateProfilesJob.runInWorkspace(ProfileSelectionHandler.java:319)
> at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-18426) Central installation drags in too many dependencies
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18426?page=com.atlassian.jira.plugi... ]
Fred Bricon resolved JBIDE-18426.
---------------------------------
Resolution: Done
Central installation no longer drags portlet and seam. Marking as resolved.
> Central installation drags in too many dependencies
> ---------------------------------------------------
>
> Key: JBIDE-18426
> URL: https://issues.jboss.org/browse/JBIDE-18426
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: central
> Affects Versions: 4.2.0.CR1
> Reporter: Denis Golovin
> Assignee: Fred Bricon
> Priority: Critical
> Labels: f2f2014
> Fix For: 4.3.0.Alpha2
>
>
> Installing only central feature from JBT Repository leads to almost full JBT installation (see list below).
> Should we support scenario when central installs minimum and then let install what is missing depending on developer's needs?
> {code}
> Warning: You are installing software that contains unsigned content. The authenticity or validity of this software cannot be established. Do you want to continue with the installation?
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.hibernate.eclipse_4.0.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.hibernate.eclipse.console_4.0.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.hibernate.eclipse.feature_4.0.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.hibernate.eclipse.help_4.0.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.hibernate.eclipse.jdt.apt.ui_4.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.hibernate.eclipse.jdt.ui_4.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.hibernate.eclipse.libs_4.0.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.hibernate.eclipse.mapper_4.0.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.ide.eclipse.archives.core_3.5.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.jboss.ide.eclipse.archives.feature_3.5.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.ide.eclipse.archives.jdt.integration_3.5.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.ide.eclipse.archives.ui_3.5.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.ide.eclipse.archives.webtools_3.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.jboss.ide.eclipse.as.archives.integration.feature_3.0.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.ide.eclipse.as.classpath.core_3.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.ide.eclipse.as.classpath.ui_3.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.ide.eclipse.as.core_3.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.ide.eclipse.as.dmr_3.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.ide.eclipse.as.doc.user_3.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.jboss.ide.eclipse.as.feature_3.0.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.ide.eclipse.as.jmx.integration_3.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.jboss.ide.eclipse.as.jmx.integration.feature_3.0.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.ide.eclipse.as.management.as71_3.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.ide.eclipse.as.management.core_3.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.ide.eclipse.as.management.wildfly8_3.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.ide.eclipse.as.rse.core_3.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.ide.eclipse.as.rse.ui_3.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.jboss.ide.eclipse.as.server.rse.integration.feature_3.0.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.jboss.ide.eclipse.as.serverAdapter.wtp.feature_3.0.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.ide.eclipse.as.ui_3.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.ide.eclipse.as.ui.mbeans_3.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.ide.eclipse.as.wtp.core_3.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.ide.eclipse.as.wtp.ui_3.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.archives.scanner_3.5.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.jboss.tools.archives.scanner.feature_3.5.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.as.catalog_3.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.as.runtimes.integration_3.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.central_1.3.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.jboss.tools.central.feature_1.3.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.common_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.common.core_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.common.el.core_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.common.el.ui_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.jboss.tools.common.feature_3.6.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.common.gef_3.6.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.common.model_3.6.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.common.model.ui_3.6.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.common.model.ui.capabilities_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.common.projecttemplates_3.6.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.common.resref.core_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.common.resref.ui_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.common.text.ext_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.common.text.xml_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.common.ui_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.common.validation_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.common.verification_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.community.central_1.3.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.jboss.tools.community.central.feature_1.3.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.community.project.examples_2.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.jboss.tools.community.project.examples.feature_2.0.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.foundation.core_1.1.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.foundation.ui_1.1.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.hibernate.antlr_2.7.7.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.hibernate.beanshell_2.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.hibernate.dom4j_1.6.1.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.hibernate.jpt.core_4.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.hibernate.jpt.ui_4.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.hibernate.jtidy_8.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.hibernate.spi_4.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.hibernate.ui_4.0.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.hibernate.xml_4.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.hibernate.xml.ui_4.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.hibernate3_5_4.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.hibernate3_6_4.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.hibernate4_0_4.0.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.hibernate4_3_4.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.jmx.core_1.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.jboss.tools.jmx.feature_1.6.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.jmx.jvmmonitor.core_1.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.jmx.jvmmonitor.tools_1.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.jmx.jvmmonitor.ui_1.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.jmx.local_1.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.jmx.ui_1.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.jsf_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.jboss.tools.jsf.feature_3.6.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.jsf.text.ext_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.jsf.text.ext.facelets_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.jsf.text.ext.richfaces_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.jsf.ui_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.jsf.verification_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.jsf.vpe.ajax4jsf_3.6.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.jsf.vpe.facelets_3.6.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.jsf.vpe.jbpm_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.jsf.vpe.jsf_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.jsf.vpe.jstl_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.jsf.vpe.myfaces_3.6.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.jsf.vpe.richfaces_3.6.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.jsf.vpe.seam_3.6.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.jboss.tools.jst.feature_3.6.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.jst.web_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.jst.web.kb_3.6.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.jst.web.ui_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.maven.conversion.ui_1.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.maven.core_1.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.jboss.tools.maven.feature_1.6.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.maven.project.examples_2.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.jboss.tools.maven.project.examples.feature_2.0.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.maven.ui_1.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.portlet.core_1.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.project.examples_2.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.project.examples.cheatsheet_2.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.jboss.tools.project.examples.feature_2.0.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.runtime.core_3.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.jboss.tools.runtime.core.feature_3.0.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.runtime.seam.detector_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.jboss.tools.runtime.seam.detector.feature_3.6.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.runtime.ui_3.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.seam.core_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.jboss.tools.seam.feature_3.6.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.seam.pages.xml_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.seam.text.ext_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.seam.ui_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.seam.ui.pages_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.seam.xml_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.seam.xml.ui_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.stacks.core_1.1.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.jboss.tools.stacks.core.feature_1.1.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.usage_2.0.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.vpe_3.6.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.vpe.docbook_3.6.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.jboss.tools.vpe.feature_3.6.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.vpe.html_3.6.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.vpe.jsp_3.6.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.vpe.preview_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.vpe.preview.core_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.vpe.preview.editor_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.jboss.tools.vpe.preview.feature_3.6.0.CR2-v20140923-2244
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.vpe.resref_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.vpe.spring_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.vpe.ui.palette_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.vpe.xulrunner_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.jboss.tools.xulrunner.initializer_3.6.0.CR2-v20140923-2244.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.mozilla.xpcom_1.9.2.16
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.mozilla.xulrunner.gtk.linux.x86_64_1.9.2.19pre
> /home/eskimo/Temp/jbt-new-tern/eclipse/plugins/org.sonatype.m2e.egit_0.14.0.201406241643.jar
> /home/eskimo/Temp/jbt-new-tern/eclipse/features/org.sonatype.m2e.egit.feature_0.14.0.201406241643
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19595) on central load java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19595?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen closed JBIDE-19595.
---------------------------------------
Resolution: Duplicate Issue
that makes sense. still weird java9 would break this ;/
> on central load java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
> ----------------------------------------------------------------------------
>
> Key: JBIDE-19595
> URL: https://issues.jboss.org/browse/JBIDE-19595
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: central
> Environment: devstudio 9 installer install, osx
> Reporter: Max Rydahl Andersen
>
> on first start of devstudio I got a dialog popping up and this error in log:
> {code}
> java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
> at org.jboss.tools.project.examples.model.ProjectExampleUtil.fetchCategories(ProjectExampleUtil.java:392)
> at org.jboss.tools.project.examples.model.ProjectExampleUtil.getProjects(ProjectExampleUtil.java:269)
> at org.jboss.tools.project.examples.model.ProjectExampleUtil.getProjects(ProjectExampleUtil.java:260)
> at org.jboss.tools.central.jobs.RefreshTutorialsJob.run(RefreshTutorialsJob.java:52)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBException cannot be found by org.jboss.tools.project.examples_3.0.0.Alpha2-v20150409-0258-B668
> at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:439)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:352)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:344)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
> ... 5 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3276) JBDS-IS Installer
by Paul Leacu (JIRA)
[ https://issues.jboss.org/browse/JBDS-3276?page=com.atlassian.jira.plugin.... ]
Paul Leacu commented on JBDS-3276:
----------------------------------
And yes - the JBDSIS installer was always meant to be separate from the JBDS standalone installer. Our release cycle requires it. Once we release we'll have to sync with JBDS releases so user don't install JBDSIS and end up with an older JBDS.
> JBDS-IS Installer
> -----------------
>
> Key: JBDS-3276
> URL: https://issues.jboss.org/browse/JBDS-3276
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: installer, integration-platform, requirements
> Affects Versions: 8.0.0.GA
> Reporter: Burr Sutter
> Assignee: Denis Golovin
> Attachments: Red Hat JBoss Developer Studio 9.0.0.Alpha2_105.png
>
>
> As a Fuse, integration-focused developer, I need a downloadable installer that will allow me to quickly and easily install JBDS with Fuse capabilities.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3276) JBDS-IS Installer
by Paul Leacu (JIRA)
[ https://issues.jboss.org/browse/JBDS-3276?page=com.atlassian.jira.plugin.... ]
Paul Leacu commented on JBDS-3276:
----------------------------------
I'm working through a couple of things before I can get to this - [~maxandersen] - what's the UX-wise - what specifically would you like to see?
> JBDS-IS Installer
> -----------------
>
> Key: JBDS-3276
> URL: https://issues.jboss.org/browse/JBDS-3276
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: installer, integration-platform, requirements
> Affects Versions: 8.0.0.GA
> Reporter: Burr Sutter
> Assignee: Denis Golovin
> Attachments: Red Hat JBoss Developer Studio 9.0.0.Alpha2_105.png
>
>
> As a Fuse, integration-focused developer, I need a downloadable installer that will allow me to quickly and easily install JBDS with Fuse capabilities.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19425) Error when loading projects in Central with Java 9
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19425?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-19425:
----------------------------------------
I believe it's more likely an issue between Equinox and Java 9. Equinox is probably failing at exposing some JRE 9 classes that were moved into JVM module.
> Error when loading projects in Central with Java 9
> --------------------------------------------------
>
> Key: JBIDE-19425
> URL: https://issues.jboss.org/browse/JBIDE-19425
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: central
> Affects Versions: 4.3.0.Alpha1
> Reporter: Martin Malina
> Assignee: Fred Bricon
> Labels: Java9
> Fix For: 4.3.x
>
>
> Today I wanted to try out the latest build of Oracle JDK 1.9 beta and discovered a problem with central.
> When I started JBDS, I immediately got an error window pop up:
> {code}
> Refreshing JBoss Tutorials... has encountered a problem.
> An internal error occurred during: "Refreshing JBoss Tutorials...".
> javax/xml/bind/JAXBException
> {code}
> This is in the workspace log:
> {code}
> !ENTRY org.eclipse.core.jobs 4 2 2015-03-10 17:12:52.346
> !MESSAGE An internal error occurred during: "Refreshing JBoss Tutorials...".
> !STACK 0
> java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
> at org.jboss.tools.project.examples.model.ProjectExampleUtil.fetchCategories(ProjectExampleUtil.java:389)
> at org.jboss.tools.project.examples.model.ProjectExampleUtil.getProjects(ProjectExampleUtil.java:266)
> at org.jboss.tools.project.examples.model.ProjectExampleUtil.getProjects(ProjectExampleUtil.java:257)
> at org.jboss.tools.central.jobs.RefreshTutorialsJob.run(RefreshTutorialsJob.java:52)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBException cannot be found by org.jboss.tools.project.examples_3.0.0.Alpha1-v20150213-0945-B3
> at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:439)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:352)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:344)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
> ... 5 more
> {code}
> I used JBDS 9.0.0.Alpha1 installed on OS X 10.10 Yosemite with Oracle JDK 1.9:
> {code}
> nattura:9.0.0 rasp$ java -version
> java version "1.9.0-ea"
> Java(TM) SE Runtime Environment (build 1.9.0-ea-b53)
> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b53, mixed mode)
> {code}
> The consequence of this is that the "Start from scratch" section in Central is not loaded and shows "No entries found".
> Note: When I installed the same JBDS with Java 8, there was no error.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19595) on central load java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19595?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-19595:
---------------------------------------
I think this is a duplicate of JBIDE-19425.
As a consequence of JBDS-3036 (ignored .ini), your JBDS was running with Java 9 (at least that happens to me) and then you get this Java 9 specific error.
> on central load java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
> ----------------------------------------------------------------------------
>
> Key: JBIDE-19595
> URL: https://issues.jboss.org/browse/JBIDE-19595
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: central
> Environment: devstudio 9 installer install, osx
> Reporter: Max Rydahl Andersen
>
> on first start of devstudio I got a dialog popping up and this error in log:
> {code}
> java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
> at org.jboss.tools.project.examples.model.ProjectExampleUtil.fetchCategories(ProjectExampleUtil.java:392)
> at org.jboss.tools.project.examples.model.ProjectExampleUtil.getProjects(ProjectExampleUtil.java:269)
> at org.jboss.tools.project.examples.model.ProjectExampleUtil.getProjects(ProjectExampleUtil.java:260)
> at org.jboss.tools.central.jobs.RefreshTutorialsJob.run(RefreshTutorialsJob.java:52)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBException cannot be found by org.jboss.tools.project.examples_3.0.0.Alpha2-v20150409-0258-B668
> at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:439)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:352)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:344)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
> ... 5 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3411) have installer build actually use M6 p2 product build
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3411?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen reassigned JBDS-3411:
-----------------------------------------
Assignee: Denis Golovin (was: Max Rydahl Andersen)
> have installer build actually use M6 p2 product build
> -----------------------------------------------------
>
> Key: JBDS-3411
> URL: https://issues.jboss.org/browse/JBDS-3411
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer, updatesite
> Reporter: Max Rydahl Andersen
> Assignee: Denis Golovin
> Priority: Critical
>
> talking with [~prapicault] I learned that since M6 the following changes are required for proper working p2 product/osx build:
> {code}
> <products>
> <product>
> ...
> <rootFolders>
> <macosx>MyProduct.app</macosx>
> </rootFolders>
> </product>
> {code}
> And to use tycho 0.23-snapshot
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19596) Connection wizard: have to retype password if I want to edit a v3 connection
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19596?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-19596:
-------------------------------------
Attachment: edit-v3-connection-wizard.png
edit-v3-connection.png
> Connection wizard: have to retype password if I want to edit a v3 connection
> ----------------------------------------------------------------------------
>
> Key: JBIDE-19596
> URL: https://issues.jboss.org/browse/JBIDE-19596
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.0.Alpha2
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.3.0.Alpha2
>
> Attachments: edit-v3-connection-wizard.png, edit-v3-connection.png
>
>
> Steps to reproduce:
> # ASSERT: make sure that you have a v3 connection listed in OpenShift explorer
> # EXEC: in explorer: select your connection and pick "Edit Connection"
> !edit-v3-connection.png!
> # ASSERT: connection dialog shows up
> Result:
> !edit-v3-connection-wizard.png!
> password text field is empty and required. You have to re-type your password
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19596) Connection wizard: have to retype password if I want to edit a v3 connection
by Andre Dietisheim (JIRA)
Andre Dietisheim created JBIDE-19596:
----------------------------------------
Summary: Connection wizard: have to retype password if I want to edit a v3 connection
Key: JBIDE-19596
URL: https://issues.jboss.org/browse/JBIDE-19596
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: openshift
Affects Versions: 4.3.0.Alpha2
Reporter: Andre Dietisheim
Assignee: Andre Dietisheim
Steps to reproduce:
# ASSERT: make sure that you have a v3 connection listed in OpenShift explorer
# EXEC: in explorer: select your connection and pick "Edit Connection"
!edit-v3-connection.png!
# ASSERT: connection dialog shows up
Result:
!edit-v3-connection-wizard.png!
password text field is empty and required. You have to re-type your password
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19596) Connection wizard: have to retype password if I want to edit a v3 connection
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19596?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-19596:
-------------------------------------
Fix Version/s: 4.3.0.Alpha2
> Connection wizard: have to retype password if I want to edit a v3 connection
> ----------------------------------------------------------------------------
>
> Key: JBIDE-19596
> URL: https://issues.jboss.org/browse/JBIDE-19596
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.0.Alpha2
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.3.0.Alpha2
>
>
> Steps to reproduce:
> # ASSERT: make sure that you have a v3 connection listed in OpenShift explorer
> # EXEC: in explorer: select your connection and pick "Edit Connection"
> !edit-v3-connection.png!
> # ASSERT: connection dialog shows up
> Result:
> !edit-v3-connection-wizard.png!
> password text field is empty and required. You have to re-type your password
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19095) OpenShift show all env. vars in Console view are listed as "Snapshot Restore/Deploy for application ..."
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19095?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-19095:
------------------------------------------
nothing critical, postponing to 4.3.0.Beta1
> OpenShift show all env. vars in Console view are listed as "Snapshot Restore/Deploy for application ..."
> --------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-19095
> URL: https://issues.jboss.org/browse/JBIDE-19095
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.2.2.Final
> Reporter: Marián Labuda
> Assignee: Andre Dietisheim
> Priority: Minor
> Labels: environment_variables
> Fix For: 4.3.0.Beta1
>
> Attachments: erroneous-snapshot-restore-title.png
>
>
> While having an application on OpenShift and listing all environment variable on it, there is incorrect label in ConsoleView. While choosing specific console, the listed environment variables for specific application are labeled there as "Snapshot Restore/Deploy for application ... (domainname):".
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19095) OpenShift show all env. vars in Console view are listed as "Snapshot Restore/Deploy for application ..."
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19095?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-19095:
-------------------------------------
Fix Version/s: 4.3.0.Beta1
(was: 4.3.0.Alpha2)
> OpenShift show all env. vars in Console view are listed as "Snapshot Restore/Deploy for application ..."
> --------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-19095
> URL: https://issues.jboss.org/browse/JBIDE-19095
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.2.2.Final
> Reporter: Marián Labuda
> Assignee: Andre Dietisheim
> Priority: Minor
> Labels: environment_variables
> Fix For: 4.3.0.Beta1
>
> Attachments: erroneous-snapshot-restore-title.png
>
>
> While having an application on OpenShift and listing all environment variable on it, there is incorrect label in ConsoleView. While choosing specific console, the listed environment variables for specific application are labeled there as "Snapshot Restore/Deploy for application ... (domainname):".
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3411) have installer build actually use M6 p2 product build
by CDW Engine (JIRA)
[ https://issues.jboss.org/browse/JBDS-3411?page=com.atlassian.jira.plugin.... ]
CDW Engine updated JBDS-3411:
-----------------------------
CDW docs_ack: ?
CDW devel_ack: ?
CDW pm_ack: +
CDW qa_ack: ?
> have installer build actually use M6 p2 product build
> -----------------------------------------------------
>
> Key: JBDS-3411
> URL: https://issues.jboss.org/browse/JBDS-3411
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer, updatesite
> Reporter: Max Rydahl Andersen
> Assignee: Max Rydahl Andersen
> Priority: Critical
>
> talking with [~prapicault] I learned that since M6 the following changes are required for proper working p2 product/osx build:
> {code}
> <products>
> <product>
> ...
> <rootFolders>
> <macosx>MyProduct.app</macosx>
> </rootFolders>
> </product>
> {code}
> And to use tycho 0.23-snapshot
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3411) have installer build actually use M6 p2 product build
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3411?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen updated JBDS-3411:
--------------------------------------
CDW release: ?
Status: New (was: New)
Target Release: 9.0.0.GA
> have installer build actually use M6 p2 product build
> -----------------------------------------------------
>
> Key: JBDS-3411
> URL: https://issues.jboss.org/browse/JBDS-3411
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer, updatesite
> Reporter: Max Rydahl Andersen
> Assignee: Max Rydahl Andersen
> Priority: Critical
>
> talking with [~prapicault] I learned that since M6 the following changes are required for proper working p2 product/osx build:
> {code}
> <products>
> <product>
> ...
> <rootFolders>
> <macosx>MyProduct.app</macosx>
> </rootFolders>
> </product>
> {code}
> And to use tycho 0.23-snapshot
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3411) have installer build actually use M6 p2 product build
by Max Rydahl Andersen (JIRA)
Max Rydahl Andersen created JBDS-3411:
-----------------------------------------
Summary: have installer build actually use M6 p2 product build
Key: JBDS-3411
URL: https://issues.jboss.org/browse/JBDS-3411
Project: Developer Studio (JBoss Developer Studio)
Issue Type: Bug
Components: installer, updatesite
Reporter: Max Rydahl Andersen
Priority: Critical
talking with [~prapicault] I learned that since M6 the following changes are required for proper working p2 product/osx build:
{code}
<products>
<product>
...
<rootFolders>
<macosx>MyProduct.app</macosx>
</rootFolders>
</product>
{code}
And to use tycho 0.23-snapshot
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3411) have installer build actually use M6 p2 product build
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3411?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen reassigned JBDS-3411:
-----------------------------------------
Assignee: Max Rydahl Andersen
> have installer build actually use M6 p2 product build
> -----------------------------------------------------
>
> Key: JBDS-3411
> URL: https://issues.jboss.org/browse/JBDS-3411
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer, updatesite
> Reporter: Max Rydahl Andersen
> Assignee: Max Rydahl Andersen
> Priority: Critical
>
> talking with [~prapicault] I learned that since M6 the following changes are required for proper working p2 product/osx build:
> {code}
> <products>
> <product>
> ...
> <rootFolders>
> <macosx>MyProduct.app</macosx>
> </rootFolders>
> </product>
> {code}
> And to use tycho 0.23-snapshot
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3276) JBDS-IS Installer
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3276?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-3276:
-------------------------------------------
[~burrsutter] yes, this is another download since JBDS IS are not available when we go GA.
We do though use the exact same initial core installer to extend with the IS stuff.
The overhead described above is what was discussed at Face-2-face and it is upto JBDSIS engineering and QE to do this work.
If you have a better suggestion on how we make IS available as a single install for easy install without internet access I would be interested.
> JBDS-IS Installer
> -----------------
>
> Key: JBDS-3276
> URL: https://issues.jboss.org/browse/JBDS-3276
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: installer, integration-platform, requirements
> Affects Versions: 8.0.0.GA
> Reporter: Burr Sutter
> Assignee: Denis Golovin
> Attachments: Red Hat JBoss Developer Studio 9.0.0.Alpha2_105.png
>
>
> As a Fuse, integration-focused developer, I need a downloadable installer that will allow me to quickly and easily install JBDS with Fuse capabilities.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19590) Update module's README.md files with information about dependencies to other modules
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19590?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-19590:
---------------------------------------------
`mvn eclipse:eclipse` we definitely do not want to recommend using if can be avoided.
get-mojo doesn't support getting git repos afaik so I do not think it would work.
> Update module's README.md files with information about dependencies to other modules
> ------------------------------------------------------------------------------------
>
> Key: JBIDE-19590
> URL: https://issues.jboss.org/browse/JBIDE-19590
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Affects Versions: 4.3.0.Alpha2
> Reporter: Denis Golovin
>
> For almost every JBoss Tools module there are three major steps to configure eclipse workspace for development:
> 1. Set up target platform in preferences
> 2. Import JBT module sources into workspace
> 3. Import required JBT module sources into worksapce
> (1) and (2) are well documented in README.md files, but (3) is not (see forum reference for jbosstools-hibernate as an example).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3276) JBDS-IS Installer
by Burr Sutter (JIRA)
[ https://issues.jboss.org/browse/JBDS-3276?page=com.atlassian.jira.plugin.... ]
Burr Sutter commented on JBDS-3276:
-----------------------------------
The proposal is yet-another-jar, another downloadable? Or is the screenshot provided simply an extension to the existing installer jar/downloadable?
A new downloadable artifact will come with some additional overhead:
- Additional QE
- Updates to all the public facing web pages where JBDS is downloaded today
- Updates to both the SOA/BxMS-related docs as well as JBDS docs
> JBDS-IS Installer
> -----------------
>
> Key: JBDS-3276
> URL: https://issues.jboss.org/browse/JBDS-3276
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: installer, integration-platform, requirements
> Affects Versions: 8.0.0.GA
> Reporter: Burr Sutter
> Assignee: Denis Golovin
> Attachments: Red Hat JBoss Developer Studio 9.0.0.Alpha2_105.png
>
>
> As a Fuse, integration-focused developer, I need a downloadable installer that will allow me to quickly and easily install JBDS with Fuse capabilities.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-18752) Freemarker plugin does not work for square bracket (since JBT 4.2.0.Final)
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18752?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-18752:
---------------------------------------------
[~mirec.zatko] can you provide some logs from crashes ? it seem to work fine for me so its tricky to hunt down without reproducible case?
> Freemarker plugin does not work for square bracket (since JBT 4.2.0.Final)
> --------------------------------------------------------------------------
>
> Key: JBIDE-18752
> URL: https://issues.jboss.org/browse/JBIDE-18752
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: freemarker
> Affects Versions: 4.2.0.Final
> Reporter: Denis Golovin
> Assignee: Max Rydahl Andersen
> Fix For: 4.3.0.Alpha2
>
>
> From https://github.com/jbosstools/jbosstools-freemarker/issues/26
> {quote}
> When using the plugin to edit freemarker files that use the square bracket syntax the editor fails to highlight the syntax (this is happening in JBoss Tools 4.20 Final).
> I think the file: src / org / jboss / ide / eclipse / freemarker / editor / DocumentProvider.java
> on line 70 is causing the syntax highlighting problem:
> {code}if (ch != LexicalConstants.SQUARE_SYNTAX_MARKER.charAt(i)) {
> return SyntaxMode.ANGLE;
> }
> SQUARE_SYNTAX_MARKER.charAt(i)
> {code}
> It should start in 0 and have a different index than i (the index of the file content) to have a proper string matching. Also, SQUARE_SYNTAX_MARKER is [#ftl, not all files start with a ftl tag, so I don't see the need for "ftl" at the end, so that's why in the following example fix I put j < 2.
> e.g.
> {code}
> int j =0;
> for (; i < docLength && j < 2; i++) {
> char ch = document.getChar(i);
> if (ch != LexicalConstants.SQUARE_SYNTAX_MARKER.charAt(j)) {
> return SyntaxMode.ANGLE;
> }
> j++;
> }
> {code}
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3018) Install screen moves to bottom left corner of the screen
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3018?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen closed JBDS-3018.
-------------------------------------
Resolution: Cannot Reproduce Bug
3 people tried on different OSX and could not reproduce it so closing this for now.
> Install screen moves to bottom left corner of the screen
> --------------------------------------------------------
>
> Key: JBDS-3018
> URL: https://issues.jboss.org/browse/JBDS-3018
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer, upstream
> Affects Versions: 7.1.1.GA
> Environment: java version "1.8.0"
> Java(TM) SE Runtime Environment (build 1.8.0-b132)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)
> OSX 10.9.2
> One monitor
> No additional software for windows management
> Reporter: Arun Gupta
> Assignee: Denis Golovin
> Priority: Minor
> Fix For: 8.x, 9.0.x
>
> Attachments: Screen Shot 2014-04-21 at 9.07.53 PM.png
>
>
> I started the install as
> java -jar ~/Downloads/jbdevstudio-product-eap-universal-7.1.1.GA-v20140314-2145-B688.jar
> Install screen (step 1 of 9) popped up in the middle and then right away went in the bottom left corner of the screen as shown in attachment.
> This does not seem right.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3410) devstudio not reading jbdevstudio.ini on osx
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3410?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-3410:
-------------------------------------------
seems like copying studio/jbdevstudio.ini to studio/jbdevstudio.app/Contents/MacOS/jbdevstudio.ini fixes it.
> devstudio not reading jbdevstudio.ini on osx
> --------------------------------------------
>
> Key: JBDS-3410
> URL: https://issues.jboss.org/browse/JBDS-3410
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer
> Reporter: Max Rydahl Andersen
> Priority: Critical
>
> When starting on OSX it has noticable larger fonts than previous versions.
> It seems to be ignoring -Dorg.eclipse.swt.internal.carbon.smallFonts set in jbdevstudio.ini.
> comparing jbdevstudio8 vs 9 I see that in 8 the location was:
> studio/jbdevstudio.app/Contents/MacOS/jbdevstudio.ini
> but in 9 we have it at
> studio/jbdevstudio.ini
> so that could explain why it wont get picked up ?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3410) devstudio not reading jbdevstudio.ini on osx
by Max Rydahl Andersen (JIRA)
Max Rydahl Andersen created JBDS-3410:
-----------------------------------------
Summary: devstudio not reading jbdevstudio.ini on osx
Key: JBDS-3410
URL: https://issues.jboss.org/browse/JBDS-3410
Project: Developer Studio (JBoss Developer Studio)
Issue Type: Bug
Components: installer
Reporter: Max Rydahl Andersen
Priority: Critical
When starting on OSX it has noticable larger fonts than previous versions.
It seems to be ignoring -Dorg.eclipse.swt.internal.carbon.smallFonts set in jbdevstudio.ini.
comparing jbdevstudio8 vs 9 I see that in 8 the location was:
studio/jbdevstudio.app/Contents/MacOS/jbdevstudio.ini
but in 9 we have it at
studio/jbdevstudio.ini
so that could explain why it wont get picked up ?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19595) on central load java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19595?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen updated JBIDE-19595:
----------------------------------------
Description:
on first start of devstudio I got a dialog popping up and this error in log:
{code}
java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
at org.jboss.tools.project.examples.model.ProjectExampleUtil.fetchCategories(ProjectExampleUtil.java:392)
at org.jboss.tools.project.examples.model.ProjectExampleUtil.getProjects(ProjectExampleUtil.java:269)
at org.jboss.tools.project.examples.model.ProjectExampleUtil.getProjects(ProjectExampleUtil.java:260)
at org.jboss.tools.central.jobs.RefreshTutorialsJob.run(RefreshTutorialsJob.java:52)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBException cannot be found by org.jboss.tools.project.examples_3.0.0.Alpha2-v20150409-0258-B668
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:439)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:352)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:344)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
... 5 more
{code}
was:
{{{
java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
at org.jboss.tools.project.examples.model.ProjectExampleUtil.fetchCategories(ProjectExampleUtil.java:392)
at org.jboss.tools.project.examples.model.ProjectExampleUtil.getProjects(ProjectExampleUtil.java:269)
at org.jboss.tools.project.examples.model.ProjectExampleUtil.getProjects(ProjectExampleUtil.java:260)
at org.jboss.tools.central.jobs.RefreshTutorialsJob.run(RefreshTutorialsJob.java:52)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBException cannot be found by org.jboss.tools.project.examples_3.0.0.Alpha2-v20150409-0258-B668
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:439)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:352)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:344)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
... 5 more}}}
> on central load java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
> ----------------------------------------------------------------------------
>
> Key: JBIDE-19595
> URL: https://issues.jboss.org/browse/JBIDE-19595
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: central
> Environment: devstudio 9 installer install, osx
> Reporter: Max Rydahl Andersen
>
> on first start of devstudio I got a dialog popping up and this error in log:
> {code}
> java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
> at org.jboss.tools.project.examples.model.ProjectExampleUtil.fetchCategories(ProjectExampleUtil.java:392)
> at org.jboss.tools.project.examples.model.ProjectExampleUtil.getProjects(ProjectExampleUtil.java:269)
> at org.jboss.tools.project.examples.model.ProjectExampleUtil.getProjects(ProjectExampleUtil.java:260)
> at org.jboss.tools.central.jobs.RefreshTutorialsJob.run(RefreshTutorialsJob.java:52)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBException cannot be found by org.jboss.tools.project.examples_3.0.0.Alpha2-v20150409-0258-B668
> at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:439)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:352)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:344)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
> ... 5 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19595) on central load java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
by Max Rydahl Andersen (JIRA)
Max Rydahl Andersen created JBIDE-19595:
-------------------------------------------
Summary: on central load java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
Key: JBIDE-19595
URL: https://issues.jboss.org/browse/JBIDE-19595
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: central
Environment: devstudio 9 installer install, osx
Reporter: Max Rydahl Andersen
{{{
java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
at org.jboss.tools.project.examples.model.ProjectExampleUtil.fetchCategories(ProjectExampleUtil.java:392)
at org.jboss.tools.project.examples.model.ProjectExampleUtil.getProjects(ProjectExampleUtil.java:269)
at org.jboss.tools.project.examples.model.ProjectExampleUtil.getProjects(ProjectExampleUtil.java:260)
at org.jboss.tools.central.jobs.RefreshTutorialsJob.run(RefreshTutorialsJob.java:52)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBException cannot be found by org.jboss.tools.project.examples_3.0.0.Alpha2-v20150409-0258-B668
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:439)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:352)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:344)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
... 5 more}}}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (TOOLSDOC-624) JBDS-IS 8.0.1: Update Install Document
by Supriya Bharadwaj (JIRA)
[ https://issues.jboss.org/browse/TOOLSDOC-624?page=com.atlassian.jira.plug... ]
Supriya Bharadwaj resolved TOOLSDOC-624.
----------------------------------------
Resolution: Done
> JBDS-IS 8.0.1: Update Install Document
> ---------------------------------------
>
> Key: TOOLSDOC-624
> URL: https://issues.jboss.org/browse/TOOLSDOC-624
> Project: Documentation for JBoss Tools and Developer Studio
> Issue Type: Bug
> Reporter: Misha Ali
> Assignee: Supriya Bharadwaj
>
> 1. Installation Guide - in Fuse, we have our own Fuse Tooling Installation Guide. After comparing the content of the two installation guides, I don't have objections to getting rid of ours and reusing the one from JBDS IS. But:
> a) the guide should include (a link to) JBDS installation instructions; this information is currently missing and imo is very important in the isolated context of individual products' docs suites. Update: Four installation instructions are provided in the Install Guide at the moment. The first two are for installing JBDS, the latter two are for JBDS-IS. The latter two should have a prerequisite step that tells you to install JBDS and links to the relevant topics (the first two ways to install).
> b) the "From the table of categories, select the JBoss Developer Studio Integration Stack functionality you want to install and click Next." step of each procedure should be expanded with specific instructions for individual products, i.e. what components of the IS to install for Fuse, DV and B*MS
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-18672) cannot run ionic tabs (the default) app with cordovasim
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18672?page=com.atlassian.jira.plugi... ]
Ilya Buziuk updated JBIDE-18672:
--------------------------------
Sprint: Sprint #2 April 2015
> cannot run ionic tabs (the default) app with cordovasim
> -------------------------------------------------------
>
> Key: JBIDE-18672
> URL: https://issues.jboss.org/browse/JBIDE-18672
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cordovasim
> Affects Versions: 4.2.0.Final
> Environment: Mac OS X, JavaFX
> Reporter: Max Rydahl Andersen
> Assignee: Ilya Buziuk
> Labels: upstream
> Fix For: 4.3.0.Beta1
>
>
> run:
> ionic start ionic-demo
> import ionic-demo
> run as > cordova sim
> try use the app, click back.
> Two issues:
> 1) cordova sim complains about app.appexit not being supported
> 2) when trying to click do not show again I get the following in the cordovasim error log:
> Outstanding resource locks detected:
> ES2 Vram Pool: 51,815,392 used (19.3%), 51,815,392 managed (19.3%), 268,435,456 total
> 84 total resources being managed
> average resource age is 15.1 frames
> 0 resources at maximum supported age (0.0%)
> 16 resources marked permanent (19.0%)
> 17 resources have had mismatched locks (20.2%)
> 17 resources locked (20.2%)
> 30 resources contain interesting data (35.7%)
> 0 resources disappeared (0.0%)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19594) SSL callback: provide meaningful hostname verifier, stop always accepting hostnames
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19594?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-19594:
-------------------------------------
Summary: SSL callback: provide meaningful hostname verifier, stop always accepting hostnames (was: SSL callback: provide meaningful hostname verifier, drop always accepting hostnames)
> SSL callback: provide meaningful hostname verifier, stop always accepting hostnames
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-19594
> URL: https://issues.jboss.org/browse/JBIDE-19594
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.0.Alpha2
> Reporter: Andre Dietisheim
> Fix For: 4.3.0.Beta1
>
>
> We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:
> {code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
> public interface ISSLCertificateCallback {
> public boolean allowCertificate(X509Certificate[] chain);
> public boolean allowHostname(String hostname, SSLSession session);
> }
> {code}
> The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
> In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
> {code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
> @Override
> public boolean allowHostname(String hostname, SSLSession sslSession) {
> return true;
> }
> {code}
> We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.
> This issue came up JBIDE-19581 when there was no callback installed which made the hostname verification fail as in jdk. When fetching the quickstarts OSJC is reaching out to https://hub.openshift.com (https://hub.openshift.com/api/v1/quickstarts/promoted.json) while the ssl certificate presented only covers openshift.redhat.com:
> {code}
> * Server certificate:
> * subject: CN=openshift.redhat.com,O=Red Hat Inc.,L=Raleigh,ST=North Carolina,C=US
> * start date: Jul 23 00:00:00 2014 GMT
> * expire date: Jul 27 12:00:00 2017 GMT
> * common name: openshift.redhat.com
> * issuer: CN=DigiCert SHA2 High Assurance Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19594) SSL callback: provide meaningful hostname verifier, drop always accepting hostnames
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19594?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-19594:
-------------------------------------
Description:
We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:
{code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
public interface ISSLCertificateCallback {
public boolean allowCertificate(X509Certificate[] chain);
public boolean allowHostname(String hostname, SSLSession session);
}
{code}
The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
{code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
@Override
public boolean allowHostname(String hostname, SSLSession sslSession) {
return true;
}
{code}
We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.
This issue came up JBIDE-19581 when there was no callback installed which made the hostname verification fail as in jdk. When fetching the quickstarts OSJC is reaching out to https://hub.openshift.com (https://hub.openshift.com/api/v1/quickstarts/promoted.json) while the ssl certificate presented only covers openshift.redhat.com:
{code}
* Server certificate:
* subject: CN=openshift.redhat.com,O=Red Hat Inc.,L=Raleigh,ST=North Carolina,C=US
* start date: Jul 23 00:00:00 2014 GMT
* expire date: Jul 27 12:00:00 2017 GMT
* common name: openshift.redhat.com
* issuer: CN=DigiCert SHA2 High Assurance Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US
{code}
was:
We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:
{code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
public interface ISSLCertificateCallback {
public boolean allowCertificate(X509Certificate[] chain);
public boolean allowHostname(String hostname, SSLSession session);
}
{code}
The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
{code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
@Override
public boolean allowHostname(String hostname, SSLSession sslSession) {
return true;
}
{code}
We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.
This issue came up JBIDE-19581 when there was no callback installed which made the hostname verification failed as in jdk. When fetching the quickstarts OSJC is redirected to https://hub.openshift.com (https://hub.openshift.com/api/v1/quickstarts/promoted.json) while the ssl certificate presented for openshift.redhat.com covers only this host:
{code}
* Server certificate:
* subject: CN=openshift.redhat.com,O=Red Hat Inc.,L=Raleigh,ST=North Carolina,C=US
* start date: Jul 23 00:00:00 2014 GMT
* expire date: Jul 27 12:00:00 2017 GMT
* common name: openshift.redhat.com
* issuer: CN=DigiCert SHA2 High Assurance Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US
{code}
> SSL callback: provide meaningful hostname verifier, drop always accepting hostnames
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-19594
> URL: https://issues.jboss.org/browse/JBIDE-19594
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.0.Alpha2
> Reporter: Andre Dietisheim
> Fix For: 4.3.0.Beta1
>
>
> We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:
> {code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
> public interface ISSLCertificateCallback {
> public boolean allowCertificate(X509Certificate[] chain);
> public boolean allowHostname(String hostname, SSLSession session);
> }
> {code}
> The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
> In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
> {code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
> @Override
> public boolean allowHostname(String hostname, SSLSession sslSession) {
> return true;
> }
> {code}
> We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.
> This issue came up JBIDE-19581 when there was no callback installed which made the hostname verification fail as in jdk. When fetching the quickstarts OSJC is reaching out to https://hub.openshift.com (https://hub.openshift.com/api/v1/quickstarts/promoted.json) while the ssl certificate presented only covers openshift.redhat.com:
> {code}
> * Server certificate:
> * subject: CN=openshift.redhat.com,O=Red Hat Inc.,L=Raleigh,ST=North Carolina,C=US
> * start date: Jul 23 00:00:00 2014 GMT
> * expire date: Jul 27 12:00:00 2017 GMT
> * common name: openshift.redhat.com
> * issuer: CN=DigiCert SHA2 High Assurance Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19594) SSL callback: provide meaningful hostname verifier, drop always accepting hostnames
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19594?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-19594:
-------------------------------------
Description:
We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:
{code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
public interface ISSLCertificateCallback {
public boolean allowCertificate(X509Certificate[] chain);
public boolean allowHostname(String hostname, SSLSession session);
}
{code}
The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
{code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
@Override
public boolean allowHostname(String hostname, SSLSession sslSession) {
return true;
}
{code}
We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.
This issue came up JBIDE-19581 when there was no callback installed which made the hostname verification failed as in jdk. When fetching the quickstarts OSJC is redirected to https://hub.openshift.com (https://hub.openshift.com/api/v1/quickstarts/promoted.json) while the ssl certificate presented for openshift.redhat.com covers only this host:
{code}
* Server certificate:
* subject: CN=openshift.redhat.com,O=Red Hat Inc.,L=Raleigh,ST=North Carolina,C=US
* start date: Jul 23 00:00:00 2014 GMT
* expire date: Jul 27 12:00:00 2017 GMT
* common name: openshift.redhat.com
* issuer: CN=DigiCert SHA2 High Assurance Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US
{code}
was:
We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:
{code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
public interface ISSLCertificateCallback {
public boolean allowCertificate(X509Certificate[] chain);
public boolean allowHostname(String hostname, SSLSession session);
}
{code}
The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
{code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
@Override
public boolean allowHostname(String hostname, SSLSession sslSession) {
return true;
}
{code}
We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.
This issue came up JBIDE-19581 when there was no callback installed which made the hostname verification failed as in jdk. When fetching the quickstarts OSJC is redirected to https://hub.openshift.com while the ssl certificate presented for openshift.redhat.com covers only this host:
{code}
* Server certificate:
* subject: CN=openshift.redhat.com,O=Red Hat Inc.,L=Raleigh,ST=North Carolina,C=US
* start date: Jul 23 00:00:00 2014 GMT
* expire date: Jul 27 12:00:00 2017 GMT
* common name: openshift.redhat.com
* issuer: CN=DigiCert SHA2 High Assurance Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US
{code}
> SSL callback: provide meaningful hostname verifier, drop always accepting hostnames
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-19594
> URL: https://issues.jboss.org/browse/JBIDE-19594
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.0.Alpha2
> Reporter: Andre Dietisheim
> Fix For: 4.3.0.Beta1
>
>
> We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:
> {code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
> public interface ISSLCertificateCallback {
> public boolean allowCertificate(X509Certificate[] chain);
> public boolean allowHostname(String hostname, SSLSession session);
> }
> {code}
> The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
> In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
> {code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
> @Override
> public boolean allowHostname(String hostname, SSLSession sslSession) {
> return true;
> }
> {code}
> We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.
> This issue came up JBIDE-19581 when there was no callback installed which made the hostname verification failed as in jdk. When fetching the quickstarts OSJC is redirected to https://hub.openshift.com (https://hub.openshift.com/api/v1/quickstarts/promoted.json) while the ssl certificate presented for openshift.redhat.com covers only this host:
> {code}
> * Server certificate:
> * subject: CN=openshift.redhat.com,O=Red Hat Inc.,L=Raleigh,ST=North Carolina,C=US
> * start date: Jul 23 00:00:00 2014 GMT
> * expire date: Jul 27 12:00:00 2017 GMT
> * common name: openshift.redhat.com
> * issuer: CN=DigiCert SHA2 High Assurance Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19594) SSL callback: provide meaningful hostname verifier, drop always accepting hostnames
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19594?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-19594:
-------------------------------------
Description:
We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:
{code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
public interface ISSLCertificateCallback {
public boolean allowCertificate(X509Certificate[] chain);
public boolean allowHostname(String hostname, SSLSession session);
}
{code}
The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
{code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
@Override
public boolean allowHostname(String hostname, SSLSession sslSession) {
return true;
}
{code}
We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.
This issue came up JBIDE-19581 when there was no callback installed which made the hostname verification failed as in jdk. When fetching the quickstarts OSJC is redirected to https://hub.openshift.com while the ssl certificate presented for openshift.redhat.com covers only this host:
{code}
* Server certificate:
* subject: CN=openshift.redhat.com,O=Red Hat Inc.,L=Raleigh,ST=North Carolina,C=US
* start date: Jul 23 00:00:00 2014 GMT
* expire date: Jul 27 12:00:00 2017 GMT
* common name: openshift.redhat.com
* issuer: CN=DigiCert SHA2 High Assurance Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US
{code}
was:
We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:
{code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
public interface ISSLCertificateCallback {
public boolean allowCertificate(X509Certificate[] chain);
public boolean allowHostname(String hostname, SSLSession session);
}
{code}
The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
{code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
@Override
public boolean allowHostname(String hostname, SSLSession sslSession) {
return true;
}
{code}
We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.
This issue came up JBIDE-19581 when there was no callback installed which made the hostname verification failed as in jdk. OSJC is apparently talking to The ssl certificate used by
> SSL callback: provide meaningful hostname verifier, drop always accepting hostnames
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-19594
> URL: https://issues.jboss.org/browse/JBIDE-19594
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.0.Alpha2
> Reporter: Andre Dietisheim
> Fix For: 4.3.0.Beta1
>
>
> We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:
> {code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
> public interface ISSLCertificateCallback {
> public boolean allowCertificate(X509Certificate[] chain);
> public boolean allowHostname(String hostname, SSLSession session);
> }
> {code}
> The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
> In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
> {code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
> @Override
> public boolean allowHostname(String hostname, SSLSession sslSession) {
> return true;
> }
> {code}
> We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.
> This issue came up JBIDE-19581 when there was no callback installed which made the hostname verification failed as in jdk. When fetching the quickstarts OSJC is redirected to https://hub.openshift.com while the ssl certificate presented for openshift.redhat.com covers only this host:
> {code}
> * Server certificate:
> * subject: CN=openshift.redhat.com,O=Red Hat Inc.,L=Raleigh,ST=North Carolina,C=US
> * start date: Jul 23 00:00:00 2014 GMT
> * expire date: Jul 27 12:00:00 2017 GMT
> * common name: openshift.redhat.com
> * issuer: CN=DigiCert SHA2 High Assurance Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19594) SSL callback: provide meaningful hostname verifier, drop always accepting hostnames
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19594?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-19594:
-------------------------------------
Description:
We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:
{code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
public interface ISSLCertificateCallback {
public boolean allowCertificate(X509Certificate[] chain);
public boolean allowHostname(String hostname, SSLSession session);
}
{code}
The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
{code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
@Override
public boolean allowHostname(String hostname, SSLSession sslSession) {
return true;
}
{code}
We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.
This issue came up JBIDE-19581 when there was no callback installed which made the hostname verification failed as in jdk. OSJC is apparently talking to The ssl certificate used by
was:
We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:
{code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
public interface ISSLCertificateCallback {
public boolean allowCertificate(X509Certificate[] chain);
public boolean allowHostname(String hostname, SSLSession session);
}
{code}
The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
{code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
@Override
public boolean allowHostname(String hostname, SSLSession sslSession) {
return true;
}
{code}
We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.
This issue came up JBIDE-19581 when there was no callback installed which made the hostname verification failed as in jdk. The ssl certificate used by
> SSL callback: provide meaningful hostname verifier, drop always accepting hostnames
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-19594
> URL: https://issues.jboss.org/browse/JBIDE-19594
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.0.Alpha2
> Reporter: Andre Dietisheim
> Fix For: 4.3.0.Beta1
>
>
> We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:
> {code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
> public interface ISSLCertificateCallback {
> public boolean allowCertificate(X509Certificate[] chain);
> public boolean allowHostname(String hostname, SSLSession session);
> }
> {code}
> The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
> In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
> {code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
> @Override
> public boolean allowHostname(String hostname, SSLSession sslSession) {
> return true;
> }
> {code}
> We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.
> This issue came up JBIDE-19581 when there was no callback installed which made the hostname verification failed as in jdk. OSJC is apparently talking to The ssl certificate used by
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19594) SSL callback: provide meaningful hostname verifier, drop always accepting hostnames
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19594?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-19594 at 4/15/15 5:17 AM:
-------------------------------------------------------------------
An example of such a hostname verifier can be found in android land:
http://developer.android.com/reference/org/apache/http/conn/ssl/BrowserCo...
Another one can be found here: https://tersesystems.com/2014/03/23/fixing-hostname-verification/
{code}
class DefaultHostnameVerifier extends HostnameVerifier {
private val logger = LoggerFactory.getLogger(getClass)
def hostnameChecker: HostnameChecker = HostnameChecker.getInstance(HostnameChecker.TYPE_TLS)
def matchKerberos(hostname: String, principal: Principal) = HostnameChecker.`match`(hostname, principal.asInstanceOf[KerberosPrincipal])
def isKerberos(principal: Principal): Boolean = principal != null && principal.isInstanceOf[KerberosPrincipal]
def verify(hostname: String, session: SSLSession): Boolean = {
logger.debug(s"verify: hostname = $hostname")
val checker = hostnameChecker
val result = try {
session.getPeerCertificates match {
case Array(cert: X509Certificate, _*) =>
try {
checker.`match`(hostname, cert)
// Certificate matches hostname
true
} catch {
case e: CertificateException =>
// Certificate does not match hostname
logger.debug("verify: Certificate does not match hostname", e)
false
}
case notMatch =>
// Peer does not have any certificates or they aren't X.509
logger.debug(s"verify: Peer does not have any certificates: $notMatch")
false
}
} catch {
case _: SSLPeerUnverifiedException =>
// Not using certificates for verification, try verifying the principal
try {
val principal = session.getPeerPrincipal
if (isKerberos(principal)) {
matchKerberos(hostname, principal)
} else {
// Can't verify principal, not Kerberos
logger.debug(s"verify: Can't verify principal, not Kerberos")
false
}
} catch {
case e: SSLPeerUnverifiedException =>
// Can't verify principal, no principal
logger.debug("Can't verify principal, no principal", e)
false
}
}
logger.debug("verify: returning {}", result)
result
}
}
{code}
and here: http://kevinlocke.name/bits/2012/10/03/ssl-certificate-verification-in-di...
{code}
/* An example program using AsyncHttpClient with SSL certificate verification
*
* To the extent possible under law, Kevin Locke has waived all copyright and
* related or neighboring rights to this work.
* A legal description of this waiver is available in LICENSE.txt.
*/
import com.ning.http.client.AsyncHttpClient;
import com.ning.http.client.AsyncHttpClientConfig;
import com.ning.http.client.Response;
import java.io.IOException;
import java.security.KeyManagementException;
import java.security.NoSuchAlgorithmException;
import java.security.Principal;
import java.security.cert.Certificate;
import java.security.cert.CertificateException;
import java.security.cert.X509Certificate;
import java.util.concurrent.ExecutionException;
import javax.net.ssl.HostnameVerifier;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLPeerUnverifiedException;
import javax.net.ssl.SSLSession;
import javax.security.auth.kerberos.KerberosPrincipal;
import sun.security.util.HostnameChecker;
/** Implements the "MyDownloader" application */
public class MyDownloader {
/** HostnameVerifier implementation which implements the same policy as the
* Java built-in pre-HostnameVerifier policy.
*/
private static class MyHostnameVerifier implements HostnameVerifier {
/** Checks if a given hostname matches the certificate or principal of
* a given session.
*/
private boolean hostnameMatches(String hostname, SSLSession session) {
HostnameChecker checker =
HostnameChecker.getInstance(HostnameChecker.TYPE_TLS);
boolean validCertificate = false, validPrincipal = false;
try {
Certificate[] peerCertificates = session.getPeerCertificates();
if (peerCertificates.length > 0 &&
peerCertificates[0] instanceof X509Certificate) {
X509Certificate peerCertificate =
(X509Certificate)peerCertificates[0];
try {
checker.match(hostname, peerCertificate);
// Certificate matches hostname
validCertificate = true;
} catch (CertificateException ex) {
// Certificate does not match hostname
}
} else {
// Peer does not have any certificates or they aren't X.509
}
} catch (SSLPeerUnverifiedException ex) {
// Not using certificates for peers, try verifying the principal
try {
Principal peerPrincipal = session.getPeerPrincipal();
if (peerPrincipal instanceof KerberosPrincipal) {
validPrincipal = HostnameChecker.match(hostname,
(KerberosPrincipal)peerPrincipal);
} else {
// Can't verify principal, not Kerberos
}
} catch (SSLPeerUnverifiedException ex2) {
// Can't verify principal, no principal
}
}
return validCertificate || validPrincipal;
}
public boolean verify(String hostname, SSLSession session) {
if (hostnameMatches(hostname, session)) {
return true;
} else {
// TODO: Add application-specific checks for
// hostname/certificate match
return false;
}
}
}
public static void main(String[] args) {
if (args.length != 1) {
System.err.println("Usage: myhttp <URL>");
} else {
String url = args[0];
SSLContext context = null;
try {
context = SSLContext.getInstance("TLS");
} catch (NoSuchAlgorithmException e) {
e.printStackTrace();
return;
}
try {
context.init(null, null, null);
} catch (KeyManagementException e) {
e.printStackTrace();
return;
}
AsyncHttpClient client = new AsyncHttpClient(
new AsyncHttpClientConfig.Builder()
.setSSLContext(context)
.setHostnameVerifier(new MyHostnameVerifier())
.build()
);
Response response = null;
try {
response = client.prepareGet(url).execute().get();
} catch (InterruptedException e) {
e.printStackTrace();
return;
} catch (ExecutionException e) {
e.printStackTrace();
return;
} catch (IOException e) {
e.printStackTrace();
return;
}
if (response.getStatusCode() / 100 == 2) {
try {
String responseBody = response.getResponseBody();
System.err.println("Successfully downloaded " + url);
System.out.println(responseBody);
} catch (IOException e) {
e.printStackTrace();
return;
}
} else {
System.err.println("Failure downloading " + url +
": HTTP Status " + response.getStatusCode());
}
}
}
}
{code}
was (Author: adietish):
An example of such a hostname verifier can be found in android land:
http://developer.android.com/reference/org/apache/http/conn/ssl/BrowserCo...
Another one can be found here: https://tersesystems.com/2014/03/23/fixing-hostname-verification/
{code}
class DefaultHostnameVerifier extends HostnameVerifier {
private val logger = LoggerFactory.getLogger(getClass)
def hostnameChecker: HostnameChecker = HostnameChecker.getInstance(HostnameChecker.TYPE_TLS)
def matchKerberos(hostname: String, principal: Principal) = HostnameChecker.`match`(hostname, principal.asInstanceOf[KerberosPrincipal])
def isKerberos(principal: Principal): Boolean = principal != null && principal.isInstanceOf[KerberosPrincipal]
def verify(hostname: String, session: SSLSession): Boolean = {
logger.debug(s"verify: hostname = $hostname")
val checker = hostnameChecker
val result = try {
session.getPeerCertificates match {
case Array(cert: X509Certificate, _*) =>
try {
checker.`match`(hostname, cert)
// Certificate matches hostname
true
} catch {
case e: CertificateException =>
// Certificate does not match hostname
logger.debug("verify: Certificate does not match hostname", e)
false
}
case notMatch =>
// Peer does not have any certificates or they aren't X.509
logger.debug(s"verify: Peer does not have any certificates: $notMatch")
false
}
} catch {
case _: SSLPeerUnverifiedException =>
// Not using certificates for verification, try verifying the principal
try {
val principal = session.getPeerPrincipal
if (isKerberos(principal)) {
matchKerberos(hostname, principal)
} else {
// Can't verify principal, not Kerberos
logger.debug(s"verify: Can't verify principal, not Kerberos")
false
}
} catch {
case e: SSLPeerUnverifiedException =>
// Can't verify principal, no principal
logger.debug("Can't verify principal, no principal", e)
false
}
}
logger.debug("verify: returning {}", result)
result
}
}
{code}
> SSL callback: provide meaningful hostname verifier, drop always accepting hostnames
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-19594
> URL: https://issues.jboss.org/browse/JBIDE-19594
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.0.Alpha2
> Reporter: Andre Dietisheim
> Fix For: 4.3.0.Beta1
>
>
> We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:
> {code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
> public interface ISSLCertificateCallback {
> public boolean allowCertificate(X509Certificate[] chain);
> public boolean allowHostname(String hostname, SSLSession session);
> }
> {code}
> The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
> In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
> {code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
> @Override
> public boolean allowHostname(String hostname, SSLSession sslSession) {
> return true;
> }
> {code}
> We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.
> This issue came up JBIDE-19581 when there was no callback installed which made the hostname verification failed as in jdk. The ssl certificate used by
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19594) SSL callback: provide meaningful hostname verifier, drop always accepting hostnames
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19594?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-19594 at 4/15/15 5:15 AM:
-------------------------------------------------------------------
An example of such a hostname verifier can be found in android land:
http://developer.android.com/reference/org/apache/http/conn/ssl/BrowserCo...
Another one can be found here: https://tersesystems.com/2014/03/23/fixing-hostname-verification/
{code}
class DefaultHostnameVerifier extends HostnameVerifier {
private val logger = LoggerFactory.getLogger(getClass)
def hostnameChecker: HostnameChecker = HostnameChecker.getInstance(HostnameChecker.TYPE_TLS)
def matchKerberos(hostname: String, principal: Principal) = HostnameChecker.`match`(hostname, principal.asInstanceOf[KerberosPrincipal])
def isKerberos(principal: Principal): Boolean = principal != null && principal.isInstanceOf[KerberosPrincipal]
def verify(hostname: String, session: SSLSession): Boolean = {
logger.debug(s"verify: hostname = $hostname")
val checker = hostnameChecker
val result = try {
session.getPeerCertificates match {
case Array(cert: X509Certificate, _*) =>
try {
checker.`match`(hostname, cert)
// Certificate matches hostname
true
} catch {
case e: CertificateException =>
// Certificate does not match hostname
logger.debug("verify: Certificate does not match hostname", e)
false
}
case notMatch =>
// Peer does not have any certificates or they aren't X.509
logger.debug(s"verify: Peer does not have any certificates: $notMatch")
false
}
} catch {
case _: SSLPeerUnverifiedException =>
// Not using certificates for verification, try verifying the principal
try {
val principal = session.getPeerPrincipal
if (isKerberos(principal)) {
matchKerberos(hostname, principal)
} else {
// Can't verify principal, not Kerberos
logger.debug(s"verify: Can't verify principal, not Kerberos")
false
}
} catch {
case e: SSLPeerUnverifiedException =>
// Can't verify principal, no principal
logger.debug("Can't verify principal, no principal", e)
false
}
}
logger.debug("verify: returning {}", result)
result
}
}
{code}
was (Author: adietish):
An example of such a hostname verifier can be found in android land:
http://developer.android.com/reference/org/apache/http/conn/ssl/BrowserCo...
> SSL callback: provide meaningful hostname verifier, drop always accepting hostnames
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-19594
> URL: https://issues.jboss.org/browse/JBIDE-19594
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.0.Alpha2
> Reporter: Andre Dietisheim
> Fix For: 4.3.0.Beta1
>
>
> We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:
> {code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
> public interface ISSLCertificateCallback {
> public boolean allowCertificate(X509Certificate[] chain);
> public boolean allowHostname(String hostname, SSLSession session);
> }
> {code}
> The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
> In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
> {code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
> @Override
> public boolean allowHostname(String hostname, SSLSession sslSession) {
> return true;
> }
> {code}
> We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.
> This issue came up JBIDE-19581 when there was no callback installed which made the hostname verification failed as in jdk. The ssl certificate used by
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-18752) Freemarker plugin does not work for square bracket (since JBT 4.2.0.Final)
by Miroslav Zaťko (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18752?page=com.atlassian.jira.plugi... ]
Miroslav Zaťko edited comment on JBIDE-18752 at 4/15/15 5:12 AM:
-----------------------------------------------------------------
Crashes, no colours and weird keyboard input responses as [~matteo.pelucco] wrote has nothing to do with ftl at the beginning of template.
It happens all the time regardless of ftl at the beginning, regardless of square brackets, angle brackets, regardless of anything... Only way how to reduce it a bit is saving to disk really often... Maybe after each character input...
This is why I removed the plugin...
was (Author: mirec.zatko):
Crashes, no colours and weird keyboard input responses as [~matteo.pelucco] wrote has nothing to do with ftl at the beginning of template.
It happens all the time regardless of ftl at the beginning, regardless of square brackets, angle brackets, regardless of anything... Only way how to reduce it a bit is to saving to disk really often... Maybe after each character input...
This is why I removed the plugin...
> Freemarker plugin does not work for square bracket (since JBT 4.2.0.Final)
> --------------------------------------------------------------------------
>
> Key: JBIDE-18752
> URL: https://issues.jboss.org/browse/JBIDE-18752
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: freemarker
> Affects Versions: 4.2.0.Final
> Reporter: Denis Golovin
> Assignee: Max Rydahl Andersen
> Fix For: 4.3.0.Alpha2
>
>
> From https://github.com/jbosstools/jbosstools-freemarker/issues/26
> {quote}
> When using the plugin to edit freemarker files that use the square bracket syntax the editor fails to highlight the syntax (this is happening in JBoss Tools 4.20 Final).
> I think the file: src / org / jboss / ide / eclipse / freemarker / editor / DocumentProvider.java
> on line 70 is causing the syntax highlighting problem:
> {code}if (ch != LexicalConstants.SQUARE_SYNTAX_MARKER.charAt(i)) {
> return SyntaxMode.ANGLE;
> }
> SQUARE_SYNTAX_MARKER.charAt(i)
> {code}
> It should start in 0 and have a different index than i (the index of the file content) to have a proper string matching. Also, SQUARE_SYNTAX_MARKER is [#ftl, not all files start with a ftl tag, so I don't see the need for "ftl" at the end, so that's why in the following example fix I put j < 2.
> e.g.
> {code}
> int j =0;
> for (; i < docLength && j < 2; i++) {
> char ch = document.getChar(i);
> if (ch != LexicalConstants.SQUARE_SYNTAX_MARKER.charAt(j)) {
> return SyntaxMode.ANGLE;
> }
> j++;
> }
> {code}
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-18752) Freemarker plugin does not work for square bracket (since JBT 4.2.0.Final)
by Miroslav Zaťko (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18752?page=com.atlassian.jira.plugi... ]
Miroslav Zaťko commented on JBIDE-18752:
----------------------------------------
Crashes, no colours and weird keyboard input responses as [~matteo.pelucco] wrote has nothing to do with ftl at the beginning of template.
It happens all the time regardless of ftl at the beginning, regardless of square brackets, angle brackets, regardless of anything... Only way how to reduce it a bit is to saving to disk really often... Maybe after each character input...
This is why I removed the plugin...
> Freemarker plugin does not work for square bracket (since JBT 4.2.0.Final)
> --------------------------------------------------------------------------
>
> Key: JBIDE-18752
> URL: https://issues.jboss.org/browse/JBIDE-18752
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: freemarker
> Affects Versions: 4.2.0.Final
> Reporter: Denis Golovin
> Assignee: Max Rydahl Andersen
> Fix For: 4.3.0.Alpha2
>
>
> From https://github.com/jbosstools/jbosstools-freemarker/issues/26
> {quote}
> When using the plugin to edit freemarker files that use the square bracket syntax the editor fails to highlight the syntax (this is happening in JBoss Tools 4.20 Final).
> I think the file: src / org / jboss / ide / eclipse / freemarker / editor / DocumentProvider.java
> on line 70 is causing the syntax highlighting problem:
> {code}if (ch != LexicalConstants.SQUARE_SYNTAX_MARKER.charAt(i)) {
> return SyntaxMode.ANGLE;
> }
> SQUARE_SYNTAX_MARKER.charAt(i)
> {code}
> It should start in 0 and have a different index than i (the index of the file content) to have a proper string matching. Also, SQUARE_SYNTAX_MARKER is [#ftl, not all files start with a ftl tag, so I don't see the need for "ftl" at the end, so that's why in the following example fix I put j < 2.
> e.g.
> {code}
> int j =0;
> for (; i < docLength && j < 2; i++) {
> char ch = document.getChar(i);
> if (ch != LexicalConstants.SQUARE_SYNTAX_MARKER.charAt(j)) {
> return SyntaxMode.ANGLE;
> }
> j++;
> }
> {code}
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19594) SSL callback: provide meaningful hostname verifier, drop always accepting hostnames
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19594?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-19594:
-------------------------------------
Description:
We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:
{code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
public interface ISSLCertificateCallback {
public boolean allowCertificate(X509Certificate[] chain);
public boolean allowHostname(String hostname, SSLSession session);
}
{code}
The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
{code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
@Override
public boolean allowHostname(String hostname, SSLSession sslSession) {
return true;
}
{code}
We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.
This issue came up JBIDE-19581 when there was no callback installed which made the hostname verification failed as in jdk. The ssl certificate used by
was:
We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:
{code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
public interface ISSLCertificateCallback {
public boolean allowCertificate(X509Certificate[] chain);
public boolean allowHostname(String hostname, SSLSession session);
}
{code}
The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
{code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
@Override
public boolean allowHostname(String hostname, SSLSession sslSession) {
return true;
}
{code}
We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.
> SSL callback: provide meaningful hostname verifier, drop always accepting hostnames
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-19594
> URL: https://issues.jboss.org/browse/JBIDE-19594
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.0.Alpha2
> Reporter: Andre Dietisheim
> Fix For: 4.3.0.Beta1
>
>
> We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:
> {code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
> public interface ISSLCertificateCallback {
> public boolean allowCertificate(X509Certificate[] chain);
> public boolean allowHostname(String hostname, SSLSession session);
> }
> {code}
> The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
> In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
> {code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
> @Override
> public boolean allowHostname(String hostname, SSLSession sslSession) {
> return true;
> }
> {code}
> We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.
> This issue came up JBIDE-19581 when there was no callback installed which made the hostname verification failed as in jdk. The ssl certificate used by
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19594) SSL callback: provide meaningful hostname verifier, drop always accepting hostnames
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19594?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-19594:
------------------------------------------
An example of such a hostname verifier can be found in android land:
http://developer.android.com/reference/org/apache/http/conn/ssl/BrowserCo...
> SSL callback: provide meaningful hostname verifier, drop always accepting hostnames
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-19594
> URL: https://issues.jboss.org/browse/JBIDE-19594
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.0.Alpha2
> Reporter: Andre Dietisheim
> Fix For: 4.3.0.Beta1
>
>
> We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:
> {code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
> public interface ISSLCertificateCallback {
> public boolean allowCertificate(X509Certificate[] chain);
> public boolean allowHostname(String hostname, SSLSession session);
> }
> {code}
> The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
> In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
> {code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
> @Override
> public boolean allowHostname(String hostname, SSLSession sslSession) {
> return true;
> }
> {code}
> We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19594) SSL callback: provide meaningful hostname verifier, drop always accepting hostnames
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19594?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-19594:
-------------------------------------
Fix Version/s: 4.3.0.Beta1
> SSL callback: provide meaningful hostname verifier, drop always accepting hostnames
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-19594
> URL: https://issues.jboss.org/browse/JBIDE-19594
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.0.Alpha2
> Reporter: Andre Dietisheim
> Fix For: 4.3.0.Beta1
>
>
> We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:
> {code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
> public interface ISSLCertificateCallback {
> public boolean allowCertificate(X509Certificate[] chain);
> public boolean allowHostname(String hostname, SSLSession session);
> }
> {code}
> The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
> In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
> {code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
> @Override
> public boolean allowHostname(String hostname, SSLSession sslSession) {
> return true;
> }
> {code}
> We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19594) SSL callback: provide meaningful hostname verifier, drop always accepting hostnames
by Andre Dietisheim (JIRA)
Andre Dietisheim created JBIDE-19594:
----------------------------------------
Summary: SSL callback: provide meaningful hostname verifier, drop always accepting hostnames
Key: JBIDE-19594
URL: https://issues.jboss.org/browse/JBIDE-19594
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: openshift
Affects Versions: 4.3.0.Alpha2
Reporter: Andre Dietisheim
We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:
{code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
public interface ISSLCertificateCallback {
public boolean allowCertificate(X509Certificate[] chain);
public boolean allowHostname(String hostname, SSLSession session);
}
{code}
The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
{code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
@Override
public boolean allowHostname(String hostname, SSLSession sslSession) {
return true;
}
{code}
We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19537) Document some of known problems in VPE FAQ related to using WebKit based internal browser
by Vlado Pakan (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19537?page=com.atlassian.jira.plugi... ]
Vlado Pakan closed JBIDE-19537.
-------------------------------
Verified on web
> Document some of known problems in VPE FAQ related to using WebKit based internal browser
> -----------------------------------------------------------------------------------------
>
> Key: JBIDE-19537
> URL: https://issues.jboss.org/browse/JBIDE-19537
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: visual-page-editor-core
> Affects Versions: 4.2.3.CR1, 4.3.0.Alpha2
> Reporter: Denis Golovin
> Assignee: Konstantin Marmalyukov
> Priority: Critical
> Fix For: 4.2.3.Final
>
>
> In latest 4.2.3.CR1 selecting "Change to HTML5" option in Browser Engine dialog sometime leads to problems after restart under Linux. It looks really bad because eclipse just disappear, never come back and there is no any trace of problem in logs. For me the reason was bluejeans.*.so files installed as part of BlueJeans. I also remember there was problem reported with google talk plugin.
> This should at least be documented in FAQ as known problems. Another more restrictive option is disable this feature for Linux completely.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (TOOLSDOC-628) JBDS-IS 8.0.1 RN: QE and PM Review
by Andrej Podhradsky (JIRA)
[ https://issues.jboss.org/browse/TOOLSDOC-628?page=com.atlassian.jira.plug... ]
Andrej Podhradsky resolved TOOLSDOC-628.
----------------------------------------
Resolution: Done
Reviewed, the doc is ok
> JBDS-IS 8.0.1 RN: QE and PM Review
> ----------------------------------
>
> Key: TOOLSDOC-628
> URL: https://issues.jboss.org/browse/TOOLSDOC-628
> Project: Documentation for JBoss Tools and Developer Studio
> Issue Type: Sub-task
> Components: Release Notes
> Reporter: Misha Ali
> Assignee: Andrej Podhradsky
>
> Asked [~pleacu] and [~apodhrad] to have a look at the draft version of the Release Notes and provide feedback on any missing items or changes required.
> Waiting on Bob (or someone else) to confirm whether all BPMN2 1.1.2 issues should be included or if we need a subset.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19536) Infinite job loop when creating project
by Rastislav Wagner (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19536?page=com.atlassian.jira.plugi... ]
Rastislav Wagner commented on JBIDE-19536:
------------------------------------------
[~akazakov] Yes, i was able to reproduce manually. The video I posted was a manual test. I was also able to reproduce on another machine.
> Infinite job loop when creating project
> ---------------------------------------
>
> Key: JBIDE-19536
> URL: https://issues.jboss.org/browse/JBIDE-19536
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi
> Affects Versions: 4.3.0.Alpha1
> Reporter: Rastislav Wagner
> Assignee: Viacheslav Kabanovich
> Fix For: 4.3.0.Beta1
>
> Attachments: cdi_jstack
>
>
> Sometimes i end up in infinite job loop after creating a CDI project. There's no description of what jobs are running, not exception in log. In progress view I can see only "Building workspace (sleeping)" -see on video https://vimeo.com/123634974
> I was able to reproduce on CDI projects (1.0,1.2) but not on any other (Dynamic Web..)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3018) Install screen moves to bottom left corner of the screen
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBDS-3018?page=com.atlassian.jira.plugin.... ]
Martin Malina commented on JBDS-3018:
-------------------------------------
Just to be sure I just tried in OS X 10.9.5 with JBDS 8.1 installer and it doesn't happen. Neither does it in OS X 10.10.3 with JBDS 8.1 or JBDS 9. So I suggest we resolve this as Out of Date.
> Install screen moves to bottom left corner of the screen
> --------------------------------------------------------
>
> Key: JBDS-3018
> URL: https://issues.jboss.org/browse/JBDS-3018
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer, upstream
> Affects Versions: 7.1.1.GA
> Environment: java version "1.8.0"
> Java(TM) SE Runtime Environment (build 1.8.0-b132)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)
> OSX 10.9.2
> One monitor
> No additional software for windows management
> Reporter: Arun Gupta
> Assignee: Denis Golovin
> Priority: Minor
> Fix For: 8.x, 9.0.x
>
> Attachments: Screen Shot 2014-04-21 at 9.07.53 PM.png
>
>
> I started the install as
> java -jar ~/Downloads/jbdevstudio-product-eap-universal-7.1.1.GA-v20140314-2145-B688.jar
> Install screen (step 1 of 9) popped up in the middle and then right away went in the bottom left corner of the screen as shown in attachment.
> This does not seem right.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (TOOLSDOC-624) JBDS-IS 8.0.1: Update Install Document
by Misha Ali (JIRA)
[ https://issues.jboss.org/browse/TOOLSDOC-624?page=com.atlassian.jira.plug... ]
Misha Ali commented on TOOLSDOC-624:
------------------------------------
Thanks, Supriya. Please resolve the issue when this is ready. I'm brewing this now to finalize docs for the release.
> JBDS-IS 8.0.1: Update Install Document
> ---------------------------------------
>
> Key: TOOLSDOC-624
> URL: https://issues.jboss.org/browse/TOOLSDOC-624
> Project: Documentation for JBoss Tools and Developer Studio
> Issue Type: Bug
> Reporter: Misha Ali
> Assignee: Supriya Bharadwaj
>
> 1. Installation Guide - in Fuse, we have our own Fuse Tooling Installation Guide. After comparing the content of the two installation guides, I don't have objections to getting rid of ours and reusing the one from JBDS IS. But:
> a) the guide should include (a link to) JBDS installation instructions; this information is currently missing and imo is very important in the isolated context of individual products' docs suites. Update: Four installation instructions are provided in the Install Guide at the moment. The first two are for installing JBDS, the latter two are for JBDS-IS. The latter two should have a prerequisite step that tells you to install JBDS and links to the relevant topics (the first two ways to install).
> b) the "From the table of categories, select the JBoss Developer Studio Integration Stack functionality you want to install and click Next." step of each procedure should be expanded with specific instructions for individual products, i.e. what components of the IS to install for Fuse, DV and B*MS
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
