You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2017/07/08 22:20:42 UTC

Playing with Android...

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:transformResourcesWithMergeJavaResForDebug'.
> 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\979fc0cf8460302e4ffbfe38c1b66a99450b0bb7\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\e590eeb783348ce8ddef205b82127f9084d82bf3\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

Re: Playing with Android...

Posted by Apache <ra...@dslextreme.com>.
The Log4J-API compile does not have any dependency on java 9

Sent from my iPad

> On Jul 8, 2017, at 5:58 PM, Gary Gregory <ga...@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.processFileBytes(Main.java:1689)\n\tat
> com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:284)\n\tat
> com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:166)\n\tat
> com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.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(DexWrapper.java:54)\n\tat
> com.android.builder.core.DexByteCodeConverter.lambda$dexInProcess$0(DexByteCodeConverter.java:174)\n\tat
> java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tat
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.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(DirectClassFile.java:476)\n\tat
> com.android.dx.cf.direct.DirectClassFile.parse(DirectClassFile.java:406)\n\tat
> com.android.dx.cf.direct.DirectClassFile.parseToInterfacesIfNecessary(DirectClassFile.java:388)\n\tat
> com.android.dx.cf.direct.DirectClassFile.getMagic(DirectClassFile.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 <bo...@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 <ga...@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 <ga...@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:transformResourcesWithMergeJav
>>>> 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 <bo...@gmail.com>
>> 



Re: Playing with Android...

Posted by Gary Gregory <ga...@gmail.com>.
Java 9 is turning into the Titanic in Java's history, and Android is just
one iceberg on its route...

Gary

On Sat, Jul 8, 2017 at 7:10 PM, Gary Gregory <ga...@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 <ra...@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 <ga...@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 <bo...@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 <ga...@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 <ga...@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 <bo...@gmail.com>
>> >>
>>
>>
>>
>

Re: Playing with Android...

Posted by Ralph Goers <ra...@dslextreme.com>.
I’m not in favor of delivering Java 9 support as a separate jar. What we have now is exactly the way Oracle expects libraries to implement it.

Ralph

> On Jul 8, 2017, at 7:26 PM, Gary Gregory <ga...@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 <ga...@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 <ra...@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 <ga...@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 <bo...@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 <ga...@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 <ga...@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 <bo...@gmail.com>
>>>>> 
>>> 
>>> 
>>> 
>> 



Re: Playing with Android...

Posted by Gary Gregory <ga...@gmail.com>.
This does not work:

packagingOptions {
    exclude 'META-INF/DEPENDENCIES'
    exclude 'META-INF/LICENSE'
    exclude 'META-INF/versions/9/**'

Gary


On Sat, Jul 8, 2017 at 9:35 PM, Ralph Goers <ra...@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 <ga...@gmail.com> wrote:
> >
> > On Sat, Jul 8, 2017 at 7:47 PM, Matt Sicker <bo...@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 <ga...@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 <ga...@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 <ra...@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 <ga...@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 <bo...@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 <ga...@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 <
> >>> garydgregory@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 <bo...@gmail.com>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> Matt Sicker <bo...@gmail.com>
> >>
>
>
>

Re: Playing with Android...

Posted by Gary Gregory <ga...@gmail.com>.
Still not simpler that log4j-api-java9...

On Sat, Jul 8, 2017 at 10:02 PM, Matt Sicker <bo...@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 <ra...@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 <ga...@gmail.com>
> wrote:
> > >
> > > On Sat, Jul 8, 2017 at 7:47 PM, Matt Sicker <bo...@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 <ga...@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 <garydgregory@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 <ra...@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 <ga...@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 <bo...@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 <ga...@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 <
> > >>> garydgregory@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 <bo...@gmail.com>
> > >>>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Matt Sicker <bo...@gmail.com>
> > >>
> >
> >
> >
>
>
> --
> Matt Sicker <bo...@gmail.com>
>

Re: Playing with Android...

Posted by Matt Sicker <bo...@gmail.com>.
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 <ra...@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 <ga...@gmail.com> wrote:
> >
> > On Sat, Jul 8, 2017 at 7:47 PM, Matt Sicker <bo...@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 <ga...@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 <ga...@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 <ra...@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 <ga...@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 <bo...@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 <ga...@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 <
> >>> garydgregory@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 <bo...@gmail.com>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> Matt Sicker <bo...@gmail.com>
> >>
>
>
>


-- 
Matt Sicker <bo...@gmail.com>

Re: Playing with Android...

Posted by Mikael Ståldal <mi...@apache.org>.
An Android project consumes the final jar:s (with .class files) which we 
publish, just like any regular Java project using Log4j.


On 2017-07-09 06:35, Ralph Goers 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 <ga...@gmail.com> wrote:
>>
>> On Sat, Jul 8, 2017 at 7:47 PM, Matt Sicker <bo...@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 <ga...@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 <ga...@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 <ra...@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 <ga...@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 <bo...@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 <ga...@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 <
>>>> garydgregory@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 <bo...@gmail.com>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
> 
> 


Re: Playing with Android...

Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ga...@gmail.com> wrote:
> 
> On Sat, Jul 8, 2017 at 7:47 PM, Matt Sicker <bo...@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 <ga...@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 <ga...@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 <ra...@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 <ga...@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 <bo...@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 <ga...@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 <
>>> garydgregory@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 <bo...@gmail.com>
>>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>> --
>> Matt Sicker <bo...@gmail.com>
>> 



Re: Playing with Android...

Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Jul 8, 2017 at 7:47 PM, Matt Sicker <bo...@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 <ga...@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 <ga...@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 <ra...@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 <ga...@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 <bo...@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 <ga...@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 <
> > garydgregory@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 <bo...@gmail.com>
> > >> >>
> > >>
> > >>
> > >>
> > >
> >
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>

Re: Playing with Android...

Posted by Matt Sicker <bo...@gmail.com>.
Seems simpler to fix the Gradle plugin(s) for Android honestly.

On 8 July 2017 at 21:26, Gary Gregory <ga...@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 <ga...@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 <ra...@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 <ga...@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 <bo...@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 <ga...@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 <
> garydgregory@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 <bo...@gmail.com>
> >> >>
> >>
> >>
> >>
> >
>



-- 
Matt Sicker <bo...@gmail.com>

Re: Playing with Android...

Posted by Gary Gregory <ga...@gmail.com>.
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 <ga...@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 <ra...@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 <ga...@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 <bo...@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 <ga...@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 <ga...@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 <bo...@gmail.com>
>> >>
>>
>>
>>
>

Re: Playing with Android...

Posted by Gary Gregory <ga...@gmail.com>.
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 <ra...@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 <ga...@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.
> processFileBytes(Main.java:1689)\n\tat
> > com.android.dx.cf.direct.ClassPathOpener.processArchive(
> ClassPathOpener.java:284)\n\tat
> > com.android.dx.cf.direct.ClassPathOpener.processOne(
> ClassPathOpener.java:166)\n\tat
> > com.android.dx.cf.direct.ClassPathOpener.process(
> ClassPathOpener.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(
> DexWrapper.java:54)\n\tat
> > com.android.builder.core.DexByteCodeConverter.lambda$dexInProcess$0(
> DexByteCodeConverter.java:174)\n\tat
> > java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat
> > java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)\n\tat
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.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(
> DirectClassFile.java:476)\n\tat
> > com.android.dx.cf.direct.DirectClassFile.parse(
> DirectClassFile.java:406)\n\tat
> > com.android.dx.cf.direct.DirectClassFile.parseToInterfacesIfNecessary(
> DirectClassFile.java:388)\n\tat
> > com.android.dx.cf.direct.DirectClassFile.getMagic(
> DirectClassFile.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 <bo...@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 <ga...@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 <ga...@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:
> transformResourcesWithMergeJav
> >>>> 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 <bo...@gmail.com>
> >>
>
>
>

Re: Playing with Android...

Posted by Apache <ra...@dslextreme.com>.
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 <ga...@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.processFileBytes(Main.java:1689)\n\tat
> com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:284)\n\tat
> com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:166)\n\tat
> com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.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(DexWrapper.java:54)\n\tat
> com.android.builder.core.DexByteCodeConverter.lambda$dexInProcess$0(DexByteCodeConverter.java:174)\n\tat
> java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tat
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.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(DirectClassFile.java:476)\n\tat
> com.android.dx.cf.direct.DirectClassFile.parse(DirectClassFile.java:406)\n\tat
> com.android.dx.cf.direct.DirectClassFile.parseToInterfacesIfNecessary(DirectClassFile.java:388)\n\tat
> com.android.dx.cf.direct.DirectClassFile.getMagic(DirectClassFile.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 <bo...@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 <ga...@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 <ga...@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:transformResourcesWithMergeJav
>>>> 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 <bo...@gmail.com>
>> 



Re: Playing with Android...

Posted by Apache <ra...@dslextreme.com>.
It already is.

Sent from my iPad

> On Jul 8, 2017, at 5:58 PM, Gary Gregory <ga...@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.processFileBytes(Main.java:1689)\n\tat
> com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:284)\n\tat
> com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:166)\n\tat
> com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.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(DexWrapper.java:54)\n\tat
> com.android.builder.core.DexByteCodeConverter.lambda$dexInProcess$0(DexByteCodeConverter.java:174)\n\tat
> java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tat
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.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(DirectClassFile.java:476)\n\tat
> com.android.dx.cf.direct.DirectClassFile.parse(DirectClassFile.java:406)\n\tat
> com.android.dx.cf.direct.DirectClassFile.parseToInterfacesIfNecessary(DirectClassFile.java:388)\n\tat
> com.android.dx.cf.direct.DirectClassFile.getMagic(DirectClassFile.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 <bo...@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 <ga...@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 <ga...@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:transformResourcesWithMergeJav
>>>> 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 <bo...@gmail.com>
>> 



Re: Playing with Android...

Posted by Gary Gregory <ga...@gmail.com>.
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.processFileBytes(Main.java:1689)\n\tat
com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:284)\n\tat
com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:166)\n\tat
com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.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(DexWrapper.java:54)\n\tat
com.android.builder.core.DexByteCodeConverter.lambda$dexInProcess$0(DexByteCodeConverter.java:174)\n\tat
java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tat
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.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(DirectClassFile.java:476)\n\tat
com.android.dx.cf.direct.DirectClassFile.parse(DirectClassFile.java:406)\n\tat
com.android.dx.cf.direct.DirectClassFile.parseToInterfacesIfNecessary(DirectClassFile.java:388)\n\tat
com.android.dx.cf.direct.DirectClassFile.getMagic(DirectClassFile.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 <bo...@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 <ga...@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 <ga...@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:transformResourcesWithMergeJav
> > > 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 <bo...@gmail.com>
>

Re: Playing with Android...

Posted by Matt Sicker <bo...@gmail.com>.
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 <ga...@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 <ga...@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:transformResourcesWithMergeJav
> > 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 <bo...@gmail.com>

Re: Playing with Android...

Posted by Gary Gregory <ga...@gmail.com>.
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 <ga...@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:transformResourcesWithMergeJav
> 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
>
>