[wildfly-dev] Removal of commons-cli, commons-lang and commons-lang3 modules

[Carlo de Wolf]

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 at redhat.com 
> <mailto:fnasser at 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 at redhat.com <mailto:jperkins at 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 at redhat.com
>>         <mailto:brian.stansberry at 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 at lists.jboss.org
>>             <mailto:wildfly-dev at lists.jboss.org>
>>             https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>>         -- 
>>         James R. Perkins
>>         JBoss by Red Hat
>>         _______________________________________________
>>         wildfly-dev mailing list
>>         wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>     _______________________________________________
>>     wildfly-dev mailing list
>>     wildfly-dev at lists.jboss.org  <mailto:wildfly-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190404/04329a08/attachment-0001.html