Hello, I don’t have intentions to add a module-info file to logging. I think we should just go with the Automatic-Module-Header solution.
I started this thread to find out why the Logging repo contains Java 1.3 files although the build targets Java 1.2. With the latest commons-parent, I get build failures because of the animal-sniffer plugin. I want to fix this, since I volunteered to be RM for the next release. Can we please go back to topic and discuss the potential addition of a module-info file on a different thread? I don’t see this for the next release… Regards, Benedikt > Am 31.10.2017 um 12:37 schrieb sebb <seb...@gmail.com>: > > On 30 October 2017 at 23:09, Stephen Colebourne <scolebou...@joda.org> wrote: >> Does commons-logging need to be a full module with a module-info.java? >> Probably not at this point. Adding Automatic-Module-Name is probably >> sufficient. However, if someone wants to do the work, then adding >> module-info shouldn't be blocked IMO. >> >> I don't believe that module-info.java requires Java 6 or later. It >> would be possible to create the module-info.class file using java 9 >> and then use a much earlier compiler version to build the rest of the >> jar. Or the module-info.class binary bytecode file could be checked >> into git (probably simpler!). > > The module-info.java file must also be stored somewhere in Git so the > class file can be recreated. > > An approach would be: > > Add module-info.java to correct location so project compiles using Java 9. > If using an earlier version of Java, skip the compilation and copy the > pre-compiled class-file instead. > [Ideally there should also be a check that the .class file is newer > than the .java file] > > Not sure how easy that would be to do in Maven, but once done, it > could be applied to all Commons components > >> Stephen >> >> >> On 28 October 2017 at 21:31, Ralph Goers <ralph.go...@dslextreme.com> wrote: >>> Gary, >>> >>> As you know Log4j has a maven module for Java 9. It contains the >>> module-info.java file. That module compiles with Java 9 and targets Java 9 >>> as there isn’t much point targeting anything earlier. That class files >>> produced are then overlaid on top of the classes produced for Log4j-api, >>> which is targeted at 1.7 and uses the 1.7 compiler. Commons Logging could >>> do exactly the same thing and just have a maven module for the Java 9 >>> support and then use whatever compiler it wants for the current commons >>> logging classes. >>> >>> That said, why does commons logging need to be a “real” module anyway? >>> >>> Ralph >>> >>>> On Oct 28, 2017, at 10:07 AM, Gary Gregory <garydgreg...@gmail.com> wrote: >>>> >>>> From a pragmatic POV, the oldest Java byte codes you can get Java 9 to emit >>>> are for Java 1.6. Since we will want, I assume, to produce a module info >>>> class in the jar, we will need to use Java 9 for that (to keep an RM's life >>>> manageable.) >>>> >>>> This means to me that we should set the bar at Java 1.6 for the bare >>>> minimum, which seams reasonable in 2017 soon to be 2018 and considering >>>> Java 6 and 7 are EOL. >>>> >>>> Gary >>>> >>>> On Sat, Oct 28, 2017 at 10:32 AM, Benedikt Ritter <brit...@apache.org> >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> maybe we should decide on what we want to achieve here, before I start the >>>>> endeavor of creating an RC for such an old component. >>>>> >>>>> My understanding of Logging is, that it is in semi dormant mode. That we >>>>> don’t want to add any new features and instead point users to Log4j2. >>>>> Since >>>>> Logging has a wide installation base we decided not to upgrade the Java >>>>> version requirement and instead stay at Java 1.2 and only release super >>>>> critical fixes/updates. >>>>> Upgrading to Java 6 seems to contradict this plan. So where do we want to >>>>> go with Logging? >>>>> >>>>> Regards, >>>>> Benedikt >>>>> >>>>>> Am 28.10.2017 um 18:20 schrieb Ralph Goers <ralph.go...@dslextreme.com>: >>>>>> >>>>>> That isn’t strictly true Gary, There are ways to build the module-info >>>>> without upgrading the main code to Java 9. That said, it is a bit of a >>>>> hack >>>>> to do it. >>>>>> >>>>>> Ralph >>>>>> >>>>>>> On Oct 28, 2017, at 8:19 AM, Gary Gregory <garydgreg...@gmail.com> >>>>> wrote: >>>>>>> >>>>>>> Let's update to at least a minimum of Java 6 such that the build can run >>>>>>> with Java 9. Builing with Java 9 will be a requirement to add module >>>>> info. >>>>>>> >>>>>>> Gary >>>>>>> >>>>>>> On Oct 28, 2017 01:21, "Benedikt Ritter" <brit...@apache.org> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> After I was able to update the the build to the latest parent POM, I’m >>>>>>>> running into animal sniffer problems. The build is defined to target >>>>> Java >>>>>>>> 1.2 but there are classes which require later JDKs: >>>>>>>> >>>>>>>> - Jdk13LumberjackLogger >>>>>>>> - Jdk14Logger >>>>>>>> >>>>>>>> This breaks the build because animal sniffer reports that these classes >>>>>>>> don’t work on Java 1.2. I don’t understand how this is supposed to >>>>> work. >>>>>>>> Did we ship those classes and users have to decide whether they want to >>>>>>>> load them or not depending on the JRE they are running on? Do we want >>>>> to >>>>>>>> exclude the two classes from animal sniffer? >>>>>>>> >>>>>>>> Regards, >>>>>>>> Benedikt >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org