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

[Brian Stansberry]

On Thu, Apr 4, 2019 at 4:58 AM Carlo de Wolf <cdewolf at redhat.com> wrote:

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

I'm not aiming in this thread at removing things we use.  My only aim was
to remove cruft.  I missed the use of org.apache.commons.lang3. (Thansk,
Jim!) It's used so I won't be removing it.

Same for commons.cli.

So this is really just about org.apache.commons.lang


> 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> 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>
>> 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> 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
>>>> 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
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> _______________________________________________
>> wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
> _______________________________________________
> wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://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



-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190404/6670198d/attachment-0001.html