[JBoss JIRA] (JBIDE-26821) Should remove outdated examples
by Stephane Bouchet (Jira)
[ https://issues.redhat.com/browse/JBIDE-26821?page=com.atlassian.jira.plug... ]
Stephane Bouchet updated JBIDE-26821:
-------------------------------------
Fix Version/s: 4.14.0.Final
(was: 4.14.0.AM1)
> Should remove outdated examples
> -------------------------------
>
> Key: JBIDE-26821
> URL: https://issues.redhat.com/browse/JBIDE-26821
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: central
> Affects Versions: 4.12.0.Final
> Reporter: André Dietisheim
> Priority: Major
> Fix For: 4.14.0.Final
>
>
> Testing all the examples I found many that use completely outdated JDK 1.6 or 1.7, some that use deprecated frameworks (deltaspike, picketlink, etc.), etc.
> * Web Applications
> ** batch-processing: NOK, JDK 1.7
> ** cdi-alternative: OK
> ** cdi-decorator: OK
> ** cdi-interceptors: NOK, xhtml validation warnings
> ** cdi-stereotype: OK
> ** deltaspike-authorization: NOK, JDK 1.6
> ** deltaspike-beanmanagerprovider: NOK, JDK 1.6, xhtml validation warnings, build warnings com.sun:tools.jar
> ** deltaspike-exception-handling: NOK, JDK 1.6, xhtml validation warnings, build warnings com.sun:tools.jar
> ** deltaspike-projectstage: NOK, JDK 1.6, xhtml validation warnings, build error com.sun:tools.jar
> ** ejb-in-war: OK
> ** ejb-security-propagation: NOK, validation warnings, build warnings com.sun:tools.jar
> ** greeter: NOK, xhtml validation errors
> ** helloworld: OK
> ** helloworld-cep: NOK, errors when creating: invalid project description
> ** helloworld-html5: NOK, JDK 1.6
> ** helloworld-rf: NOK, JDK 1.6
> ** inter-app: NOK, EJB validation warnings (EJB module must contain one or more e)
> ** jsonp: NOK, JDK 1.7
> ** kitchensink: OK
> ** kitchensink-angularjs: NOK, JDK 1.6, xhtml validation warnings, build warnings com.sun:tools.jar
> ** kitchensink-angularjs-bootstrap: NOK, JDK 1.6, xhtml validation warnings, build warnings com.sun:tools.jar
> ** kitchensink-angularjs-topcoat: NOK, JDK 1.6, xhtml validation warnings, build warnings com.sun:tools.jar
> ** kitchensink-deltaspike: NOK, JDK 1.6, xhtml validation warnings, build warnings com.sun:tools.jar
> ** kitchensink-ear: OK
> ** kitchensink-html5-mobile: NOK, JDK 1.6, build warnings com.sun:tools.jar
> ** kitchensink-ml: OK
> ** kitchensink-ml-ear: OK
> ** kitchensink-rf: NOK, JDK 1.6, build warnings com.sun:tools.jar
> ** mail: OK
> ** numberguess: OK
> ** payment-cdi-event: OK
> ** picketlink-angularjs-rest: NOK, JDK 1.6, html validation warnings
> (skipping all other picketlink examples, last commit in picketlink was 3y ago)
> ** servlet-async: OK
> ** servlet-filterlistener: OK
> ** servlet-security-genericreader-auth: NOK, maven build error (unresolvable parent pom)
> ** stateful-ksession: NOK, maven build error (unresolvable parent pom)
> ** tasks-jsf: OK
> ** temperature-converter: OK
> ** websocket-hello: OK
> ** xml-dom4j: OK
> ** xml-jaxp: OK
> * Mobile Applications:
> ** contacts-mobile-basic: NOK, JDK 1.6, (x)html validation warnings
> ** kitchesink-cordova: NOK, js & (x)html validation warnings
> ** kitchesink-cordova-contacts: NOK, html validation warnings
> ** push-contacts-mobile: NOK, does not compile
> (missing artifacts ex. com.google.android:android:jar:4.1.1.4, it's also creating a picktelink project)
> ** push-helloworld-android: NOK, JDK 1.6, missing artifacts ex. com.google.android:android:jar:4.1.1.4
> testing stopped here, should test all of them
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JBIDE-26792) OpenShift ITests: Fix failing ServerAdapterFromResourceTest
by Stephane Bouchet (Jira)
[ https://issues.redhat.com/browse/JBIDE-26792?page=com.atlassian.jira.plug... ]
Stephane Bouchet updated JBIDE-26792:
-------------------------------------
Fix Version/s: 4.14.0.Final
(was: 4.14.0.AM1)
> OpenShift ITests: Fix failing ServerAdapterFromResourceTest
> -----------------------------------------------------------
>
> Key: JBIDE-26792
> URL: https://issues.redhat.com/browse/JBIDE-26792
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: integration-tests, openshift
> Affects Versions: 4.13.0.AM1
> Reporter: Josef Kopriva
> Assignee: Josef Kopriva
> Priority: Major
> Fix For: 4.14.0.Final
>
>
> Test is failing on Jenkins:
> {code:java}
> org.eclipse.reddeer.common.exception.WaitTimeoutExpiredException:
> Timeout after: 120 s.: The following jobs are still running:
> Publishing to nodejs-example (Service) at OpenShift (127.0.0.1)...
> Stopping nodejs-example (Service) at OpenShift (127.0.0.1)
> Building workspace
> at org.jboss.tools.openshift.ui.bot.test.application.v3.adapter.ServerAdapterFromResourceTest.removeAdapterIfExists(ServerAdapterFromResourceTest.java:128)
> {code}
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JBIDE-26947) CDI Web Project created with CDI 1.2 settings shows version 1.1 in the beans.xml
by Stephane Bouchet (Jira)
[ https://issues.redhat.com/browse/JBIDE-26947?page=com.atlassian.jira.plug... ]
Stephane Bouchet updated JBIDE-26947:
-------------------------------------
Fix Version/s: 4.14.0.Final
(was: 4.14.0.AM1)
> CDI Web Project created with CDI 1.2 settings shows version 1.1 in the beans.xml
> --------------------------------------------------------------------------------
>
> Key: JBIDE-26947
> URL: https://issues.redhat.com/browse/JBIDE-26947
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi, cdi-extensions
> Affects Versions: 4.13.0.Final
> Environment: OS X
> Reporter: Zbyněk Červinka
> Assignee: Jeff MAURY
> Priority: Major
> Fix For: 4.14.0.Final
>
> Attachments: Project Facets with CDI 1.2 settings.png, beans.xml-gui.png, beans.xml-source.png
>
>
> When you create new CDI Web Project and during the process of project creation you set CDI 1.2 (in the Project Facets window), you will get a project with CDI 1.1 set in the beans.xml.
> h3. See the Project Facets with the CDI 1.2 settings (window accessible during creating new CDI Web Project):
> * !Project Facets with CDI 1.2 settings.png|thumbnail!
> h3. See the beans.xml with the CDI 1.1 settings:
> * beans.xml GUI:
> * !beans.xml-gui.png|thumbnail!
> * beans.xml text source code:
> * !beans.xml-source.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JBIDE-26916) Dynamic Web Project shows errors after converting to maven project when using WildFly 18 as target runtime and Java 11
by Stephane Bouchet (Jira)
[ https://issues.redhat.com/browse/JBIDE-26916?page=com.atlassian.jira.plug... ]
Stephane Bouchet updated JBIDE-26916:
-------------------------------------
Fix Version/s: 4.14.0.Final
(was: 4.14.0.AM1)
> Dynamic Web Project shows errors after converting to maven project when using WildFly 18 as target runtime and Java 11
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-26916
> URL: https://issues.redhat.com/browse/JBIDE-26916
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: maven
> Affects Versions: 4.13.0.AM1
> Environment: All OSes
> Reporter: Zbyněk Červinka
> Assignee: Jeff MAURY
> Priority: Major
> Fix For: 4.14.0.Final
>
> Attachments: RHCRS_preferences.png, dynamic_web_project_after_converting_to_maven.png, new_server_settings.png, project_facets_when_creating_the_project.png
>
>
> h2. Basic information on this issue:
> - Issue appears only when using WildFly 18 as target runtime and Java 11 (see the 'Steps to reproduce' section and printscreens in the attachment)
> - Issue does not appear on WildFly 16 and on WildFly 17 (tested on both Java 8 and 11; this issue has not appeared even if I have mixed Java version settings in workspace/server runtime JRE/Project fFacets, no issue for any combination)
> h2. Error messages from the Problems view:
> * Missing artifact jakarta.jws:jakarta.jws-api:jar:2.1.0 pom.xml
> * The container 'Maven Dependencies' references non existing library '/Users/zcervink/.m2/repository/jakarta/jws/jakarta.jws-api/2.1.0/jakarta.jws-api-2.1.0.jar'
> * The project cannot be built until build path errors are resolved
> h2. Tested solution - insert the following dependency into the pom.xml and all the problems in the Problems view disappear
> {code:java}
> <dependency>
> <groupId>jakarta.jws</groupId>
> <artifactId>jakarta.jws-api</artifactId>
> <version>1.1.1</version>
> </dependency>
> {code}
> h2. Red Hat CodeReady Studio version (version used to testing when creating this JIRA):
> Version: 12.13.0.GA
> Build id: GA-v20191024-0752-B5215
> Build date: 20191024-0752
> h2. Red Hat CodeReady Studio (newest version used to testing when updating this JIRA):
> Version: 12.14.0.AM1
> Build id: AM1-v20191122-0713-B5330
> Build date: 20191122-0713
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JBIDE-26893) Create universal template and label that would accommodate different rhel needed by interop testing team
by Stephane Bouchet (Jira)
[ https://issues.redhat.com/browse/JBIDE-26893?page=com.atlassian.jira.plug... ]
Stephane Bouchet updated JBIDE-26893:
-------------------------------------
Fix Version/s: 4.14.0.Final
(was: 4.14.0.AM1)
> Create universal template and label that would accommodate different rhel needed by interop testing team
> --------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-26893
> URL: https://issues.redhat.com/browse/JBIDE-26893
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: integration-tests, qa
> Affects Versions: 4.13.0.Final
> Reporter: Ondrej Dockal
> Assignee: Ondrej Dockal
> Priority: Major
> Labels: jenkins
> Fix For: 4.14.0.Final
>
>
> We would like to use universal label that would cover different rhel versions that are required by interop testing. The idea is that we will keep one/two label for interop testing slave: rhel-interop (and possibly for both stream, so rhel7-interop and rhel8-interop), which would have used image: rhel-interop-7(8)-snapshot that would have actually needed rhel version to test. During provisioning we will replace snapshot with proper rhel. This way we can keep these two labels and do not need to change interop test job label all the time via PR in cci-config repo.
> Reqs:
> * UMB trigger for interop rhel to run provision job with
> * job will be parametrized based on rhel version given by umb message
> * jenkins provisioning job build description needs to be updated to have available info about rhel version
>
> Pros:
> * do not need to change code via PR every time there is new bits to test
> * probably can be fully automated
> Cons:
> * only one version to test at a time
> * complex and possibly unstable?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JBIDE-26878) Improve validation of CRC Binary and Pull Secret File in CRC Server Wizard and Editor
by Stephane Bouchet (Jira)
[ https://issues.redhat.com/browse/JBIDE-26878?page=com.atlassian.jira.plug... ]
Stephane Bouchet updated JBIDE-26878:
-------------------------------------
Fix Version/s: 4.14.0.Final
(was: 4.14.0.AM1)
> Improve validation of CRC Binary and Pull Secret File in CRC Server Wizard and Editor
> -------------------------------------------------------------------------------------
>
> Key: JBIDE-26878
> URL: https://issues.redhat.com/browse/JBIDE-26878
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: cdk
> Affects Versions: 4.13.0.Final
> Reporter: Ondrej Dockal
> Assignee: Rob Stryker
> Priority: Major
> Fix For: 4.14.x, 4.14.0.Final
>
>
> I can image improved validation of Pull secret file that is available in CRC Server wizard and Server Editor.
> Missing validation of CRC Binary:
> * Please select a valid CRC Binary, which would check that file is really a crc binary - we used similar validation for minishift where (I f I recall it right) we checked in process the output from `minishift version` or `minishift status` command. Something similar I can imagine to be used for crc. Since `crc status` could return different outputs, version seems to be better option. I would agree to postpone this validation once the crc is GA. then please ignore this and create new jira issue. Thanks!
> I can imagine all of those validation in action for pull secret path input:
> * Path does not exist
> * Is not a file
> * Is not executable (user cannot read the file)
> * Is not a valid Pull secret file (probably check for if file's content is a valid json and/or we can probably validate if json's first object is "auths"? This would be nice, but simple json validation seems fine)
> I believe that last three points could be validated at once by reading the file's content and creating valid json object, or else showing the error that given path is no valid a secret file. It's up implementation, right?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months