> On Jun 8, 2017, at 4:19 AM, Christofer Dutz <christofer.d...@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 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>


Reply via email to