edgent-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dale LaBossiere <dml.apa...@gmail.com>
Subject Re: Understanding the snapshot and release process
Date Thu, 08 Jun 2017 20:03:16 GMT
sorry no idea about travis and memory

On Jun 8, 2017, at 10:40 AM, Christofer Dutz <christofer.dutz@c-ware.de> wrote:
> ...
> Today I had some progress on the java7 side.
> problem. The default methods in DirectTestSetup can’t seem to be backported if the
interface and the implementing class are not in the same retrolambda execution. Eventually
refactoring the tests to work without default methods would be a good idea.
I’ll look into that.

> The problem with classifiers is that maven automatically resolves artifacts. Depending
on the scope different artifacts are pulled in. In general, we would be using the “compile”
scope. So, if I add a dependency with classifier “java7” then it would pull in that jar
in the java7 version, but the transitive dependencies would probably be the java8 ones, so
you would have to explicitly define all the transitive dependencies with the classifier. We
don’t want that ;-)

Thought I was following it but then not :-)  
I may have to try a test using classifier so as to really understand how/why it won’t work.

But if encoding tgt-kind in the versionId is the way to go… (I think it would be nice if
it could be avoided for tgt-java8, e.g., just 1.2.0, not 1.2.0.java8)

In travis I don’t think you’ll be able to just/only say
	mvn clean deploy			# compile/test/deploy java8
	mvn clean deploy -Pjava7	# compile/test/deploy java7

That’s because the compile for java7, including the tests, must be done with a java8 JDK
(with retrolambda then applied).  There’s no java7 JDK in the mix for java7 compile.

But to really test the compiled java7-compatible tests one has to first switch the environment
to a java7 JRE and then run them in that environment (they can’t be compiled in a java7
env because they use lambdas).

That’s why the travis / gradle/ant stuff was structured out the way it was:
	switch to java8
	gradlew release           # compiles Edgent into jars for java8,7,android.
					    # NOTE, tests are not bundled into jars. So there are just the j8 class files
	gradlew test                 # runs the already compiled Edgent tests (with java8)
	gradlew test7Compile  # recompile the tests-only to be java7 compatible
	switch to java7
	gradlew test7Run        # runs the already java7-compatible compiled Edgent tests (with java7)

Also at a high level I think we don’t want to deploy one config unless all configs are OK.

— Dale
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message