Define the end-state.

If commons-lang3 is part of that end-state it makes no sense to remove it from the matrix. Were it not for CXF it could however be removed from the runtime.

Don't drive into a road which could potentially be a dead-end.

Carlo

On 03-04-19 16:51, Darran Lofthouse wrote:
Certainly a topic for the future.

On Wed, Apr 3, 2019 at 3:36 PM Fernando Nasser <fnasser@redhat.com> wrote:
On 2019-04-03 4:43 a.m., Darran Lofthouse wrote:
+1 the tool is a shaded jar so should not need to depend on another module.

We may want to look at shading again but that would be a different topic.


Indeed. 

Who monitors/detects the shaded code does not contain a CVE and fix it if it does?

Are the people who "shaded" it responsible for supporting/maintaining that code?



On Tue, Apr 2, 2019 at 10:13 PM James Perkins <jperkins@redhat.com> wrote:
I believe the org.wildfly.security:wildfly-elytron-tool does use org.apache.commons.lang3. However IIRC it's now shaded in so likely not an issue. That could be why it was originally there.

On Tue, Apr 2, 2019 at 12:34 PM Brian Stansberry <brian.stansberry@redhat.com> wrote:
Currently WildFly includes 3 JBoss Modules modules that are not used in our runtime. I would like to remove these in WildFly 17:

org.apache.commons.cli
org.apache.commons.lang[1]
org.apache.commons.lang3

All three have the "jboss.api" = "private" property set in their module.xml, meaning they are marked for internal use only and we are free to remove them. End user applications should not have referenced these modules, and if they do we log a WARN on boot advising not to do that.

However, other projects that extend WildFly (i.e. write their own subsystems) may be using these modules, so I wanted to notify any such folks that these will likely be going away and you'll need to provide these yourselves.ed.

Best regards,
Brian

[1] This one is referenced in a commented out module.xml section related to My Faces 1.1 support. I've checked with Farah Juma and that is no longer relevant and the comment can be removed.

_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev


--
James R. Perkins
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev