As I said before, that can be handled by a dependency swap. Ralph
> On Jul 10, 2017, at 5:33 AM, Remko Popma <[email protected]> wrote: > > One problem with the log4j-api-android idea is that it doesn't cover other > libraries that bring in a dependency to log4j-api. > > However, I wouldn't mind saying Log4j 2.9 supports Java 9 but not Android; > on Android use Log4j 2.8. > > > (Shameless plug) Every java main() method deserves http://picocli.info > FORK ME!! > > >>> On Jul 10, 2017, at 14:28, Matt Sicker <[email protected]> wrote: >>> >>> On 9 July 2017 at 18:32, Ralph Goers <[email protected]> wrote: >>> >>> >>> >>>> On Jul 9, 2017, at 1:29 PM, Matt Sicker <[email protected]> wrote: >>>> >>>> Suppose we have an Android-specific api jar. Then when an Android >>> developer >>>> gets log4j-api transitively, what now? I don't see normal libraries > using >>>> log4j-api-android or something instead of the standard one. >>> >>> This would be an android specific build, so they can exclude log4j-api > and >>> include log4j-api-android instead. That isn’t much different than what >>> people have to do to use SLF4J’s commons-logging bridge. >>> >>> Ralph >>> >> >> That makes sense to me. Would it be appropriate to give this a classifier >> or just name it log4j-api-android? I'd imagine a classifier version might >> work if that is generated straight from log4j-api without the jdk9 classes >> added. >> >> -- >> Matt Sicker <[email protected]>
