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 14:29:28 GMT
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