[JBoss JIRA] (JBIDE-23312) When an OS certificate is accepted, the preference is not always saved
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23312?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-23312:
------------------------------------------
this was merged to master before code freeze for 4.4.2.AM2.
> When an OS certificate is accepted, the preference is not always saved
> ----------------------------------------------------------------------
>
> Key: JBIDE-23312
> URL: https://issues.jboss.org/browse/JBIDE-23312
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.2.AM1
> Reporter: Jeff MAURY
> Assignee: Viacheslav Kabanovich
> Labels: openshift, openshift_v3, preferences
> Fix For: 4.4.2.AM3
>
>
> EXEC: clean up Openshift V3 SSL certificates
> EXEC: connect to Openshift
> ASSERT: the certificate dialog should pop up
> EXEC:accept the cerificate and select remember
> EXEC: stop Eclipse
> EXEC: start Eclipse
> EXEC: connect to Openshift
> ASSERT: the certificate dialog popups again
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (JBIDE-23312) When an OS certificate is accepted, the preference is not always saved
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23312?page=com.atlassian.jira.plugi... ]
Andre Dietisheim reassigned JBIDE-23312:
----------------------------------------
Assignee: Viacheslav Kabanovich
> When an OS certificate is accepted, the preference is not always saved
> ----------------------------------------------------------------------
>
> Key: JBIDE-23312
> URL: https://issues.jboss.org/browse/JBIDE-23312
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.2.AM1
> Reporter: Jeff MAURY
> Assignee: Viacheslav Kabanovich
> Labels: openshift, openshift_v3, preferences
> Fix For: 4.4.2.AM3
>
>
> EXEC: clean up Openshift V3 SSL certificates
> EXEC: connect to Openshift
> ASSERT: the certificate dialog should pop up
> EXEC:accept the cerificate and select remember
> EXEC: stop Eclipse
> EXEC: start Eclipse
> EXEC: connect to Openshift
> ASSERT: the certificate dialog popups again
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (JBIDE-23380) MOJO that fails build if manifest in .core plugin has .ui dependency
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23380?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-23380:
--------------------------------
Description:
At a minimum, the mojo should:
foreach plugin, if plugin ends in .core, check plugin/META-INF/MANIFEST for Dependencies manifest header, and verify .ui is not included in the dependencies at all.
However, this minimum goal would not have solved the issue we are experiencing with foundation.checkup. The foundation.checkup plugin does not end in .core and so would be skipped by this simple algorithm.
So... we may wish to check transitive dependencies *only in the same repo*. For example, foundation.core depends on foundation.checker, and foundation.checker is in the same repo, so foundation.checker should also be checked for ui deps or fail.
was:See subject
> MOJO that fails build if manifest in .core plugin has .ui dependency
> --------------------------------------------------------------------
>
> Key: JBIDE-23380
> URL: https://issues.jboss.org/browse/JBIDE-23380
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Reporter: Rob Stryker
>
> At a minimum, the mojo should:
> foreach plugin, if plugin ends in .core, check plugin/META-INF/MANIFEST for Dependencies manifest header, and verify .ui is not included in the dependencies at all.
> However, this minimum goal would not have solved the issue we are experiencing with foundation.checkup. The foundation.checkup plugin does not end in .core and so would be skipped by this simple algorithm.
> So... we may wish to check transitive dependencies *only in the same repo*. For example, foundation.core depends on foundation.checker, and foundation.checker is in the same repo, so foundation.checker should also be checked for ui deps or fail.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (JBIDE-23093) use consistent variables across all jenkins jobs for streams, TP versions, etc.
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23093?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-23093:
------------------------------------
refactor vars in discovery jobs for consistency and simpler operation
> use consistent variables across all jenkins jobs for streams, TP versions, etc.
> -------------------------------------------------------------------------------
>
> Key: JBIDE-23093
> URL: https://issues.jboss.org/browse/JBIDE-23093
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.4.1.Final
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.4.2.AM3
>
>
> We have a number of inconsistencies between jobs / pom.xml:
> * TARGET_PLATFORM_CENTRAL_MAX vs. JBTCENTRALTARGET_VERSION
> * TARGET_PLATFORM_VERSION vs. TARGET_PLATFORM_VERSION_MIN
> * TARGET_PLATFORM_VERSION_MAXIMUM vs. TARGET_PLATFORM_VERSION_MAX
> * stream_jbt vs. jbosstools_site_stream
> * version_jbt, versionWithRespin_jbt, JBT_buildversion
> * version_ds, vesionWithResin_ds, JBDS_buildversion
> * devstudioReleaseVersion, JBDSVersion
> Should standardize these.
> Can script relationship between version_* and versionWithRespin_*:
> {code}
> version_jbt=$(echo ${versionWithRespin_jbt} | sed -e '/[abcdwxyz]$/ s/\(^.*\)\(.$\)/\1/')
> version_ds=$(echo ${versionWithRespin_ds} | sed -e '/[abcdwxyz]$/ s/\(^.*\)\(.$\)/\1/')
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (JBIDE-23030) Scaling a service changes the wrong deployment
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23030?page=com.atlassian.jira.plugi... ]
Fred Bricon commented on JBIDE-23030:
-------------------------------------
oc cluster up
open the webconsole
create a nodejs app
after the initial deployment, click deploy on the nodejs app build section
2nd deployment fails (timeout)
eclipse is not involved
> Scaling a service changes the wrong deployment
> ----------------------------------------------
>
> Key: JBIDE-23030
> URL: https://issues.jboss.org/browse/JBIDE-23030
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.4.1.AM3
> Reporter: Fred Bricon
> Assignee: Jeff Cantrill
> Priority: Critical
> Fix For: 4.4.2.AM3
>
>
> In openshift explorer, when scaling a service that has 2 deployments, it deploys pod from the oldest deployment instead of the latest. Eventually, these pods are killed by openshift.
> The workaround is to open the properties view and issue a scale command on a deployment directly.
> However, because scaling is such a front-and-center feature from the explorer, I believe it's critical we fix it ASAP
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (JBIDE-23311) Review xsd schema files in org.jboss.tools.as.catalog for wf 10.1
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23311?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-23311:
-------------------------------------
[~mmalina] If you notice, all of the listed "missing" schema are standard jee schema. They are included in WTP. We do not include them because it will confuse stuff and we already depend on WTP.
As for how to verify, I really don't know. I've always just tried autocomplete for specific schema if I want to test them and make sure it works.
My unit tests use WTP API to create a new xml file based on the schema and verify that the root element is correct. I don't test autocomplete for various parts of the schema.
Close this jira if you're satisified with this response.
> Review xsd schema files in org.jboss.tools.as.catalog for wf 10.1
> -----------------------------------------------------------------
>
> Key: JBIDE-23311
> URL: https://issues.jboss.org/browse/JBIDE-23311
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: server
> Affects Versions: 4.4.2.AM2
> Reporter: Martin Malina
> Assignee: Rob Stryker
>
> Rather than reopening JBIDE-23161 to ask you about some discrepancies that I found, I am opening this JIRA.
> I compared the contents of org.jboss.tools.as.catalog_3.2.2.v20160923-0424.jar and what's in the wildfly 10.1.0 zip. And there are some diffs. I understand that there will always be more in the plugin - we keep some previous versions. But there are many xsd files missing in the plugin:
> {code}
> $ comm -23 xsd-list-wf.txt xsd-list-plugin.txt
> application-client_6.xsd
> application-client_7.xsd
> application_1_4.xsd
> application_5.xsd
> application_6.xsd
> application_7.xsd
> ejb-jar_2_1.xsd
> ejb-jar_3_0.xsd
> ejb-jar_3_1.xsd
> ejb-jar_3_2.xsd
> j2ee_1_4.xsd
> j2ee_jaxrpc_mapping_1_1.xsd
> j2ee_web_services_1_1.xsd
> j2ee_web_services_client_1_1.xsd
> javaee_5.xsd
> javaee_6.xsd
> javaee_7.xsd
> javaee_web_services_1_2.xsd
> javaee_web_services_1_3.xsd
> javaee_web_services_1_4.xsd
> javaee_web_services_client_1_2.xsd
> javaee_web_services_client_1_3.xsd
> javaee_web_services_client_1_4.xsd
> jbxb_1_0.xsd
> jsp_2_0.xsd
> jsp_2_1.xsd
> jsp_2_2.xsd
> jsp_2_3.xsd
> orm_1_0.xsd
> persistence_1_0.xsd
> persistence_2_0.xsd
> web-app_2_4.xsd
> web-app_2_5.xsd
> web-app_3_0.xsd
> web-app_3_1.xsd
> web-common_3_0.xsd
> web-common_3_1.xsd
> web-facelettaglibrary_2_2.xsd
> web-facesconfig_1_2.xsd
> web-facesconfig_2_2.xsd
> web-fragment_3_0.xsd
> web-fragment_3_1.xsd
> web-jsptaglibrary_2_0.xsd
> web-jsptaglibrary_2_1.xsd
> web-partialresponse_2_2.xsd
> nattura:jar rasp$ find . -name javaee_7.xsd
> nattura:jar rasp$ comm -23 xsd-list-wf.txt xsd-list-plugin.txt
> application-client_6.xsd
> application-client_7.xsd
> application_1_4.xsd
> application_5.xsd
> application_6.xsd
> application_7.xsd
> ejb-jar_2_1.xsd
> ejb-jar_3_0.xsd
> ejb-jar_3_1.xsd
> ejb-jar_3_2.xsd
> j2ee_1_4.xsd
> j2ee_jaxrpc_mapping_1_1.xsd
> j2ee_web_services_1_1.xsd
> j2ee_web_services_client_1_1.xsd
> javaee_5.xsd
> javaee_6.xsd
> javaee_7.xsd
> javaee_web_services_1_2.xsd
> javaee_web_services_1_3.xsd
> javaee_web_services_1_4.xsd
> javaee_web_services_client_1_2.xsd
> javaee_web_services_client_1_3.xsd
> javaee_web_services_client_1_4.xsd
> jbxb_1_0.xsd
> jsp_2_0.xsd
> jsp_2_1.xsd
> jsp_2_2.xsd
> jsp_2_3.xsd
> orm_1_0.xsd
> persistence_1_0.xsd
> persistence_2_0.xsd
> web-app_2_4.xsd
> web-app_2_5.xsd
> web-app_3_0.xsd
> web-app_3_1.xsd
> web-common_3_0.xsd
> web-common_3_1.xsd
> web-facelettaglibrary_2_2.xsd
> web-facesconfig_1_2.xsd
> web-facesconfig_2_2.xsd
> web-fragment_3_0.xsd
> web-fragment_3_1.xsd
> web-jsptaglibrary_2_0.xsd
> web-jsptaglibrary_2_1.xsd
> web-partialresponse_2_2.xsd
> nattura:jar rasp$
> nattura:jar rasp$
> nattura:jar rasp$
> nattura:jar rasp$
> nattura:jar rasp$
> nattura:jar rasp$
> nattura:jar rasp$ comm -23 xsd-list-wf.txt xsd-list-plugin.txt
> application-client_6.xsd
> application-client_7.xsd
> application_1_4.xsd
> application_5.xsd
> application_6.xsd
> application_7.xsd
> ejb-jar_2_1.xsd
> ejb-jar_3_0.xsd
> ejb-jar_3_1.xsd
> ejb-jar_3_2.xsd
> j2ee_1_4.xsd
> j2ee_jaxrpc_mapping_1_1.xsd
> j2ee_web_services_1_1.xsd
> j2ee_web_services_client_1_1.xsd
> javaee_5.xsd
> javaee_6.xsd
> javaee_7.xsd
> javaee_web_services_1_2.xsd
> javaee_web_services_1_3.xsd
> javaee_web_services_1_4.xsd
> javaee_web_services_client_1_2.xsd
> javaee_web_services_client_1_3.xsd
> javaee_web_services_client_1_4.xsd
> jbxb_1_0.xsd
> jsp_2_0.xsd
> jsp_2_1.xsd
> jsp_2_2.xsd
> jsp_2_3.xsd
> orm_1_0.xsd
> persistence_1_0.xsd
> persistence_2_0.xsd
> web-app_2_4.xsd
> web-app_2_5.xsd
> web-app_3_0.xsd
> web-app_3_1.xsd
> web-common_3_0.xsd
> web-common_3_1.xsd
> web-facelettaglibrary_2_2.xsd
> web-facesconfig_1_2.xsd
> web-facesconfig_2_2.xsd
> web-fragment_3_0.xsd
> web-fragment_3_1.xsd
> web-jsptaglibrary_2_0.xsd
> web-jsptaglibrary_2_1.xsd
> web-partialresponse_2_2.xsd
> {code}
> But I randomly checked one and it was visible in Preferences -> XML -> XML Catalog. My guess is that these are not ours so they will be present in some Eclipse plugin and we don't need to add them. Can you confirm this?
> And in that case, what would you recommend as the best option to verify that our catalog is correct and also that the jboss.org.schema git repo is correct?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (JBIDE-23030) Scaling a service changes the wrong deployment
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23030?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-23030:
------------------------------------------
[~fbricon] can you give steps so that I can try to reproduce your failure (in upcoming oc releases, too)?
> Scaling a service changes the wrong deployment
> ----------------------------------------------
>
> Key: JBIDE-23030
> URL: https://issues.jboss.org/browse/JBIDE-23030
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.4.1.AM3
> Reporter: Fred Bricon
> Assignee: Jeff Cantrill
> Priority: Critical
> Fix For: 4.4.2.AM3
>
>
> In openshift explorer, when scaling a service that has 2 deployments, it deploys pod from the oldest deployment instead of the latest. Eventually, these pods are killed by openshift.
> The workaround is to open the properties view and issue a scale command on a deployment directly.
> However, because scaling is such a front-and-center feature from the explorer, I believe it's critical we fix it ASAP
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months