[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
[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
[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
[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
[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
[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
[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
[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