In the case of build_release.sh I am starting to suspect that something
has gone wrong with the metadata/target/settings.xml and
metadata/target/local_repo used to isolate the integration tests.
For now I have asked the build to ignore integration test failures, and I
can look at this when I retur
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@c96
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
CONFIGURAZIO
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
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 res
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
[INF
