AVVERTENZA, INFORMAZIONI update on integration tests. I am not confident in
maven CONFIGURAZIONE. Did I get that right?

More seriously I am having trouble with the integration tests, no doubt
doing there job, and failing builds:

geoserver *build_release.sh* is failing when asked to
build main@c96baa2df1a27bc573b7304455cb7e11dd48f480 for milestone release

Checking other jenkins jobs shows *geotools-main-online-mysql* job failing
in response to the locale fix.

[ [1;34mINFO [m]   java.lang.IllegalStateException: log4j2.xml use expected
[ [1;34mINFO [m]   java.lang.IllegalStateException: INFO expected
[ [1;34mINFO [m]   java.lang.IllegalStateException: INFO expected
[ [1;34mINFO [m]   java.lang.IllegalStateException:
commons-logging.properties
[ [1;34mINFO [m]   java.lang.IllegalStateException: log4j.properties  use
expected
[ [1;34mINFO [m]           log4j/pom.xml
.................................... [1;31mFAILED [m (23.5 s)
[ [1;34mINFO [m]           logging/pom.xml
.................................. [1;31mFAILED [m (23.5 s)
[ [1;34mINFO [m]           logback/pom.xml
.................................. [1;31mFAILED [m (23.5 s)
[ [1;34mINFO [m]           commons/pom.xml
.................................. [1;31mFAILED [m (23.5 s)
[ [1;34mINFO [m]           reload4j/pom.xml
................................. [1;31mFAILED [m (23.5 s)

Checking jenkins workspace, metadata/target/it/commons/build.log shows
endless build failures:

WARNING] Error injecting: org.apache.maven.plugin.resources.ResourcesMojo
Caused by: java.lang.NoClassDefFoundError:
Lorg/sonatype/plexus/build/incremental/BuildContext;
    at java.lang.Class.getDeclaredFields0 (Native Method)
    at java.lang.Class.privateGetDeclaredFields (Class.java:2583)
    at java.lang.Class.getDeclaredFields (Class.java:1916)
    at com.google.inject.spi.InjectionPoint.getDeclaredFields
(InjectionPoint.java:760)
Caused by: java.lang.ClassNotFoundException:
org.sonatype.plexus.build.incremental.BuildContext
    at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass
(SelfFirstStrategy.java:50)
    at
org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass
(ClassRealm.java:271)
    at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass
(ClassRealm.java:247)
    at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass
(ClassRealm.java:239)


Not sure what is going on with this
--
Jody Garnett


On Apr 19, 2022 at 9:58:23 AM, Jody Garnett <jody.garn...@gmail.com> wrote:

> Andrea was able to check and found that java util logging had some
> localization applied:
>
> Expected GeoTools.init() use native java util logging factory, was
> org.geotools.util.logging.DefaultLoggerFactory@4cc77c2e
> INFORMAZIONI LoggingIntegration - Welcome to Logging Integration Example
> CONFIGURAZIONE LoggingIntegration -
> java.util.logging.config.file=logging.properties
> CONFIGURAZIONE LoggingIntegration - Configuration logging.properties
> OTTIMALE LoggingIntegration - Everything is finest...
> MIGLIORE LoggingIntegration - Everything is finer...
> BUONO LoggingIntegration - Everything is fine...
> CONFIGURAZIONE LoggingIntegration - Everything is configured...
> INFORMAZIONI LoggingIntegration - Everything is okay.
> AVVERTENZA LoggingIntegration - Everything is alarming!
> GRAVE LoggingIntegration - Everything is terrible!
>
> And will send a PR (updating exec:exec target to execute integration test
> with en locale).
>
> Marco you have a lot more failure, can you troubleshoot and report back
> pls.
>
> --
> Jody Garnett
>
>
> On Apr 19, 2022 at 9:46:33 AM, Jody Garnett <jody.garn...@gmail.com>
> wrote:
>
>> One more idea, what was the exactly command line used when running?
>>
>> Adding -nsu or something may mess with ability of target/local-repo to be
>> populated (it is setup to treat your local repository as a mirror, so it
>> can be an integration test your current gt-metadata jar).
>> --
>> Jody Garnett
>>
>>
>> On Apr 19, 2022 at 9:39:13 AM, Jody Garnett <jody.garn...@gmail.com>
>> wrote:
>>
>>> I made sure to do nothing unusual when writing integration tests so that
>>> we could make use of any online resources for troubleshooting.
>>>
>>> Here is what I have figured out for maven:
>>>
>>> cd modules/library/metadata
>>> mvn clean install -DskipTests
>>>
>>> I asked it to build with parrallelThreads so the run vs results does not
>>> always line up (but build is faster):
>>>
>>> [INFO] use parallelThreads 8
>>> [INFO] Building: log4j/pom.xml
>>> [INFO] Building: commons/pom.xml
>>> [INFO] Building: reload4j/pom.xml
>>> [INFO] Building: logback/pom.xml
>>> [INFO] Building: logging/pom.xml
>>> [INFO] run post-build script postbuild.bsh
>>> [INFO] run post-build script postbuild.bsh
>>> [INFO] run post-build script postbuild.bsh
>>> [INFO] run post-build script postbuild.bsh
>>> [INFO]           logging/pom.xml ..................................
>>> SUCCESS (22.8 s)
>>> [INFO]           commons/pom.xml ..................................
>>> SUCCESS (22.8 s)
>>> [INFO]           reload4j/pom.xml .................................
>>> SUCCESS (22.8 s)
>>> [INFO]           logback/pom.xml ..................................
>>> SUCCESS (22.8 s)
>>> [INFO] run post-build script postbuild.bsh
>>> [INFO]           log4j/pom.xml ....................................
>>> SUCCESS (25.3 s)
>>>
>>> While I do not have your failure, here is what I would do to
>>> troubleshoot your failure with commons:
>>>
>>> The script that checks the output just tests for simple strings:
>>>
>>> cat src/it/commons/postbuild.bsh
>>>
>>> You can have a look  at the output it is checking:
>>>
>>> cd target/it/commons
>>> cat build.log
>>>
>>> The results includes text like the following:
>>>
>>> 2022-04-19 09:31:45:598 [INFO] logging - Welcome to Commons Logging
>>> Integration Example
>>> 2022-04-19 09:31:45:599 [INFO] logging - Configuration
>>> /Users/jgarnett/java/geotools/geotools/modules/library/metadata/target/it/commons/target/classes/commons-logging.properties
>>> 2022-04-19 09:31:45:599 [TRACE] logging - Everything is finest...
>>> 2022-04-19 09:31:45:599 [DEBUG] logging - Everything is finer...
>>> 2022-04-19 09:31:45:599 [DEBUG] logging - Everything is fine...
>>> 2022-04-19 09:31:45:600 [INFO] logging - Everything is configured...
>>> 2022-04-19 09:31:45:600 [INFO] logging - Everything is okay.
>>> 2022-04-19 09:31:45:600 [WARN] logging - Everything is alarming!
>>> 2022-04-19 09:31:45:600 [ERROR] logging - Everything is terrible!
>>>
>>> This target/it/commons project can be compiled on the command line:
>>>
>>> cd target/it/commons
>>> mvn clean install
>>> mvn exec:exec
>>>
>>> Here is what I have figured out for IntelliJ:
>>>
>>>
>>>    1. If you want you can add the projects directly to IntelliJ (using
>>>    add module, and then going to the src/it/logging folder (to trouble shoot
>>>    your logging failure below).
>>>    2. You can then compile and run this module
>>>    3. Keep in mind IntelliJ is making a folder src/it/logging/target
>>>    (and managing this pretty much as a separate project)
>>>    (For a while I was having trouble as IntelliJ was building and maven
>>>    was staging the resulting build)
>>>
>>>
>>> --
>>> Jody Garnett
>>>
>>>
>>> On Apr 19, 2022 at 9:24:23 AM, Andrea Aime <
>>> andrea.a...@geosolutionsgroup.com> wrote:
>>>
>>>> Hi,
>>>> a colleague of mine (Marco) today told me that the gt-metadata module
>>>> tests were failing:
>>>>
>>>> Building: logging\pom.xml
>>>> [INFO] Building: commons\pom.xml
>>>> [INFO] Building: logback\pom.xml
>>>> [INFO] Building: log4j\pom.xml
>>>> [INFO] Building: reload4j\pom.xml
>>>> [INFO] run post-build script postbuild.bsh
>>>> [INFO] run post-build script postbuild.bsh
>>>> [INFO] run post-build script postbuild.bsh
>>>> [INFO] run post-build script postbuild.bsh
>>>> [INFO] run post-build script postbuild.bsh
>>>> [INFO]   java.lang.IllegalStateException: INFO expected
>>>> [INFO]   java.lang.IllegalStateException: INFO expected
>>>> [INFO]   java.lang.IllegalStateException: log4j2.xml use expected
>>>> [INFO]   java.lang.IllegalStateException: INFO expected
>>>> [INFO]   java.lang.IllegalStateException: log4j.properties  use expected
>>>> [INFO]           reload4j\pom.xml .................................
>>>> FAILED (1.8 s)
>>>> [INFO]           logging\pom.xml ..................................
>>>> FAILED (1.8 s)
>>>> [INFO]           logback\pom.xml ..................................
>>>> FAILED (1.8 s)
>>>> [INFO]           log4j\pom.xml ....................................
>>>> FAILED (1.8 s)
>>>> [INFO]           commons\pom.xml ..................................
>>>> FAILED (1.8 s)
>>>>
>>>> So I tried locally, and can confirm at least one failure:
>>>>
>>>> [INFO]
>>>> [INFO] --- maven-invoker-plugin:3.2.2:integration-test
>>>> (integration-test) @ gt-metadata ---
>>>> [INFO] use parallelThreads 16
>>>> [INFO] Building: reload4j/pom.xml
>>>> [INFO] Building: logging/pom.xml
>>>> [INFO] Building: log4j/pom.xml
>>>> [INFO] Building: logback/pom.xml
>>>> [INFO] Building: commons/pom.xml
>>>> [INFO] run post-build script postbuild.bsh
>>>> [INFO] run post-build script postbuild.bsh
>>>> [INFO]   java.lang.IllegalStateException: INFO expected
>>>> [INFO]           logback/pom.xml ..................................
>>>> SUCCESS (25.2 s)
>>>> [INFO]           logging/pom.xml ..................................
>>>> FAILED (25.2 s)
>>>> [INFO] run post-build script postbuild.bsh
>>>> [INFO] run post-build script postbuild.bsh
>>>> [INFO]           reload4j/pom.xml .................................
>>>> SUCCESS (25.2 s)
>>>> [INFO]           commons/pom.xml ..................................
>>>> SUCCESS (25.2 s)
>>>> [INFO] run post-build script postbuild.bsh
>>>> [INFO]           log4j/pom.xml ....................................
>>>> SUCCESS (26.1 s)
>>>> [INFO]
>>>>
>>>> Now, I don't see them failing on the build server so...  I'm guessing
>>>> maybe it's due to locale? Or timezone?
>>>> Maybe with a hint of Windows in the mix? (Marco is running on it).
>>>>
>>>> How does one get more details about the failures?
>>>> I checked IntelliJ, the integration tests do not even load into it
>>>> (flat files, rather than modules)
>>>>
>>>> Cheers
>>>> Andrea
>>>>
>>>> ==
>>>> GeoServer Professional Services from the experts!
>>>>
>>>> Visit http://bit.ly/gs-services-us for more information.
>>>> ==
>>>>
>>>> Ing. Andrea Aime
>>>> @geowolf
>>>> Technical Lead
>>>>
>>>> GeoSolutions Group
>>>> phone: +39 0584 962313
>>>>
>>>> fax:     +39 0584 1660272
>>>>
>>>> mob:   +39  333 8128928
>>>>
>>>> https://www.geosolutionsgroup.com/
>>>>
>>>> http://twitter.com/geosolutions_it
>>>>
>>>> -------------------------------------------------------
>>>>
>>>> Con riferimento alla normativa sul trattamento dei dati personali (Reg.
>>>> UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
>>>> precisa che ogni circostanza inerente alla presente email (il suo
>>>> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
>>>> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
>>>> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
>>>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>>>>
>>>> This email is intended only for the person or entity to which it is
>>>> addressed and may contain information that is privileged, confidential or
>>>> otherwise protected from disclosure. We remind that - as provided by
>>>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
>>>> e-mail or the information herein by anyone other than the intended
>>>> recipient is prohibited. If you have received this email by mistake, please
>>>> notify us immediately by telephone or e-mail
>>>> _______________________________________________
>>>> GeoTools-Devel mailing list
>>>> GeoTools-Devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>>
>>>
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to