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" <christofer.d...@c-ware.de>:
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" <dml.apa...@gmail.com>:
> On Jun 16, 2017, at 4:46 AM, Christofer Dutz
<christofer.d...@c-ware.de> 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
