Hi Arnaud, Arnaud Héritier wrote:
> In short/middle term the lack of IDE integration isn't a real problem for > now. > Like Brian said, they know that users won't use such feature before > several years. > The runtime part providing the compatibility for the JRE should be > backported to Java 8 but only Java 9 JDK will provide required tools to > create such jars. > The goal to involve build tools ASAP is to validate the technical > feasibility to integrate such new feature before J9 is out (and not to > wait for its delivery to do it - and complain when it will be too late) You can already use several executions for the compiler plugin to create a jar file with classes targeting different JDKs. That's what XStream does for years already. The challenge is that you have multiple class files with same name. > What we need to do here is to imagine how it will be in 2/3? years when > we'll start to have developers using a JDK9 who'll want to provide > librairies compatible (and optimized) for previous JREs. > > For me (in my dreams) it should clearly be in only one module and thus > probably with additional sources directories. The compiler plugin should > hide (in one or several steps) the compilation of sources and the jar > packaging should discover if it has to create a mvjar or not You have different use cases here. One time you have one Java source that will behave different depending against which runtime libs you have compiled (e.g. a different overloaded method is used). In another scenario your Java code actually differs. So, for Maven there might be several src folders ... or you have annotations at types, methods and/or fields indicating the target runtime. However, the result should be a jar file that allows a client to write code that is indifferent of the multiple versions of a class. Wait ... maybe the client will have to create a mvjar himself, because the different versions also result in different versions of his own code (think about JDBC api) ...? IMHO, mvjars will create a bigger maintenance mess than the current solutions. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
