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 Thu, 08 Jun 2017 14:40:49 GMT
Hi Dale,

Today I had some progress on the java7 side.
I successfully added the retrolambda-maven-plugin in a dedicated java7 profile to the main
pom. Now the plugin automatically kicks in and converts the classes after compiling them.
I also added the animal-sniffer-maven-plugin to explicitly check against the signatures of
1.7 or 1.8 JDKs. This all seems to be working. Unfortunately, the backporting of default methods
in interfaces seems to be a problem. The default methods in DirectTestSetup can’t seem to
be backported if the interface and the implementing class are not in the same retrolambda
execution. Eventually refactoring the tests to work without default methods would be a good

The problem with classifiers is that maven automatically resolves artifacts. Depending on
the scope different artifacts are pulled in. In general, we would be using the “compile”
scope. So, if I add a dependency with classifier “java7” then it would pull in that jar
in the java7 version, but the transitive dependencies would probably be the java8 ones, so
you would have to explicitly define all the transitive dependencies with the classifier. We
don’t want that ;-)

I also contacted the maven guys on their mailing list. They did have the one or the other
solution. In general, they would all come down to adding the type to the version. So, we would
start producing “1.2.0.java7” and “1.2.0.java8” or “” and “”
versions (I would prefer the first as it doesn’t suggest the java 8 version being slightly
newer than the 7 version). Another alternative would be to prefix the version with the target
version. “” and “” … but I don’t really like that option. In this
case, I would have to refactor the build to use variables in all modules except the parent
poms (you can’t use variables for parent poms). Then travis/Jenkins would run two build:

mvn clean deploy
mvn clean deploy –Pjava7

In the end, it would result in both versions being built, tested and deployed, but in the
end the java7 version would remain in the workspace as the second executions “clean” removed
any reference to the java8 version.

Hope that explains the dilemma a little more. At least with these version-suffixes we would
have a fully working solution. I’ll get into changing this tomorrow.

By the way … anyone got an idea how I can make Travis not die on out of memory? Tried several
things, but it didn’t seem to do the job.


Am 08.06.17, 16:13 schrieb "Dale LaBossiere" <dml.apache@gmail.com>:

    > On Jun 8, 2017, at 4:19 AM, Christofer Dutz <christofer.dutz@c-ware.de> wrote:
    > Regarding java8 and java7 artifacts …
    Coincidentally, I started investigating this space yesterday and retrolambda-maven-plugin
    and was just composing mail on the question of publishing java8 and java7 to mvn repos
    [ fwiw, so far I had defined a Profile (e.g., mvn install -Ptgt=java7) and
    changed the “target” build directory to “target/${edgent.target.kind}”
    (e.g., target/{java8,java7}).  Things were working fine up to that point:
    generated class files and module jars. ]
    > This could be problematic, if we wanted to publish both.
    > ...
    > I could offer to generally build java7 versions and to test them with java7 and java8
… I think this topic should be discussed a little more before I start implementing this.
    > Right now, I would opt for distributing java8 binaries to Maven Central and to offer
downloadable java7 binary distributions.
    Ugh.  Publishing java8 in a mvn repo but java7/android as a binary tgz seems really bad.
    It creates two different ways (and needed doc) for users building an Edgent app
    and installing Edgent jars onto a “device”.
    Could you elaborate on the problems using the maven coordinate “classifier”?
    The maven doc [1] has this exactly as use case for it (they use “jdk15” vs “jdk14”).
    At a high (ignorant) level I don’t have a problem with the classifier being nil for
java8 :-)
    If using a coordinate classifier is a no-go, what about (grimace) incorporating it into
    groupId:  org.apache.edgent, org.apache.edgent.java7  ?
    A bit related, what coordinate component is “incubating” supposed to be incorporated
    — Dale
    [1] https://maven.apache.org/pom.html <https://maven.apache.org/pom.html>

View raw message