Hi Martin,

time is a bit scarce for me at the moment. But I will give it a try within the next few weeks.

Joachim

On 05/07/2015 08:21 AM, Martin Grigorov 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


Reply via email to