While you could write the ServiceLoader class by hand, I wouldn’t want anyone to. That would be error prone.
I have though about creating a Maven plugin to generate the class, but all that would do is replace the proc=only compile step, so there isn’t much point. Ralph > On May 29, 2021, at 5:40 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > We do need better docs on this. 3.0 is going to be a mixed bag. It will be > easier > for “normal” applications because plugins now use ServiceLoader instead of > the Log4jPlugins.dat file. However, it is going to be more challenging for > those > developing plugins if they use the Java Platform Module System. > > As one might imagine, the compiler now has a modulePath in addition to a > classPath. When no module-info.java is present Maven will set things up to > only use the classPath, which will work as normal. However, when a > module-info.java > file is present than Maven will configure the project and its tests to use > the > modulePath. By itself this isn’t a problem. However, the Java compiler ONLY > looks for Annotation processors automatically on the classPath. This means > anyone using JPMS while compiling plugins will have to explicitly configure > the annotation processor. > > There is a second issue when using JPMS. While our annotation processor > generates the service class and service definition file, JPMS requires that > the > Log4jPlugins service class must be declared in module-info.java. This is > somewhat of a problem because the compiler will fail if it finds the > module-info.java references the Log4jPlugins service class because the > annotation processor hasn’t generated it yet. > > The only recourse to this is to do a proc=only compile that does not include > the module-info.java class followed by a full compile with proc=none. > Personally, > I think this is a but in javac but I suspect it would be a major change to > fix it. > > I have meant to write a blog post on all of this basically to ask the > question, > “Is JPMS really worth it”? > > Ralph > >> On May 29, 2021, at 11:06 AM, Matt Sicker <boa...@gmail.com> wrote: >> >> Hey all, that itch is back to figure out how to complete my previous >> attempt at the plugin system updates (started a little over a year ago >> and put on pause at some point). I'm currently working on getting that >> branch back up to working again with master (mostly needing to update >> module-info files), and I'm hoping to map out and figure out the path >> forward on completing it. >> >> With that being said, one major aspect of this project will be >> explaining how the 2.x plugin system works, how it relates to the 3.x >> system, and the gist of how I'd like to restructure things. Does >> anyone here have any preferences on how I share some docs about this? >> I could record some videos that go over code and such, or I could >> write things up blog style. Note that these docs would be focused at >> fellow log4j developers and not necessarily the user manual. I still >> plan to have proper API docs and manual pages for the system, but >> those would be targeted for users writing their own extensions mainly. >> >> Link for background info: >> https://issues.apache.org/jira/browse/LOG4J2-2803 >> > > >
