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(a)redhat.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- James R. Perkins JBoss by Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > James R. Perkins > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing listwildfly-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev

Certainly a topic for the future. On Wed, Apr 3, 2019 at 3:36 PM Fernando Nasser <fnasser(a)redhat.com <mailto: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(a)redhat.com <mailto: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(a)redhat.com > <mailto: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(a)lists.jboss.org > <mailto: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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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(a)redhat.com&gt; 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(a)redhat.com&gt; > 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(a)redhat.com&gt; 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> -- >> James R. Perkins >> JBoss by Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing listwildfly-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ wildfly-dev mailing listwildfly-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On Thu, Apr 4, 2019 at 10:26 AM Brian Stansberry <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote: Same for commons.cli. So this is really just about org.apache.commons.lang

It looks like org.apache.commons.lang is used in org.apache.openjpa too [1]. It's also commented out in com.microsoft.azure.storage [2]. [1]: https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/reso... [2]: https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/reso... -- James R. Perkins JBoss by Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Looks like I should be able to remove org.apache.commons.lang from the OpenJPA module. Will create a pr later.

>

+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 <jperkins(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > James R. Perkins > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev