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 idea.
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 “1.2.0.7” and “1.2.0.8” 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. “7.1.2.0” and “8.1.2.0” … 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. Chris Am 08.06.17, 16:13 schrieb "Dale LaBossiere" <[email protected]>: > On Jun 8, 2017, at 4:19 AM, Christofer Dutz <[email protected]> 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 the groupId: org.apache.edgent, org.apache.edgent.java7 ? A bit related, what coordinate component is “incubating” supposed to be incorporated into? — Dale [1] https://maven.apache.org/pom.html <https://maven.apache.org/pom.html>
