Great news/progress!
I think it’s OK if j7 tests are not run for PRs/travis and only run from
Jenkins for SNAPSHOTS/release
Shorter PR validation times… yay! :-)
Will all this work for creating our android platform release artifacts?
Two things happen when generating the android release:
- a subset of the j7 jars are included (some filtered out due to utilizing
features not available on android)
- the android-{topology, hardware} jars are built on j8/j7 and included in the
android release,
but they are removed from j8/j7 before releasing j8/j7.
— Dale
> On Jun 17, 2017, at 1:06 PM, Christofer Dutz <[email protected]>
> wrote:
>
> Ok … reporting some progress here.
>
> I managed to get the build to create the java8 and the java7 artifacts in one
> run and to run the tests in both versions.
> The only thing I am currently struggling with is the Maven toolchain support.
>
> Maven provides a mechanism called “toolchains” in which you can for example
> define multiple JDKs and use this to do exactly what we want: run all tests
> in the normal modules with Java8 and the ones in the Java7 modules with
> Java7. Unfortunately, we would need the paths to the JDKs on Travis to use
> this. It would be easy on Apache Jenkins, but right now I think it would
> probably be better to let the tests on Travis all run with Java8 and to run
> the Java7 tests with Java7 on the ASF Jenkins.
>
> What do you think?
>
> Will continue porting all the individual modules … currently only ported the
> api modules . A lot more to go ;-)
>
> Chris
>
>
>
> Am 17.06.17, 16:29 schrieb "Christofer Dutz" <[email protected]>:
>
> Ok … so I think I might have a possible solution, thanks to Karl Heinz
> Marbaise on the Maven list.
>
> We don’t use profiles at all and build all artifacts in one run. The
> difference would be that we create mini modules in the “java7” directory
> which build the java7 versions of the java8 artifacs by copying and unpacking
> the java8 versions to the mini projects target directory, have retrolambda do
> it’s magic there and package them normally. In this case, I would like to use
> a different groupId for the java7 artifacts instead of using different
> versions as this way we will have far less trouble releasing stuff.
>
> Using maven toolchains I might even be able to run the transformed tests
> in the mini projects with java7 … haven’t used toolchains till now, but it
> looks as if they would deliver exactly the functionality we need.
>
> So I’m going to give this approach a try.
>
> Chris
>
>
> Am 16.06.17, 18:43 schrieb "Dale LaBossiere" <[email protected]>:
>
>
>> On Jun 16, 2017, at 4:46 AM, Christofer Dutz <[email protected]>
>> wrote:
>>
>> In case of a variable for the groupId the warning is the same except that it
>> mentions groupId instead of version :-(
>
> Hmm… any thoughts on plausible alternatives? ...and implications to
> dev, release, and consumption of java7&android Edgent?
>
> At a high level, something just seems wrong that it’s this hard to
> create multiple variants of a product w/mvn, where the variants’
> jars need different coordinates along some dimension.
> The retrolambda plugin may be complicating things but it doesn't
> feel like it’s the cause of the main issue: variable coordinate decls.
>
> Related, without the use of variable-version decls, even ignoring
> this j8/j7 thing, there would be <version>1.2.0-SNAPSHOT</version>
> throughout every one of our (~65) poms. Even using
> variable-version decls, that static decl is present in every pom’s
> <parent> decl! Is it the really case that when we want to release
> 1.2.0 (not SNAPSHOT) or when it’s time for 1.3.0, every pom
> has to be edited?
>
> Just brainstorming… my head hurts :-\ I apologize in advance… :-)
>
> E<n> means Edgent-java<n> ...
>
> Is there any ~convenient way to synthesize/use alternate pom’s for E7?
> Might there be a way to leverage “mvn —file <pom>” and also
> pom.xml:<relativePath>?
>
> e.g., have the pom.xml implicitly be j8/E8 oriented with non-variable
> coordinate decl for the project.
>
> Imagine building / staging a RC for E7 would be something like:
>
> mk-j7-poms # create pom-j7.xml files adding “-java7” in
> versions and a “relativePath” of ../pom-j7.xml
> # **/pom-7.xml added to .gitignore; target
> dir is still variable
>
> mvn -f pom-j7.xml -Pjava7 clean install -DskipTests
> # TBD do j7 testing
> # …
> mvn -f pom-j7.xml -Pjava7 deploy -Papache-release -DskipTests
>
> Or if we’re going that far, then maybe needing/using a separate
> clone/workspace to build & deploy E7 might be tolerable?
>
> Though… while the gradle/ant tooling created j7 jars using *the* j8
> jars,
> this mvn tooling is already regenerating the j8 classes
> and then running them through retrolambda, right? (if so, ugh)
>
> Kinda feels like E7 artifacts should instead just declare a
> dependency on their corresponding E8 jar artifact (not src)
> and just do some (retrolambda) transform to generate the E7 jar
> artifacts.
> Which seems to imply separate (~parallel) simpler poms for E7
> which can then also have non-variable-version decl?
> e.g., then something like
> cd java7
> mvn clean install -DskipTests
> # TBD test
> mvn deploy -Papache-release -DskipTests
>
> Also, the current "mvn install -Papache-release -Pjava7"
> generates -sources.jar, -javadoc.jar, -source-release.zip
> Do we really want to distribute those (duplicate) set of those
> artifacts?
> Don’t know if that might just mean more config tweaking or
> if the retrolambda plugin / “deploy” flow for java isn’t really what
> we want.
>
> Your thoughts on all of this?
>
> — Dale
>
>
>
>
>
