[wildfly-dev] Re: Deprecated Modules Cleanup + Standardized Deployments

Thank you, Scott Marlow, for pointing me at this thread! Thanks, Richard for writing this up; sorry I didn't see it last week. Responses in-line. On Wed, Mar 29, 2023 at 8:59 AM Yeray Borges Santana <yborgess(a)redhat.com&gt; wrote: I'm not sure about this. Please see below. I'm thinking we might do a WF 29 Alpha at the end of April. If we do something less aggressive in WF 28 with the intent to finish in WF 29, that finishing work should be in that Alpha. There's various code organization and deprecated item cleanup work that we're planning and I'd like to get all of that done for that Alpha so we can focus for the rest of the WF 29 dev cycle on other things. I expect April will be devoted to this kind of work, plus bug fixing. So the paths listed in https://github.com/wildfly/wildfly-core/blob/main/core-feature-pack/commo... are no longer available in recent IBM JDK 11 releases? If not, then I agree with Yeray that we might as well remove the module in 28 Final or 29 Alpha1. Otherwise, if any of the listed paths are no longer relevant we should clean up the module.xml. For any that do still exist, the question becomes what functionality will be lost by removing access to these packages? For any packages that still exist we should work with the Windup project ( https://github.com/windup/windup) to see if they want to add migration rules. If the use cases are more ones where a class is not a compile time dependency but ends up needing to be loaded at runtime, then the need to add a dependency on ibm.jdk becomes something to document, perhaps as part of https://issues.redhat.com/browse/WFLY-14330. Ok. I think this is right in general, although there is an open question about the wildflyee.api module, which is also being discussed in zulip at https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/to.... My instinct here is that we need to add java.se back into that, as otherwise we are breaking uses of that module. Some of those uses we could patch up by modifying ExternalModuleSpecService to add a java.se dependency, but that would leave cases where user provided static modules that depend on wildflyee.api might be broken. I don't think wildflyee.api should depend on / export jdk.xml.dom though. That's a breakage that I think we should just accept. Tangent: We should add a comment block to the wildflyee.api module.xml explaining its purpose/use. Every 2 years that module pops up in some context and it takes several hours of discussion to remember how/why it's used. :) So AIUI from #2 above, the effect of exporting java.se by default instead of javax.api is that deployments no longer see jdk.xml.dom packages by default. I think that is fine. * deprecated ibm.jdk will not be propagated anymore to all deployments by I agree we should do this, but we need to handle what I mentioned above under point #1. * deprecated sun.jdk will not be propagated anymore to all deployments by We need to do much the same kind of thinking as is noted above re ibm.jdk. Except it's both harder (because of far more paths) and more urgent (because IBM JDK is less used.) That said, it makes sense to not expose JDK internals to deployments. We just need to better understand what use cases may be affected. I agree. VFS should not be an application API. I'm hoping/praying that the only reason we exposed it to deployments in the first place was for our own internally classloading needs, not because user apps wanted access. Note that depending on org.jboss.vfs will result in a log WARN, because the module is jboss.api=private. Which it should be. -- Brian Stansberry Principal Architect, Red Hat JBoss EAP He/Him/His