Hi Joachim, The reason to use two separate folders is that at deploy time we use [1]: $ cd jdk-1.6.x; JAVA_HOME=$JAVA_6_HOME mvn deploy .... $ cd ../jdk-7.x; JAVA_HOME=$JAVA_7_HOME mvn deploy .... $ cd ../jdk-8.x; JAVA_HOME=$JAVA_8_HOME mvn deploy ....
With your approach we could just use JAVA_8_HOME for all of them. m-compiler-p's settings will set the appropriate -target for each module. But this is not enough - we have to use something like http://mojo.codehaus.org/animal-sniffer-maven-plugin/ to make sure that jdk 1.6/7.x modules do not use feature from a newer JDK, because compiler's -target won't help. I think it should work. Do you want to try it out? 1. https://github.com/wicketstuff/core/wiki/Wicket-Stuff-Core-Release-Process#steps-to-create-new-version Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Wed, May 6, 2015 at 11:50 PM, Joachim Rohde <[email protected] > wrote: > Hi, > As I already mentioned the other day I was porting some changes from > master branch to the wicket-6.x branch ( > http://apache-wicket.1842946.n4.nabble.com/wicketstuff-Need-help-with-cherry-picking-td4670615.html) > and had some trouble doing so, since Git was not able to cherry-pick my > changes due to a different folder structure. Since this was really a pain > in the neck (and quite erroneous) I would like to know if we cannot get rid > of the distinction between different JDK versions in the folder structure. > > At the moment all projects on the master branch are located in the > jdk-1.7-parent folder (since no project requires Java 8 yet, the > jdk-1.8-parent folder is empty). Most of those projects reside in the > jdk-1.6-parent folder on the wicket-6.x branch, making it impossible to > simply downport changes via cherry-picking. Only difference between the > POMs in those folders are the source- and target-level for the Maven > compiler plugin. > > Can't we just put everything in one folder and override source- and > target-level in the project specific POM if a project needs a higher > version than the default one? The only drawback I see at the moment is the > fact, that you cannot recognize at a first glance if a project needs a > higher Java version. Or do I overlook here something? > > To be honest: I don't know if I would downport bigger changes on a project > when myself only needs those changes on the master branch (since I'm > already using Wicket 1.7) and downporting is such a hassle. > > Joachim >
