Alright, I took another whack at this over the weekend and figured out what you need to do to get IntelliJ working properly with this project.
1. Set up your ~/.m2/toolchains.xml as usual. 2. In the IntelliJ settings, go to "Build, Execution, Deployment" > "Build Tools" > "Maven" > "Runner", and tick the checkbox for "Delegate IDE build/run actions to Maven". Using this setup, IntelliJ will defer to Maven instead of using its own almost-but-not-quite-entirely-unlike-Maven compiler. Thanks to this, I was finally able to get around to cleaning up some old plugin system APIs that were bugging me for years. On Sun, 9 Jun 2019 at 12:28, Ralph Goers <[email protected]> wrote: > > When using the —release option my understanding is that the compiler only > exposes JDK classes for the target release, so you can’t accidentally > reference newer Java API classes and methods. However, when running the tests > you would still be using the newer JDK instead of the target JDK. The only > way I know how to limit that is via toolchains. > > Ralph > > > On Jun 9, 2019, at 10:11 AM, Matt Sicker <[email protected]> wrote: > > > > The IntelliJ ticket is certainly a good idea. I was thinking it might be a > > simpler setup to compile with anything 9+ and a verifier on API usage, > > though who knows if that will introduce other issues. > > > > On Sun, Jun 9, 2019 at 12:05, Ralph Goers <[email protected]> > > wrote: > > > >> That would mean abandoning Java’s multi-version support. I’m not in favor > >> of that as I believe once we are building with Java 9+ things should be > >> able to get simpler. I will trust builds once you can use -release as a > >> build option. > >> > >> I would suggest opening a ticket with Intellij to get them to recognize > >> and support the toolchains plugin. > >> > >> Ralph > >> > >>> On Jun 9, 2019, at 9:54 AM, Matt Sicker <[email protected]> wrote: > >>> > >>> One potential fix could be to extract the version specific code into its > >>> own support library that we only need to release once in a while. That > >>> would at least minimize the workarounds required in the main repo. That’s > >>> what we’ve done in Jenkins so far at least (which also has several native > >>> code bindings packaged similarly). > >>> > >>> On Sun, Jun 9, 2019 at 11:21, Matt Sicker <[email protected]> wrote: > >>> > >>>> Kind of funny that I have an old todo task about investigating the > >>>> possibility of a mono repo for Log4j to make things easier. We might be > >>>> reaching the limits of Maven and/or IDEs here. I’d suggest going back to > >>>> revisit the multiple repos idea, but that doesn’t handle the multiple > >> JDK > >>>> problem. I’m thinking of investigating what Spring Framework is doing to > >>>> support this nowadays. > >>>> > >>>> On Sat, Jun 8, 2019 at 17:45, Volkan Yazıcı <[email protected]> > >>>> wrote: > >>>> > >>>>> For the records, the very same frustration was my initial driver to > >> start > >>>>> working on log4j2-logstash-layout as a separate project. (That said, > >> this > >>>>> path led other advantages for the plugin.) I think this awkwardly high > >>>>> entry barrier repels many potential contributors. Sometimes you just > >> want > >>>>> to fix a one liner, but end up throwing the towel once you figure out > >> the > >>>>> project does not even build properly in your IDE. Just my 2 cents... > >>>>> > >>>>> On Sat, Jun 8, 2019 at 10:33 PM Matt Sicker <[email protected]> wrote: > >>>>> > >>>>>> The maven config has gotten so complicated now that IntelliJ no longer > >>>>>> knows how to compile anything or run tests. I've tried using Java 8 as > >>>>>> a default JDK, but that leads to errors because IntelliJ doesn't > >>>>>> recognize the java9 modules as using a different JDK. I tried manually > >>>>>> changing those modules, but then I get some javac error with no error > >>>>>> message. > >>>>>> > >>>>>> Next, I tried using Java 12 as the default JDK, but then came across > >>>>>> an issue in a test that I fixed in master. Now I'm stuck trying to get > >>>>>> the log4j-jmx-gui module to compile in Java 12 because jconsole.jar is > >>>>>> now jdk.jconsole.jmod, and I can't find any docs on using maven to > >>>>>> generate any JPMS stuff. > >>>>>> > >>>>>> To be clear, this all builds perfectly fine from the command line > >>>>>> using maven directly. > >>>>>> > >>>>>> -- > >>>>>> Matt Sicker <[email protected]> > >>>>>> > >>>>> > >>>> -- > >>>> Matt Sicker <[email protected]> > >>>> > >>> -- > >>> Matt Sicker <[email protected]> > >> > >> > >> -- > > Matt Sicker <[email protected]> > > -- Matt Sicker <[email protected]>
