March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8418) Enhance the way licenses are presented and fix inconsistencies

by Petr Sakař (JIRA)

[ https://issues.jboss.org/browse/WFLY-8418?page=com.atlassian.jira.plugin.... ] Petr Sakař updated WFLY-8418: ----------------------------- Summary: Enhance the way licenses are presented and fix inconsistencies (was: (7.1.0) Enhance the way licenses are presented and fix inconsistencies) > Enhance the way licenses are presented and fix inconsistencies > -------------------------------------------------------------- > > Key: WFLY-8418 > URL: https://issues.jboss.org/browse/WFLY-8418 > Project: WildFly > Issue Type: Enhancement > Components: Build System > Affects Versions: 11.0.0.Alpha1 > Reporter: Petr Sakař > Assignee: Petr Sakař > Priority: Critical > Labels: downstream_dependency > > We need to provide a better view of the existing license information presented in the docs/licenses.xml file, in the form of a docs/licenses.html file that lists: > Group/Artifact/Version/License (name+original URL)/Local Copy(relative pathname link to local copy of the license in the licenses dir). > This can be achieved with an .xslt transformation that runs as part of the build process, which produces the desired licenses.html, and it would allow us to zip and forward the entire doc/licenses directory to a client that wants to evaluate the licenses used in Wildfly. > In addition we need to sanitize a bit the presented licensing information: > Licenses.html *MUST* contain a reference to the Wildfly version it applies to. It *MUST* also contain a timestamp (or build number) to uniquely identify it should it need changes within one Wildfly release cycle. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1491) It is not possible for a type declaration to extend a Java class

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-1491: ----------------------------------- Summary: It is not possible for a type declaration to extend a Java class Key: DROOLS-1491 URL: https://issues.jboss.org/browse/DROOLS-1491 Project: Drools Issue Type: Bug Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8418) (7.1.0) Enhance the way licenses are presented and fix inconsistencies

by Petr Sakař (JIRA)

[ https://issues.jboss.org/browse/WFLY-8418?page=com.atlassian.jira.plugin.... ] Petr Sakař updated WFLY-8418: ----------------------------- Description: We need to provide a better view of the existing license information presented in the docs/licenses.xml file, in the form of a docs/licenses.html file that lists: Group/Artifact/Version/License (name+original URL)/Local Copy(relative pathname link to local copy of the license in the licenses dir). This can be achieved with an .xslt transformation that runs as part of the build process, which produces the desired licenses.html, and it would allow us to zip and forward the entire doc/licenses directory to a client that wants to evaluate the licenses used in Wildfly. In addition we need to sanitize a bit the presented licensing information: Licenses.html *MUST* contain a reference to the Wildfly version it applies to. It *MUST* also contain a timestamp (or build number) to uniquely identify it should it need changes within one Wildfly release cycle. was: We need to provide a better view of the existing license information presented in the docs/licenses.xml file, in the form of a docs/licenses.html file that lists: Group/Artifact/Version/License (name+original URL)/Local Copy(relative pathname link to local copy of the license in the licenses dir). This can be achieved with an .xslt transformation that runs as part of the build process, which produces the desired licenses.html, and it would allow us to zip and forward the entire doc/licenses directory to a client that wants to evaluate the licenses used in EAP. In addition we need to sanitize a bit the presented licensing information: - License Names should adhere to the standard presented here: https://spdx.org/licenses/ (full license name). Apparently we present the same license using different names which can be confusing, e.g. The Apache Software License, Version 2.0, Apache Software License, Version 2.0, Apache License, Version 2.0, Apache 2, ASL 2.0 all refer essentially to Apache License 2.0 - The ActiveMQ package misses license name information, it should probably be Apache License 2.0. - relaxngDatatype misses full license info - Again, we shouldn't list simply "lgpl" Some example is attached on the JIRA. Licenses.html *MUST* contain a reference to the EAP version it applies to. It *MUST* also contain a timestamp (or build number) to uniquely identify it should it need changes within one EAP release cycle. > (7.1.0) Enhance the way licenses are presented and fix inconsistencies > ---------------------------------------------------------------------- > > Key: WFLY-8418 > URL: https://issues.jboss.org/browse/WFLY-8418 > Project: WildFly > Issue Type: Enhancement > Components: Build System > Affects Versions: 11.0.0.Alpha1 > Reporter: Petr Sakař > Assignee: Petr Sakař > Priority: Critical > Labels: downstream_dependency > > We need to provide a better view of the existing license information presented in the docs/licenses.xml file, in the form of a docs/licenses.html file that lists: > Group/Artifact/Version/License (name+original URL)/Local Copy(relative pathname link to local copy of the license in the licenses dir). > This can be achieved with an .xslt transformation that runs as part of the build process, which produces the desired licenses.html, and it would allow us to zip and forward the entire doc/licenses directory to a client that wants to evaluate the licenses used in Wildfly. > In addition we need to sanitize a bit the presented licensing information: > Licenses.html *MUST* contain a reference to the Wildfly version it applies to. It *MUST* also contain a timestamp (or build number) to uniquely identify it should it need changes within one Wildfly release cycle. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8418) (7.1.0) Enhance the way licenses are presented and fix inconsistencies

by Petr Sakař (JIRA)

[ https://issues.jboss.org/browse/WFLY-8418?page=com.atlassian.jira.plugin.... ] Petr Sakař updated WFLY-8418: ----------------------------- Security: (was: Red Hat Internal) > (7.1.0) Enhance the way licenses are presented and fix inconsistencies > ---------------------------------------------------------------------- > > Key: WFLY-8418 > URL: https://issues.jboss.org/browse/WFLY-8418 > Project: WildFly > Issue Type: Enhancement > Components: Build System > Affects Versions: 11.0.0.Alpha1 > Reporter: Petr Sakař > Assignee: Petr Sakař > Priority: Critical > Labels: downstream_dependency > > We need to provide a better view of the existing license information presented in the docs/licenses.xml file, in the form of a docs/licenses.html file that lists: > Group/Artifact/Version/License (name+original URL)/Local Copy(relative pathname link to local copy of the license in the licenses dir). > This can be achieved with an .xslt transformation that runs as part of the build process, which produces the desired licenses.html, and it would allow us to zip and forward the entire doc/licenses directory to a client that wants to evaluate the licenses used in EAP. > In addition we need to sanitize a bit the presented licensing information: > - License Names should adhere to the standard presented here: https://spdx.org/licenses/ (full license name). Apparently we present the same license using different names which can be confusing, e.g. The Apache Software License, Version 2.0, Apache Software License, Version 2.0, Apache License, Version 2.0, Apache 2, ASL 2.0 all refer essentially to Apache License 2.0 > > - The ActiveMQ package misses license name information, it should probably be Apache License 2.0. > - relaxngDatatype misses full license info > - Again, we shouldn't list simply "lgpl" > Some example is attached on the JIRA. > Licenses.html *MUST* contain a reference to the EAP version it applies to. It *MUST* also contain a timestamp (or build number) to uniquely identify it should it need changes within one EAP release cycle. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2569) Elytron properties-realm is not able to read users dynamically

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFCORE-2569: ------------------------------------ Summary: Elytron properties-realm is not able to read users dynamically Key: WFCORE-2569 URL: https://issues.jboss.org/browse/WFCORE-2569 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical Elytron properties-realm reads users only during server start. As consequence it means that when Elytron properties-realm is used for securing management interface and user is added through {{add-user.sh}} script then authentication with that user is not possible until server is reloaded/restarted. In legacy security, users can be added and used without needed of reloading server. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8415) Remove Elytron integration tests module from default build chain

by Petr Kremensky (JIRA)

[ https://issues.jboss.org/browse/WFLY-8415?page=com.atlassian.jira.plugin.... ] Petr Kremensky commented on WFLY-8415: -------------------------------------- [~ctomc] I can handle this one in case you're fine with http://pastebin.test.redhat.com/467005 > Remove Elytron integration tests module from default build chain > ---------------------------------------------------------------- > > Key: WFLY-8415 > URL: https://issues.jboss.org/browse/WFLY-8415 > Project: WildFly > Issue Type: Task > Components: Build System, Test Suite > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > > Elytron module is always part of the build chain now. We use separate jobs to run unit tests, integration tests and mixed domain tests and Elytron integration tests are now run in all of them. > e.g. command we use to run just unit tests {{mvn test -DskipTests -Dts.noSmoke}} now starts also Elytron module (same goes to mixed domain, domain and others). > Elytron integration module should behave as other test suite modules - be part of {{all-modules.module.profile}} profile, have its own {{elytron.module.profile}} with {{ts.elytron}} activation property. > see http://pastebin.test.redhat.com/467005 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8415) Remove Elytron integration tests module from default build chain

by Petr Kremensky (JIRA)

[ https://issues.jboss.org/browse/WFLY-8415?page=com.atlassian.jira.plugin.... ] Petr Kremensky updated WFLY-8415: --------------------------------- Description: Elytron module is always part of the build chain now. We use separate jobs to run unit tests, integration tests and mixed domain tests and Elytron integration tests are now run in all of them. e.g. command we use to run just unit tests {{mvn test -DskipTests -Dts.noSmoke}} now starts also Elytron module (same goes to mixed domain, domain and others). Elytron integration module should behave as other test suite modules - be part of {{all-modules.module.profile}} profile, have its own {{elytron.module.profile}} with {{ts.elytron}} activation property. see http://pastebin.test.redhat.com/467005 was: Elytron module is always part of the build chain now. We use separate jobs to run unit tests, integration tests and mixed domain tests and Elytron integration tests are now run in all of them. e.g. command we use to run just unit tests {{mvn test -DskipTests -Dts.noSmoke}} now starts also Elytron module (same goes to mixed domain, domain and others). Elytron integration module should behave as other test suite modules - be part of {{all-modules.module.profile}} profile, have its own {{elytron.module.profile}} with {{ts.elytron}} activation property. see http://pastebin.test.redhat.com/457432 > Remove Elytron integration tests module from default build chain > ---------------------------------------------------------------- > > Key: WFLY-8415 > URL: https://issues.jboss.org/browse/WFLY-8415 > Project: WildFly > Issue Type: Task > Components: Build System, Test Suite > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > > Elytron module is always part of the build chain now. We use separate jobs to run unit tests, integration tests and mixed domain tests and Elytron integration tests are now run in all of them. > e.g. command we use to run just unit tests {{mvn test -DskipTests -Dts.noSmoke}} now starts also Elytron module (same goes to mixed domain, domain and others). > Elytron integration module should behave as other test suite modules - be part of {{all-modules.module.profile}} profile, have its own {{elytron.module.profile}} with {{ts.elytron}} activation property. > see http://pastebin.test.redhat.com/467005 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8417) Create DistributedWorkManager implementation based on WF clustering API

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-8417: ---------------------------------- Summary: Create DistributedWorkManager implementation based on WF clustering API Key: WFLY-8417 URL: https://issues.jboss.org/browse/WFLY-8417 Project: WildFly Issue Type: Task Components: Clustering, JCA Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 12.0.0.Alpha1 The upgrade to JGroups 4.0 will break the JGroups DistributedWorkManager implementation in IronJacamar (which uses JGroups 3.x). JGroups is only used to broadcast/receive commands to the cluster. This can be easily implemented using the WildFly clustering API. Such an implementation will simplify the transition to JGroups 4.0 and future-proof WildFly from any new API breakage. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8416) Create BroadcastEndpoint implementation using WF clustering API

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-8416?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-8416: ------------------------------- Description: The upgrade to JGroups 4.0 will break the JGroups BroadcastEndpoint implementation in ActiveMQ Artemis (which uses JGroups 3.x). JGroups is only used to broadcast/receive a byte[] to the cluster. This can be easily implemented using the WildFly clustering API. Such an implementation will simplify the transition to JGroups 4.0 and future-proof WildFly from any new API breakage. (was: The upgrade to JGroups 4.0 will break the JGroups usage in ActiveMQ Artemis (which uses JGroups 3.x). JGroups is only used to broadcast/receive a byte[] to the cluster. This can be easily implemented using the WildFly clustering API. Such an implementation will simplify the transition to JGroups 4.0 and future-proof WildFly from any new API breakage.) > Create BroadcastEndpoint implementation using WF clustering API > --------------------------------------------------------------- > > Key: WFLY-8416 > URL: https://issues.jboss.org/browse/WFLY-8416 > Project: WildFly > Issue Type: Task > Components: Clustering, JMS > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 12.0.0.Alpha1 > > > The upgrade to JGroups 4.0 will break the JGroups BroadcastEndpoint implementation in ActiveMQ Artemis (which uses JGroups 3.x). JGroups is only used to broadcast/receive a byte[] to the cluster. This can be easily implemented using the WildFly clustering API. Such an implementation will simplify the transition to JGroups 4.0 and future-proof WildFly from any new API breakage. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8416) Create BroadcastEndpoint implementation using WF clustering API

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-8416: ---------------------------------- Summary: Create BroadcastEndpoint implementation using WF clustering API Key: WFLY-8416 URL: https://issues.jboss.org/browse/WFLY-8416 Project: WildFly Issue Type: Task Components: Clustering, JMS Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 12.0.0.Alpha1 The upgrade to JGroups 4.0 will break the JGroups usage in ActiveMQ Artemis (which uses JGroups 3.x). JGroups is only used to broadcast/receive a byte[] to the cluster. This can be easily implemented using the WildFly clustering API. Such an implementation will simplify the transition to JGroups 4.0 and future-proof WildFly from any new API breakage. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2017