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 Sat, 17 Jun 2017 17:06:07 GMT
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