edgent-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject Re: Understanding the snapshot and release process
Date Mon, 12 Jun 2017 21:04:22 GMT
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" <dml.apache@gmail.com>:

    
    > On Jun 12, 2017, at 10:23 AM, Christofer Dutz <christofer.dutz@c-ware.de> 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
    
    

Mime
View raw message