Removal of commons-cli, commons-lang and commons-lang3 modules

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Removal of commons-cli, commons-lang and commons-lang3 modules

Brian Stansberry
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removal of commons-cli, commons-lang and commons-lang3 modules

James Perkins
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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


--
James R. Perkins
JBoss by Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removal of commons-cli, commons-lang and commons-lang3 modules

Darran Lofthouse
+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.

On Tue, Apr 2, 2019 at 10:13 PM James Perkins <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removal of commons-cli, commons-lang and commons-lang3 modules

Jim Ma
In reply to this post by Brian Stansberry
We can look at remove it after delete it from CXF future release first.

Cheers,
Jim

On 4/3/19 3:24 AM, Brian Stansberry 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removal of commons-cli, commons-lang and commons-lang3 modules

Carlo de Wolf
In reply to this post by Darran Lofthouse
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev