Eventually your approach with a sub-directory inside the target would be a valid option … would probably have to adjust the maven-clean-plugin too, but that should work in getting all results inside the target directory in parallel.
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>
