> 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>
