Still not simpler that log4j-api-java9...
On Sat, Jul 8, 2017 at 10:02 PM, Matt Sicker <boa...@gmail.com> wrote:
> That's what I'm getting at with the plugin. I'm sure log4j won't be the
> first or last common jar to have multi-version support. I wonder if this
> situation is any better than the Scala one where each major version has its
> own separate jar.
>
> I think the worst case scenario could be an android classifier with a
> trimmed down set of jars. That would of course mean publishing more
> artefacts, but not too crazy an idea IMO.
>
> On 8 July 2017 at 23:35, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>
> > NOTHING should be looking for class files under the META-INF directory.
> > Both the Maven Bundle plugin and now, it seems, Android have this
> problem.
> >
> > We get around this for OSGi by running the plugin before the Java 9 class
> > (there is only 1 now) is added to the Jar. Can we do the same with
> Android
> > or can the Android build somehow be configured to ignore META-INF?
> >
> > Ralph
> >
> > > On Jul 8, 2017, at 9:10 PM, Gary Gregory <garydgreg...@gmail.com>
> wrote:
> > >
> > > On Sat, Jul 8, 2017 at 7:47 PM, Matt Sicker <boa...@gmail.com> wrote:
> > >
> > >> Seems simpler to fix the Gradle plugin(s) for Android honestly.
> > >>
> > >
> > > How can changing plugins (I'm not using the work "fix" here) any
> easier?
> > It
> > > sure would take a lot longer... and it's something we have no control
> > > over...
> > >
> > > Gary
> > >
> > >>
> > >> On 8 July 2017 at 21:26, Gary Gregory <garydgreg...@gmail.com> wrote:
> > >>
> > >>> I say we keep it simple: Deliver log4j-api-java9 as an add-on to
> > >> log4j-api
> > >>> instead of being clever with log4j-api embedding Java 9 classes a la
> > >>> Titanic.
> > >>>
> > >>> Thoughts?
> > >>>
> > >>> Gary
> > >>>
> > >>> On Sat, Jul 8, 2017 at 7:10 PM, Gary Gregory <garydgreg...@gmail.com
> >
> > >>> wrote:
> > >>>
> > >>>> I do not think that is how Android development works. The .class
> files
> > >>> are
> > >>>> converted to .dex files from what I can tell, a different byte code
> > >>> format
> > >>>> used by both Dalvik (discontinued) and ART.
> > >>>>
> > >>>> Gary
> > >>>>
> > >>>> On Sat, Jul 8, 2017 at 6:15 PM, Apache <ralph.go...@dslextreme.com>
> > >>> wrote:
> > >>>>
> > >>>>> Is it trying to process the class files generated by java? I
> thought
> > >>>>> Android compiled Java source. If it is looking at class files then
> > it
> > >>>>> needs to ignore everything under META-INF
> > >>>>>
> > >>>>> Sent from my iPad
> > >>>>>
> > >>>>>> On Jul 8, 2017, at 5:58 PM, Gary Gregory <garydgreg...@gmail.com>
> > >>>>> wrote:
> > >>>>>>
> > >>>>>> We are worst off with our 2.9-SNAPSHOT, I can't even build an app
> > >>> using
> > >>>>>> only log4j-api:
> > >>>>>>
> > >>>>>> AGPBI: {"kind":"error","text":"Error converting bytecode to
> > >>> dex:\nCause:
> > >>>>>> Dex cannot parse version 53 byte code.\nThis is caused by library
> > >>>>>> dependencies that have been compiled using Java 8 or above.\nIf
> you
> > >>> are
> > >>>>>> using the \u0027java\u0027 gradle plugin in a library submodule
> add
> > >>>>>> \ntargetCompatibility \u003d \u00271.7\u0027\nsourceCompatibility
> > >>>>> \u003d
> > >>>>>> \u00271.7\u0027\nto that submodule\u0027s build.gradle
> > >>>>>> file.","sources":[{}],"original":"UNEXPECTED TOP-LEVEL
> > >>>>>> EXCEPTION:\njava.lang.RuntimeException: Exception parsing
> > >>> classes\n\tat
> > >>>>>> com.android.dx.command.dexer.Main.processClass(Main.java:
> 781)\n\tat
> > >>>>>> com.android.dx.command.dexer.Main.processFileBytes(Main.
> > >>> java:747)\n\tat
> > >>>>>> com.android.dx.command.dexer.Main.access$1200(Main.java:88)\n\tat
> > >>>>>> com.android.dx.command.dexer.Main$FileBytesConsumer.processF
> > >>>>> ileBytes(Main.java:1689)\n\tat
> > >>>>>> com.android.dx.cf.direct.ClassPathOpener.processArchive(Clas
> > >>>>> sPathOpener.java:284)\n\tat
> > >>>>>> com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPat
> > >>>>> hOpener.java:166)\n\tat
> > >>>>>> com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOp
> > >>>>> ener.java:144)\n\tat
> > >>>>>> com.android.dx.command.dexer.Main.processOne(Main.java:695)\n\tat
> > >>>>>> com.android.dx.command.dexer.Main.processAllFiles(Main.
> > >>> java:592)\n\tat
> > >>>>>> com.android.dx.command.dexer.Main.runMultiDex(Main.java:
> 376)\n\tat
> > >>>>>> com.android.dx.command.dexer.Main.run(Main.java:290)\n\tat
> > >>>>>> com.android.builder.internal.compiler.DexWrapper.run(DexWrap
> > >>>>> per.java:54)\n\tat
> > >>>>>> com.android.builder.core.DexByteCodeConverter.lambda$dexInPr
> > >>>>> ocess$0(DexByteCodeConverter.java:174)\n\tat
> > >>>>>> java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat
> > >>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
> > >>>>> Executor.java:1142)\n\tat
> > >>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
> > >>>>> lExecutor.java:617)\n\tat
> > >>>>>> java.lang.Thread.run(Thread.java:745)\nCaused by:
> > >>>>>> com.android.dx.cf.iface.ParseException: bad class file magic
> > >>>>> (cafebabe) or
> > >>>>>> version (0035.0000)\n\tat
> > >>>>>> com.android.dx.cf.direct.DirectClassFile.parse0(DirectClassF
> > >>>>> ile.java:476)\n\tat
> > >>>>>> com.android.dx.cf.direct.DirectClassFile.parse(DirectClassFi
> > >>>>> le.java:406)\n\tat
> > >>>>>> com.android.dx.cf.direct.DirectClassFile.parseToInterfacesIf
> > >>>>> Necessary(DirectClassFile.java:388)\n\tat
> > >>>>>> com.android.dx.cf.direct.DirectClassFile.getMagic(DirectClas
> > >>>>> sFile.java:251)\n\tat
> > >>>>>> com.android.dx.command.dexer.Main.parseClass(Main.java:793)\n\tat
> > >>>>>> com.android.dx.command.dexer.Main.access$1600(Main.java:88)\n\tat
> > >>>>>> com.android.dx.command.dexer.Main$ClassParserTask.call(Main.
> > >>>>> java:1728)\n\tat
> > >>>>>> com.android.dx.command.dexer.Main.processClass(Main.java:
> > >> 779)\n\t...
> > >>> 16
> > >>>>>> more\n","tool":"Dex"}
> > >>>>>> AGPBI: {"kind":"error","text":"1 error; aborting","sources":[{}]}
> > >>>>>>
> > >>>>>> Can we split off this Java 9 stuff in a separate module?
> > >>>>>>
> > >>>>>> Gary
> > >>>>>>
> > >>>>>>> On Sat, Jul 8, 2017 at 4:01 PM, Matt Sicker <boa...@gmail.com>
> > >>> wrote:
> > >>>>>>>
> > >>>>>>> If you've got some instructions on how to even get an Android
> > >> project
> > >>>>> up
> > >>>>>>> and running, getting some test code to play with would certainly
> > >>> help.
> > >>>>> Long
> > >>>>>>> ago when I tried debugging some Android issues with Log4j, I
> > >> couldn't
> > >>>>> even
> > >>>>>>> get that far. :/
> > >>>>>>>
> > >>>>>>>> On 8 July 2017 at 17:31, Gary Gregory <garydgreg...@gmail.com>
> > >>> wrote:
> > >>>>>>>>
> > >>>>>>>> A quick follow up to note that with 2.8.2, using log4j-api does
> > >> not
> > >>>>> cause
> > >>>>>>>> problems but then adding log4j-core causes the app to fail to
> > >> start.
> > >>>>> So I
> > >>>>>>>> definitively see an Android epic for 2.10. Maybe this is when we
> > >>> want
> > >>>>> to
> > >>>>>>>> split up log4j-core.
> > >>>>>>>>
> > >>>>>>>> Gary
> > >>>>>>>>
> > >>>>>>>> On Sat, Jul 8, 2017 at 3:20 PM, Gary Gregory <
> > >>> garydgreg...@gmail.com>
> > >>>>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> So here I am with my family our of town on a weekend, and I
> > >> thought
> > >>>>> I'd
> > >>>>>>>>> give Log4j on Android a try.
> > >>>>>>>>>
> > >>>>>>>>> The first thing I run into is:
> > >>>>>>>>>
> > >>>>>>>>> FAILURE: Build failed with an exception.
> > >>>>>>>>>
> > >>>>>>>>> * What went wrong:
> > >>>>>>>>> Execution failed for task ':Application:transformResourc
> > >>>>> esWithMergeJav
> > >>>>>>>>> aResForDebug'.
> > >>>>>>>>>> com.android.build.api.transform.TransformException:
> > >>>>>>>>> com.android.builder.packaging.DuplicateFileException:
> Duplicate
> > >>>>> files
> > >>>>>>>>> copied in APK META-INF/LICENSE
> > >>>>>>>>> File1: C:\Users\ggregory\.gradle\caches\modules-2\files-2.1\
> > >>>>>>>>> org.apache.logging.log4j\log4j-core\2.8.2\
> > >>>>>>> 979fc0cf8460302e4ffbfe38c1b66a
> > >>>>>>>>> 99450b0bb7\log4j-core-2.8.2.jar
> > >>>>>>>>> File2: C:\Users\ggregory\.gradle\caches\modules-2\files-2.1\
> > >>>>>>>>> org.apache.logging.log4j\log4j-api\2.8.2\
> > >>>>>>> e590eeb783348ce8ddef205b82127f
> > >>>>>>>>> 9084d82bf3\log4j-api-2.8.2.jar
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> * Try:
> > >>>>>>>>> Run with --stacktrace option to get the stack trace. Run with
> > >>> --info
> > >>>>> or
> > >>>>>>>>> --debug option to get more log output.
> > >>>>>>>>>
> > >>>>>>>>> BUILD FAILED
> > >>>>>>>>>
> > >>>>>>>>> Total time: 1.995 secs
> > >>>>>>>>>
> > >>>>>>>>> which is solved by:
> > >>>>>>>>>
> > >>>>>>>>> https://stackoverflow.com/questions/37586800/android-
> > >>>>>>>>> gradle-duplicate-files-copied-in-apk-meta-inf-license-txt
> > >>>>>>>>>
> > >>>>>>>>> Which means I have to add this to my build:
> > >>>>>>>>>
> > >>>>>>>>> packagingOptions {
> > >>>>>>>>> exclude 'META-INF/DEPENDENCIES'
> > >>>>>>>>> exclude 'META-INF/LICENSE'
> > >>>>>>>>> }
> > >>>>>>>>>
> > >>>>>>>>> I wonder if we should generate these files pretending we are in
> > >> an
> > >>>>> uber
> > >>>>>>>> jar, either:
> > >>>>>>>>>
> > >>>>>>>>> - with the project name in the name like
> META-INF/log4j2.LICENSE
> > >>>>>>>>>
> > >>>>>>>>> - with maven AID in the name like META-INF/log4j-api.LICENSE
> > >>>>>>>>>
> > >>>>>>>>> - with maven coords in the name like
> META-INF/org.apache.logging.
> > >>>>>>>> log4j-log4j-api.LICENSE
> > >>>>>>>>>
> > >>>>>>>>> As an aside files like LICENSE and NOTICE do not have .txt
> > >>> extensions
> > >>>>>>>> which is lame IMO.
> > >>>>>>>>>
> > >>>>>>>>> Ignore and do nothing? Thoughts?
> > >>>>>>>>>
> > >>>>>>>>> Gary
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> Matt Sicker <boa...@gmail.com>
> > >>>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Matt Sicker <boa...@gmail.com>
> > >>
> >
> >
> >
>
>
> --
> Matt Sicker <boa...@gmail.com>
>
