For Wicket proper we now have toolchains support to switch between jdk 6, 7 [and possibly 8]. There's no reason to not use this for wicket stuff IMO.
Martijn On Thu, May 7, 2015 at 8:21 AM, Martin Grigorov <[email protected]> wrote: > 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 >> -- Become a Wicket expert, learn from the best: http://wicketinaction.com
