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 Mon, 19 Jun 2017 13:09:35 GMT
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 <christofer.dutz@c-ware.de> 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" <christofer.dutz@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.apache@gmail.com>:
> 
> 
>> On Jun 16, 2017, at 4:46 AM, Christofer Dutz <christofer.dutz@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
> 
> 
> 
> 
> 


Mime
View raw message