Well Maven can do quite a lot of things. But there’s one base principal which I lay great emphasis on in my Maven trainings. “If it’s hard to do with Maven, you’re probably doing it wrong” :-)
I guess the main problem is that we need Java8 to compile the tests and Java7 to run them. As a maven build fires up a VM to do the build the version of java used throughout the build is sort of defined by this call to run maven. Anything else would require to fork a new process with the JavaVM VM … this is not handled. If it was possible to build and test with java7, this wouldn’t be a problem. I guess also executing the pre-built test with java7 should also be possible, but I’m struggling with one other of your requirements: “Only deploy everything if the java8, java7 and android builds succeed”. I hope you can see the dilemma. Here it might be a better option to add a Jenkinsfile to the repository and setup a Jenkins job on the ASF Jenkins. With this I am a lot more flexible than with Travis. We could continue to use Travis for the auto-testing of pull requests, but would live with running the java7 testsuite with a java8 VM, but have the Jenkins job deploy the SNAPSHOTS to the ASF repo. What do you think about that? Building on Apache Machines also gives a lot of other benefits. Chris Am 12.06.17, 18:55 schrieb "Dale LaBossiere" <[email protected]>: > On Jun 12, 2017, at 10:23 AM, Christofer Dutz <[email protected]> wrote: > > Well “mvn test” would run the maven lifecycle up to the test phase, this includes compiling etc … and compiling doesn’t work with Java7. Maven doesn’t have the notion of build-avoidance / artifact reuse? I can imagine that even if it did, it might record the JDK version used to generate the artifacts and then not reuse them when the current JDK version is different. > We could probably create some solution to manually load and run the tests inside the test-jars but integrating this into one nice Maven build could be a challenging task, so say the least … but we wouldn’t have to, if you would be ok with the signature-verification option. I’m holding out till I better understand maven’s behavior/limitations and what other strategies might exist :-) > > Seems not, so I’ll continue digging … but this one will probably take a little longer. What do other projects do if for example they build/release to a least-common-demonitor, e.g., 1.7, and still want to do actual test verification against the higher compatible/supported version, e.g., 1.8? They don’t/can’t use standard maven machinery for that? They must build some parallel test execution / reporting machinery? — Dale
