You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Joachim Rohde <ma...@joachimrohde.com> on 2015/05/06 22:50:51 UTC
[wicketstuff] Can't we get rid of the distinction between JDK-versions
on the folder level?
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
Re: [wicketstuff] Can't we get rid of the distinction between
JDK-versions on the folder level?
Posted by Martin Grigorov <mg...@apache.org>.
I'll do it in the next few days!
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Wed, Aug 12, 2015 at 12:54 PM, Joachim Rohde <
mailinglist@joachimrohde.com> wrote:
> Had anyone had the chance to have a look already at this?
>
>
> On 07/31/2015 11:25 PM, Joachim Rohde wrote:
>
>> I finally found the time today to make those changes which you can find
>> here: https://github.com/JoachimRohde/core
>>
>> Since the diff is "slightly" bigger than usually, here a short
>> description of the relevant changes I made:
>>
>> - The animal sniffer plugin was integrated into the parent POM where it
>> is now executed during the compile phase (see:
>>
>> https://github.com/wicketstuff/core/commit/5f68a8e7f9fb94dd4536817556aefb41aeb5afeb#diff-f44ca8b53c4fd9a67160bc238396d231
>> )
>>
>>
>> - Where it was necessary I overwrote the settings in the project POMs
>> (see e.g.:
>>
>> https://github.com/wicketstuff/core/commit/5f68a8e7f9fb94dd4536817556aefb41aeb5afeb#diff-290ebaa69933b91a6f5c1e25f609062a
>> )
>>
>>
>> - I moved all project folders to the root-folder and included the
>> modules in the POM. The remaining JDK-specific folders with the
>> respective POM has been removed.
>>
>> Same I did for the wicket-6.x branch.
>>
>> Any new project on the wicket-6.x branch which uses a newer JDK than
>> version 6 would need to include following in the project POM:
>>
>> <build>
>> <pluginManagement>
>> <plugins>
>> <!--
>> Overwrite compiler plugin configuration from parent-POM
>> since we want this project to allow features from Java 7.
>> -->
>> <plugin>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-compiler-plugin</artifactId>
>> <configuration>
>> <source>1.7</source>
>> <target>1.7</target>
>> </configuration>
>> </plugin>
>> </plugins>
>> </pluginManagement>
>> <plugins>
>> <!--
>> Overwrite animal sniffer plugin configuration from parent-POM
>> since we want this project to allow features from Java 7.
>> -->
>> <plugin>
>> <groupId>org.codehaus.mojo</groupId>
>> <artifactId>animal-sniffer-maven-plugin</artifactId>
>>
>> <executions>
>> <execution>
>> <id>check-java-version</id>
>> <phase>compile</phase>
>> <goals>
>> <goal>check</goal>
>> </goals>
>> <configuration>
>> <signature>
>>
>> <groupId>org.codehaus.mojo.signature</groupId>
>> <artifactId>java17</artifactId>
>> <version>1.0</version>
>> </signature>
>> </configuration>
>> </execution>
>> </executions>
>> </plugin>
>> </plugins>
>> </build>
>>
>> Same applies to new projects on the master branch which wants to take
>> adavantage of the JDK 8. At the moment we don't have any projects which
>> requires JDK 8.
>> But since there is no signature from animal sniffer itself for JDK 8
>> yet, the project POM looks a bit different:
>>
>>
>> <build>
>> <pluginManagement>
>> <plugins>
>> <!--
>> Overwrite compiler plugin configuration from parent-POM
>> since we want this project to allow features from Java 7.
>> -->
>> <plugin>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-compiler-plugin</artifactId>
>> <configuration>
>> <source>1.8</source>
>> <target>1.8</target>
>> </configuration>
>> </plugin>
>> </plugins>
>> </pluginManagement>
>> <plugins>
>> <!--
>> Overwrite animal sniffer plugin configuration from parent-POM
>> since we want this project to allow features from Java 7.
>> -->
>> <plugin>
>> <groupId>org.codehaus.mojo</groupId>
>> <artifactId>animal-sniffer-maven-plugin</artifactId>
>>
>> <executions>
>> <execution>
>> <id>check-java-version</id>
>> <phase>compile</phase>
>> <goals>
>> <goal>check</goal>
>> </goals>
>> <configuration>
>> <signature>
>>
>> <groupId>com.ianbrandt.maven.signature</groupId>
>> <artifactId>java1.8</artifactId>
>> <version>1.0</version>
>> </signature>
>> </configuration>
>> </execution>
>> </executions>
>> </plugin>
>> </plugins>
>> </build>
>>
>> The artifact for the signature comes from
>> https://github.com/ianbrandt/animal-sniffer-signatures and needs to be
>> deployed manually to the local Maven repository since it's not available
>> on Maven central.
>>
>> Any feedback is highly appreciated. (Anything unclear? Have I missed
>> something?)
>>
>> Joachim
>>
>> On 05/17/2015 02:58 PM, Joachim Rohde wrote:
>>
>>> I would change both branches. If only one branch is changed nothing
>>> would change (regarding the cherry picking).
>>>
>>> Joachim
>>>
>>> On 05/17/2015 02:23 PM, Martin Grigorov wrote:
>>>
>>>> Hi Joachim,
>>>>
>>>> What is your plan? Make the change only in master or also in
>>>> wicket-6.x too?
>>>>
>>>> Martin Grigorov
>>>> Wicket Training and Consulting
>>>> https://twitter.com/mtgrigorov
>>>>
>>>> On Sun, May 17, 2015 at 12:46 PM, Joachim Rohde <
>>>> mailinglist@joachimrohde.com> wrote:
>>>>
>>>> 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 <
>>>>>> mailinglist@joachimrohde.com
>>>>>>
>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
Re: [wicketstuff] Can't we get rid of the distinction between JDK-versions
on the folder level?
Posted by Joachim Rohde <ma...@joachimrohde.com>.
Had anyone had the chance to have a look already at this?
On 07/31/2015 11:25 PM, Joachim Rohde wrote:
> I finally found the time today to make those changes which you can find
> here: https://github.com/JoachimRohde/core
>
> Since the diff is "slightly" bigger than usually, here a short
> description of the relevant changes I made:
>
> - The animal sniffer plugin was integrated into the parent POM where it
> is now executed during the compile phase (see:
> https://github.com/wicketstuff/core/commit/5f68a8e7f9fb94dd4536817556aefb41aeb5afeb#diff-f44ca8b53c4fd9a67160bc238396d231)
>
>
> - Where it was necessary I overwrote the settings in the project POMs
> (see e.g.:
> https://github.com/wicketstuff/core/commit/5f68a8e7f9fb94dd4536817556aefb41aeb5afeb#diff-290ebaa69933b91a6f5c1e25f609062a)
>
>
> - I moved all project folders to the root-folder and included the
> modules in the POM. The remaining JDK-specific folders with the
> respective POM has been removed.
>
> Same I did for the wicket-6.x branch.
>
> Any new project on the wicket-6.x branch which uses a newer JDK than
> version 6 would need to include following in the project POM:
>
> <build>
> <pluginManagement>
> <plugins>
> <!--
> Overwrite compiler plugin configuration from parent-POM
> since we want this project to allow features from Java 7.
> -->
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-compiler-plugin</artifactId>
> <configuration>
> <source>1.7</source>
> <target>1.7</target>
> </configuration>
> </plugin>
> </plugins>
> </pluginManagement>
> <plugins>
> <!--
> Overwrite animal sniffer plugin configuration from parent-POM
> since we want this project to allow features from Java 7.
> -->
> <plugin>
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>animal-sniffer-maven-plugin</artifactId>
>
> <executions>
> <execution>
> <id>check-java-version</id>
> <phase>compile</phase>
> <goals>
> <goal>check</goal>
> </goals>
> <configuration>
> <signature>
>
> <groupId>org.codehaus.mojo.signature</groupId>
> <artifactId>java17</artifactId>
> <version>1.0</version>
> </signature>
> </configuration>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
>
> Same applies to new projects on the master branch which wants to take
> adavantage of the JDK 8. At the moment we don't have any projects which
> requires JDK 8.
> But since there is no signature from animal sniffer itself for JDK 8
> yet, the project POM looks a bit different:
>
>
> <build>
> <pluginManagement>
> <plugins>
> <!--
> Overwrite compiler plugin configuration from parent-POM
> since we want this project to allow features from Java 7.
> -->
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-compiler-plugin</artifactId>
> <configuration>
> <source>1.8</source>
> <target>1.8</target>
> </configuration>
> </plugin>
> </plugins>
> </pluginManagement>
> <plugins>
> <!--
> Overwrite animal sniffer plugin configuration from parent-POM
> since we want this project to allow features from Java 7.
> -->
> <plugin>
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>animal-sniffer-maven-plugin</artifactId>
>
> <executions>
> <execution>
> <id>check-java-version</id>
> <phase>compile</phase>
> <goals>
> <goal>check</goal>
> </goals>
> <configuration>
> <signature>
>
> <groupId>com.ianbrandt.maven.signature</groupId>
> <artifactId>java1.8</artifactId>
> <version>1.0</version>
> </signature>
> </configuration>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
>
> The artifact for the signature comes from
> https://github.com/ianbrandt/animal-sniffer-signatures and needs to be
> deployed manually to the local Maven repository since it's not available
> on Maven central.
>
> Any feedback is highly appreciated. (Anything unclear? Have I missed
> something?)
>
> Joachim
>
> On 05/17/2015 02:58 PM, Joachim Rohde wrote:
>> I would change both branches. If only one branch is changed nothing
>> would change (regarding the cherry picking).
>>
>> Joachim
>>
>> On 05/17/2015 02:23 PM, Martin Grigorov wrote:
>>> Hi Joachim,
>>>
>>> What is your plan? Make the change only in master or also in
>>> wicket-6.x too?
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>> https://twitter.com/mtgrigorov
>>>
>>> On Sun, May 17, 2015 at 12:46 PM, Joachim Rohde <
>>> mailinglist@joachimrohde.com> wrote:
>>>
>>>> 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 <
>>>>> mailinglist@joachimrohde.com
>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>
>>
>
Re: [wicketstuff] Can't we get rid of the distinction between JDK-versions
on the folder level?
Posted by Joachim Rohde <ma...@joachimrohde.com>.
I finally found the time today to make those changes which you can find
here: https://github.com/JoachimRohde/core
Since the diff is "slightly" bigger than usually, here a short
description of the relevant changes I made:
- The animal sniffer plugin was integrated into the parent POM where it
is now executed during the compile phase (see:
https://github.com/wicketstuff/core/commit/5f68a8e7f9fb94dd4536817556aefb41aeb5afeb#diff-f44ca8b53c4fd9a67160bc238396d231)
- Where it was necessary I overwrote the settings in the project POMs
(see e.g.:
https://github.com/wicketstuff/core/commit/5f68a8e7f9fb94dd4536817556aefb41aeb5afeb#diff-290ebaa69933b91a6f5c1e25f609062a)
- I moved all project folders to the root-folder and included the
modules in the POM. The remaining JDK-specific folders with the
respective POM has been removed.
Same I did for the wicket-6.x branch.
Any new project on the wicket-6.x branch which uses a newer JDK than
version 6 would need to include following in the project POM:
<build>
<pluginManagement>
<plugins>
<!--
Overwrite compiler plugin configuration from parent-POM
since we want this project to allow features from Java 7.
-->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<!--
Overwrite animal sniffer plugin configuration from parent-POM
since we want this project to allow features from Java 7.
-->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>animal-sniffer-maven-plugin</artifactId>
<executions>
<execution>
<id>check-java-version</id>
<phase>compile</phase>
<goals>
<goal>check</goal>
</goals>
<configuration>
<signature>
<groupId>org.codehaus.mojo.signature</groupId>
<artifactId>java17</artifactId>
<version>1.0</version>
</signature>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Same applies to new projects on the master branch which wants to take
adavantage of the JDK 8. At the moment we don't have any projects which
requires JDK 8.
But since there is no signature from animal sniffer itself for JDK 8
yet, the project POM looks a bit different:
<build>
<pluginManagement>
<plugins>
<!--
Overwrite compiler plugin configuration from parent-POM
since we want this project to allow features from Java 7.
-->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<!--
Overwrite animal sniffer plugin configuration from parent-POM
since we want this project to allow features from Java 7.
-->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>animal-sniffer-maven-plugin</artifactId>
<executions>
<execution>
<id>check-java-version</id>
<phase>compile</phase>
<goals>
<goal>check</goal>
</goals>
<configuration>
<signature>
<groupId>com.ianbrandt.maven.signature</groupId>
<artifactId>java1.8</artifactId>
<version>1.0</version>
</signature>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
The artifact for the signature comes from
https://github.com/ianbrandt/animal-sniffer-signatures and needs to be
deployed manually to the local Maven repository since it's not available
on Maven central.
Any feedback is highly appreciated. (Anything unclear? Have I missed
something?)
Joachim
On 05/17/2015 02:58 PM, Joachim Rohde wrote:
> I would change both branches. If only one branch is changed nothing
> would change (regarding the cherry picking).
>
> Joachim
>
> On 05/17/2015 02:23 PM, Martin Grigorov wrote:
>> Hi Joachim,
>>
>> What is your plan? Make the change only in master or also in
>> wicket-6.x too?
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Sun, May 17, 2015 at 12:46 PM, Joachim Rohde <
>> mailinglist@joachimrohde.com> wrote:
>>
>>> 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 <
>>>> mailinglist@joachimrohde.com
>>>>
>>>>> 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
>>>>>
>>>>>
>>>>
>>
>
Re: [wicketstuff] Can't we get rid of the distinction between
JDK-versions on the folder level?
Posted by Martin Grigorov <mg...@apache.org>.
http://developer-blog.cloudbees.com/2014/12/beware-siren-target-call.html
A blog post explaining that animal-sniffer is not perfect ...
Martin Grigorov
Freelancer. Available for hire!
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Sun, May 17, 2015 at 3:58 PM, Joachim Rohde <mailinglist@joachimrohde.com
> wrote:
> I would change both branches. If only one branch is changed nothing would
> change (regarding the cherry picking).
>
> Joachim
>
>
> On 05/17/2015 02:23 PM, Martin Grigorov wrote:
>
>> Hi Joachim,
>>
>> What is your plan? Make the change only in master or also in wicket-6.x
>> too?
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Sun, May 17, 2015 at 12:46 PM, Joachim Rohde <
>> mailinglist@joachimrohde.com> wrote:
>>
>> 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 <
>>>> mailinglist@joachimrohde.com
>>>>
>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>
Re: [wicketstuff] Can't we get rid of the distinction between JDK-versions
on the folder level?
Posted by Joachim Rohde <ma...@joachimrohde.com>.
I would change both branches. If only one branch is changed nothing
would change (regarding the cherry picking).
Joachim
On 05/17/2015 02:23 PM, Martin Grigorov wrote:
> Hi Joachim,
>
> What is your plan? Make the change only in master or also in wicket-6.x too?
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Sun, May 17, 2015 at 12:46 PM, Joachim Rohde <
> mailinglist@joachimrohde.com> wrote:
>
>> 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 <
>>> mailinglist@joachimrohde.com
>>>
>>>> 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
>>>>
>>>>
>>>
>
Re: [wicketstuff] Can't we get rid of the distinction between
JDK-versions on the folder level?
Posted by Martin Grigorov <mg...@apache.org>.
Hi Joachim,
What is your plan? Make the change only in master or also in wicket-6.x too?
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Sun, May 17, 2015 at 12:46 PM, Joachim Rohde <
mailinglist@joachimrohde.com> wrote:
> 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 <
>> mailinglist@joachimrohde.com
>>
>>> 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
>>>
>>>
>>
Re: [wicketstuff] Can't we get rid of the distinction between JDK-versions
on the folder level?
Posted by Joachim Rohde <ma...@joachimrohde.com>.
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 <mailinglist@joachimrohde.com
>> 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
>>
>
Re: [wicketstuff] Can't we get rid of the distinction between
JDK-versions on the folder level?
Posted by Maxim Solodovnik <so...@gmail.com>.
WOW I was able to build wicketstuff using default memory settings!
This is absolutely amazing :)
On Tue, Sep 1, 2015 at 2:26 AM, Martin Grigorov <mg...@apache.org>
wrote:
> On Mon, Aug 31, 2015 at 10:16 PM, Joachim Rohde <
> mailinglist@joachimrohde.com> wrote:
>
> > I get this error when I simply run
> >
> > mvn install
> >
> > from the command line using the master branch.
> >
> > My toolchains.xml looks like:
> >
> > <?xml version="1.0" encoding="UTF8"?>
> > <toolchains>
> > <!-- JDK toolchains -->
> > <toolchain>
> > <type>jdk</type>
> > <provides>
> > <version>1.7</version>
> > <vendor>sun</vendor>
> > </provides>
> > <configuration>
> > <jdkHome>/usr/lib/jvm/java-7-openjdk-amd64</jdkHome>
> > </configuration>
> > </toolchain>
> > <toolchain>
> > <type>jdk</type>
> > <provides>
> > <version>1.8</version>
> > <vendor>sun</vendor>
> > </provides>
> > <configuration>
> > <jdkHome>/usr/lib/jvm/java-8-oracle</jdkHome>
> > </configuration>
> > </toolchain>
> >
> > </toolchains>
> >
> > Maybe it's a problem with OpenJDK. (Only reason I use OpenJDK 7, is the
> > fact, that it was still installed and before using toolchains I was not
> in
> > the need of a JDK 7).
>
>
> Could be. I use Oracle JDKs and I don't face such problem.
> Try whether fix like
>
> https://github.com/l0rdn1kk0n/wicket-bootstrap/commit/ed8494b29385cb22ebf72461f6a9041089b7a2e9
> will help in your case.
>
>
> >
> >
> > Joachim
> >
> >
> >
> > On 08/31/2015 07:39 PM, Martin Grigorov wrote:
> >
> >> On Sun, Aug 30, 2015 at 7:57 PM, Joachim Rohde <
> >> mailinglist@joachimrohde.com
> >>
> >>> wrote:
> >>>
> >>
> >> Thanks for the effort, Martin. This makes things *really* easier.
> >>>
> >>> But just two small issues I encountered while compiling
> >>>
> >>> 1) I hadn't had toolchains configured on my machine so I was not able
> to
> >>> compile the project at first. I added a short paragraph in the Wiki (
> >>> https://github.com/wicketstuff/core/wiki#toolchains) to point this
> out.
> >>>
> >>> What I haven't updated is the wiki entry about the release process (
> >>>
> >>>
> https://github.com/wicketstuff/core/wiki/Wicket-Stuff-Core-Release-Process
> >>> )
> >>>
> >>> 2) I needed to set ${javadoc.disabled} to true, to compile everything,
> >>> else the JavaDoc plugin would fail:
> >>>
> >>> Failed to execute goal
> >>> org.apache.maven.plugins:maven-javadoc-plugin:2.10.3:jar
> (attach-javadoc)
> >>> on project wicketstuff-annotation: MavenReportException: Error while
> >>> generating Javadoc:
> >>> Exit code: 1 -
> >>>
> >>>
> /home/jr/NetBeansProjects/wicketstuff-newfolderstruct/core/annotation/src/main/java/org/wicketstuff/annotation/mount/MountPath.java:36:
> >>> error: reference not found
> >>> * {@link
> >>>
> >>>
> org.apache.wicket.protocol.http.request.WebRequestCodingStrategy#getMountEncoder(org.apache.wicket.IRequestTarget)}
> >>> ^
> >>>
> >>>
> /home/jr/NetBeansProjects/wicketstuff-newfolderstruct/core/annotation/src/main/java/org/wicketstuff/annotation/scan/AnnotatedMountScanner.java:126:
> >>> warning: no @param for pattern
> >>> public List<Class<?>> getPackageMatches(String pattern)
> >>> ^
> >>>
> >>>
> >> How exactly I could reproduce this?
> >> I've tried with Java 8 but m-toolchains-p correctly uses Java 7 for
> >> compiling and for javadoc and there are no errors here.
> >>
> >>
> >> [...]
> >>>
> >>>
> >>> Is this on purpose? Or should we work-around it (solutions can be found
> >>> here:
> >>>
> >>>
> http://stackoverflow.com/questions/15886209/maven-is-not-working-in-java-8-when-javadoc-tags-are-incomplete
> >>> )
> >>>
> >>>
> >>> Joachim
> >>>
> >>>
> >>> On 08/22/2015 05:03 PM, Martin Grigorov wrote:
> >>>
> >>> Done.
> >>>> It should be easier to port changes now!
> >>>>
> >>>> Martin Grigorov
> >>>> Wicket Training and Consulting
> >>>> https://twitter.com/mtgrigorov
> >>>>
> >>>> On Sat, Aug 22, 2015 at 8:47 AM, Martin Grigorov <
> mgrigorov@apache.org>
> >>>> wrote:
> >>>>
> >>>> I start working on this.
> >>>>
> >>>>> Please do not push to WicketStuff 6.x and master until I'm ready.
> >>>>>
> >>>>> Martin Grigorov
> >>>>> Wicket Training and Consulting
> >>>>> https://twitter.com/mtgrigorov
> >>>>>
> >>>>> On Sun, Aug 16, 2015 at 7:23 PM, Martin Grigorov <
> mgrigorov@apache.org
> >>>>> >
> >>>>> wrote:
> >>>>>
> >>>>> +1 for toolchains!
> >>>>>
> >>>>>>
> >>>>>> I think we should start by introducing m-toolchains-p in the current
> >>>>>> POMs. Just to make sure that running "mvn clean package" on the
> parent
> >>>>>> project builds successfully all modules.
> >>>>>> Then the second step is to remove jdk-1** middle modules and make
> the
> >>>>>> flat hierarchy.
> >>>>>>
> >>>>>> @Joachim: do you want to do this yourself? Otherwise I may have the
> >>>>>> time
> >>>>>> next week
> >>>>>>
> >>>>>> Martin Grigorov
> >>>>>> Wicket Training and Consulting
> >>>>>> https://twitter.com/mtgrigorov
> >>>>>>
> >>>>>> On Wed, Aug 12, 2015 at 3:16 PM, Martijn Dashorst <
> >>>>>> martijn.dashorst@gmail.com> wrote:
> >>>>>>
> >>>>>> 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 <
> >>>>>>> mgrigorov@apache.org>
> >>>>>>> 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 <
> >>>>>>>>
> >>>>>>>> mailinglist@joachimrohde.com
> >>>>>>>
> >>>>>>> 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
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
>
--
WBR
Maxim aka solomax
Re: [wicketstuff] Can't we get rid of the distinction between
JDK-versions on the folder level?
Posted by Martin Grigorov <mg...@apache.org>.
On Mon, Aug 31, 2015 at 10:16 PM, Joachim Rohde <
mailinglist@joachimrohde.com> wrote:
> I get this error when I simply run
>
> mvn install
>
> from the command line using the master branch.
>
> My toolchains.xml looks like:
>
> <?xml version="1.0" encoding="UTF8"?>
> <toolchains>
> <!-- JDK toolchains -->
> <toolchain>
> <type>jdk</type>
> <provides>
> <version>1.7</version>
> <vendor>sun</vendor>
> </provides>
> <configuration>
> <jdkHome>/usr/lib/jvm/java-7-openjdk-amd64</jdkHome>
> </configuration>
> </toolchain>
> <toolchain>
> <type>jdk</type>
> <provides>
> <version>1.8</version>
> <vendor>sun</vendor>
> </provides>
> <configuration>
> <jdkHome>/usr/lib/jvm/java-8-oracle</jdkHome>
> </configuration>
> </toolchain>
>
> </toolchains>
>
> Maybe it's a problem with OpenJDK. (Only reason I use OpenJDK 7, is the
> fact, that it was still installed and before using toolchains I was not in
> the need of a JDK 7).
Could be. I use Oracle JDKs and I don't face such problem.
Try whether fix like
https://github.com/l0rdn1kk0n/wicket-bootstrap/commit/ed8494b29385cb22ebf72461f6a9041089b7a2e9
will help in your case.
>
>
> Joachim
>
>
>
> On 08/31/2015 07:39 PM, Martin Grigorov wrote:
>
>> On Sun, Aug 30, 2015 at 7:57 PM, Joachim Rohde <
>> mailinglist@joachimrohde.com
>>
>>> wrote:
>>>
>>
>> Thanks for the effort, Martin. This makes things *really* easier.
>>>
>>> But just two small issues I encountered while compiling
>>>
>>> 1) I hadn't had toolchains configured on my machine so I was not able to
>>> compile the project at first. I added a short paragraph in the Wiki (
>>> https://github.com/wicketstuff/core/wiki#toolchains) to point this out.
>>>
>>> What I haven't updated is the wiki entry about the release process (
>>>
>>> https://github.com/wicketstuff/core/wiki/Wicket-Stuff-Core-Release-Process
>>> )
>>>
>>> 2) I needed to set ${javadoc.disabled} to true, to compile everything,
>>> else the JavaDoc plugin would fail:
>>>
>>> Failed to execute goal
>>> org.apache.maven.plugins:maven-javadoc-plugin:2.10.3:jar (attach-javadoc)
>>> on project wicketstuff-annotation: MavenReportException: Error while
>>> generating Javadoc:
>>> Exit code: 1 -
>>>
>>> /home/jr/NetBeansProjects/wicketstuff-newfolderstruct/core/annotation/src/main/java/org/wicketstuff/annotation/mount/MountPath.java:36:
>>> error: reference not found
>>> * {@link
>>>
>>> org.apache.wicket.protocol.http.request.WebRequestCodingStrategy#getMountEncoder(org.apache.wicket.IRequestTarget)}
>>> ^
>>>
>>> /home/jr/NetBeansProjects/wicketstuff-newfolderstruct/core/annotation/src/main/java/org/wicketstuff/annotation/scan/AnnotatedMountScanner.java:126:
>>> warning: no @param for pattern
>>> public List<Class<?>> getPackageMatches(String pattern)
>>> ^
>>>
>>>
>> How exactly I could reproduce this?
>> I've tried with Java 8 but m-toolchains-p correctly uses Java 7 for
>> compiling and for javadoc and there are no errors here.
>>
>>
>> [...]
>>>
>>>
>>> Is this on purpose? Or should we work-around it (solutions can be found
>>> here:
>>>
>>> http://stackoverflow.com/questions/15886209/maven-is-not-working-in-java-8-when-javadoc-tags-are-incomplete
>>> )
>>>
>>>
>>> Joachim
>>>
>>>
>>> On 08/22/2015 05:03 PM, Martin Grigorov wrote:
>>>
>>> Done.
>>>> It should be easier to port changes now!
>>>>
>>>> Martin Grigorov
>>>> Wicket Training and Consulting
>>>> https://twitter.com/mtgrigorov
>>>>
>>>> On Sat, Aug 22, 2015 at 8:47 AM, Martin Grigorov <mg...@apache.org>
>>>> wrote:
>>>>
>>>> I start working on this.
>>>>
>>>>> Please do not push to WicketStuff 6.x and master until I'm ready.
>>>>>
>>>>> Martin Grigorov
>>>>> Wicket Training and Consulting
>>>>> https://twitter.com/mtgrigorov
>>>>>
>>>>> On Sun, Aug 16, 2015 at 7:23 PM, Martin Grigorov <mgrigorov@apache.org
>>>>> >
>>>>> wrote:
>>>>>
>>>>> +1 for toolchains!
>>>>>
>>>>>>
>>>>>> I think we should start by introducing m-toolchains-p in the current
>>>>>> POMs. Just to make sure that running "mvn clean package" on the parent
>>>>>> project builds successfully all modules.
>>>>>> Then the second step is to remove jdk-1** middle modules and make the
>>>>>> flat hierarchy.
>>>>>>
>>>>>> @Joachim: do you want to do this yourself? Otherwise I may have the
>>>>>> time
>>>>>> next week
>>>>>>
>>>>>> Martin Grigorov
>>>>>> Wicket Training and Consulting
>>>>>> https://twitter.com/mtgrigorov
>>>>>>
>>>>>> On Wed, Aug 12, 2015 at 3:16 PM, Martijn Dashorst <
>>>>>> martijn.dashorst@gmail.com> wrote:
>>>>>>
>>>>>> 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 <
>>>>>>> mgrigorov@apache.org>
>>>>>>> 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 <
>>>>>>>>
>>>>>>>> mailinglist@joachimrohde.com
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>
Re: [wicketstuff] Can't we get rid of the distinction between
JDK-versions on the folder level?
Posted by Joachim Rohde <ma...@joachimrohde.com>.
I get this error when I simply run
mvn install
from the command line using the master branch.
My toolchains.xml looks like:
<?xml version="1.0" encoding="UTF8"?>
<toolchains>
<!-- JDK toolchains -->
<toolchain>
<type>jdk</type>
<provides>
<version>1.7</version>
<vendor>sun</vendor>
</provides>
<configuration>
<jdkHome>/usr/lib/jvm/java-7-openjdk-amd64</jdkHome>
</configuration>
</toolchain>
<toolchain>
<type>jdk</type>
<provides>
<version>1.8</version>
<vendor>sun</vendor>
</provides>
<configuration>
<jdkHome>/usr/lib/jvm/java-8-oracle</jdkHome>
</configuration>
</toolchain>
</toolchains>
Maybe it's a problem with OpenJDK. (Only reason I use OpenJDK 7, is the
fact, that it was still installed and before using toolchains I was not
in the need of a JDK 7).
Joachim
On 08/31/2015 07:39 PM, Martin Grigorov wrote:
> On Sun, Aug 30, 2015 at 7:57 PM, Joachim Rohde <mailinglist@joachimrohde.com
>> wrote:
>
>> Thanks for the effort, Martin. This makes things *really* easier.
>>
>> But just two small issues I encountered while compiling
>>
>> 1) I hadn't had toolchains configured on my machine so I was not able to
>> compile the project at first. I added a short paragraph in the Wiki (
>> https://github.com/wicketstuff/core/wiki#toolchains) to point this out.
>>
>> What I haven't updated is the wiki entry about the release process (
>> https://github.com/wicketstuff/core/wiki/Wicket-Stuff-Core-Release-Process
>> )
>>
>> 2) I needed to set ${javadoc.disabled} to true, to compile everything,
>> else the JavaDoc plugin would fail:
>>
>> Failed to execute goal
>> org.apache.maven.plugins:maven-javadoc-plugin:2.10.3:jar (attach-javadoc)
>> on project wicketstuff-annotation: MavenReportException: Error while
>> generating Javadoc:
>> Exit code: 1 -
>> /home/jr/NetBeansProjects/wicketstuff-newfolderstruct/core/annotation/src/main/java/org/wicketstuff/annotation/mount/MountPath.java:36:
>> error: reference not found
>> * {@link
>> org.apache.wicket.protocol.http.request.WebRequestCodingStrategy#getMountEncoder(org.apache.wicket.IRequestTarget)}
>> ^
>> /home/jr/NetBeansProjects/wicketstuff-newfolderstruct/core/annotation/src/main/java/org/wicketstuff/annotation/scan/AnnotatedMountScanner.java:126:
>> warning: no @param for pattern
>> public List<Class<?>> getPackageMatches(String pattern)
>> ^
>>
>
> How exactly I could reproduce this?
> I've tried with Java 8 but m-toolchains-p correctly uses Java 7 for
> compiling and for javadoc and there are no errors here.
>
>
>> [...]
>>
>>
>> Is this on purpose? Or should we work-around it (solutions can be found
>> here:
>> http://stackoverflow.com/questions/15886209/maven-is-not-working-in-java-8-when-javadoc-tags-are-incomplete
>> )
>>
>>
>> Joachim
>>
>>
>> On 08/22/2015 05:03 PM, Martin Grigorov wrote:
>>
>>> Done.
>>> It should be easier to port changes now!
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>> https://twitter.com/mtgrigorov
>>>
>>> On Sat, Aug 22, 2015 at 8:47 AM, Martin Grigorov <mg...@apache.org>
>>> wrote:
>>>
>>> I start working on this.
>>>> Please do not push to WicketStuff 6.x and master until I'm ready.
>>>>
>>>> Martin Grigorov
>>>> Wicket Training and Consulting
>>>> https://twitter.com/mtgrigorov
>>>>
>>>> On Sun, Aug 16, 2015 at 7:23 PM, Martin Grigorov <mg...@apache.org>
>>>> wrote:
>>>>
>>>> +1 for toolchains!
>>>>>
>>>>> I think we should start by introducing m-toolchains-p in the current
>>>>> POMs. Just to make sure that running "mvn clean package" on the parent
>>>>> project builds successfully all modules.
>>>>> Then the second step is to remove jdk-1** middle modules and make the
>>>>> flat hierarchy.
>>>>>
>>>>> @Joachim: do you want to do this yourself? Otherwise I may have the time
>>>>> next week
>>>>>
>>>>> Martin Grigorov
>>>>> Wicket Training and Consulting
>>>>> https://twitter.com/mtgrigorov
>>>>>
>>>>> On Wed, Aug 12, 2015 at 3:16 PM, Martijn Dashorst <
>>>>> martijn.dashorst@gmail.com> wrote:
>>>>>
>>>>> 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 <mg...@apache.org>
>>>>>> 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 <
>>>>>>>
>>>>>> mailinglist@joachimrohde.com
>>>>>>
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>
Re: [wicketstuff] Can't we get rid of the distinction between
JDK-versions on the folder level?
Posted by Martin Grigorov <mg...@apache.org>.
On Sun, Aug 30, 2015 at 7:57 PM, Joachim Rohde <mailinglist@joachimrohde.com
> wrote:
> Thanks for the effort, Martin. This makes things *really* easier.
>
> But just two small issues I encountered while compiling
>
> 1) I hadn't had toolchains configured on my machine so I was not able to
> compile the project at first. I added a short paragraph in the Wiki (
> https://github.com/wicketstuff/core/wiki#toolchains) to point this out.
>
> What I haven't updated is the wiki entry about the release process (
> https://github.com/wicketstuff/core/wiki/Wicket-Stuff-Core-Release-Process
> )
>
> 2) I needed to set ${javadoc.disabled} to true, to compile everything,
> else the JavaDoc plugin would fail:
>
> Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:2.10.3:jar (attach-javadoc)
> on project wicketstuff-annotation: MavenReportException: Error while
> generating Javadoc:
> Exit code: 1 -
> /home/jr/NetBeansProjects/wicketstuff-newfolderstruct/core/annotation/src/main/java/org/wicketstuff/annotation/mount/MountPath.java:36:
> error: reference not found
> * {@link
> org.apache.wicket.protocol.http.request.WebRequestCodingStrategy#getMountEncoder(org.apache.wicket.IRequestTarget)}
> ^
> /home/jr/NetBeansProjects/wicketstuff-newfolderstruct/core/annotation/src/main/java/org/wicketstuff/annotation/scan/AnnotatedMountScanner.java:126:
> warning: no @param for pattern
> public List<Class<?>> getPackageMatches(String pattern)
> ^
>
How exactly I could reproduce this?
I've tried with Java 8 but m-toolchains-p correctly uses Java 7 for
compiling and for javadoc and there are no errors here.
> [...]
>
>
> Is this on purpose? Or should we work-around it (solutions can be found
> here:
> http://stackoverflow.com/questions/15886209/maven-is-not-working-in-java-8-when-javadoc-tags-are-incomplete
> )
>
>
> Joachim
>
>
> On 08/22/2015 05:03 PM, Martin Grigorov wrote:
>
>> Done.
>> It should be easier to port changes now!
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Sat, Aug 22, 2015 at 8:47 AM, Martin Grigorov <mg...@apache.org>
>> wrote:
>>
>> I start working on this.
>>> Please do not push to WicketStuff 6.x and master until I'm ready.
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>> https://twitter.com/mtgrigorov
>>>
>>> On Sun, Aug 16, 2015 at 7:23 PM, Martin Grigorov <mg...@apache.org>
>>> wrote:
>>>
>>> +1 for toolchains!
>>>>
>>>> I think we should start by introducing m-toolchains-p in the current
>>>> POMs. Just to make sure that running "mvn clean package" on the parent
>>>> project builds successfully all modules.
>>>> Then the second step is to remove jdk-1** middle modules and make the
>>>> flat hierarchy.
>>>>
>>>> @Joachim: do you want to do this yourself? Otherwise I may have the time
>>>> next week
>>>>
>>>> Martin Grigorov
>>>> Wicket Training and Consulting
>>>> https://twitter.com/mtgrigorov
>>>>
>>>> On Wed, Aug 12, 2015 at 3:16 PM, Martijn Dashorst <
>>>> martijn.dashorst@gmail.com> wrote:
>>>>
>>>> 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 <mg...@apache.org>
>>>>> 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 <
>>>>>>
>>>>> mailinglist@joachimrohde.com
>>>>>
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
Re: [wicketstuff] Can't we get rid of the distinction between
JDK-versions on the folder level?
Posted by Martin Grigorov <ma...@gmail.com>.
I will update the release steps next time I do a release
About the javadoc issue - it is a known problem with JDK 8. Many projects
disabled javadoc lint because of this.
See Wicket-Bootstrap for example
We have to do the same for Wicketstuff
On Aug 30, 2015 7:57 PM, "Joachim Rohde" <ma...@joachimrohde.com>
wrote:
> Thanks for the effort, Martin. This makes things *really* easier.
>
> But just two small issues I encountered while compiling
>
> 1) I hadn't had toolchains configured on my machine so I was not able to
> compile the project at first. I added a short paragraph in the Wiki (
> https://github.com/wicketstuff/core/wiki#toolchains) to point this out.
>
> What I haven't updated is the wiki entry about the release process (
> https://github.com/wicketstuff/core/wiki/Wicket-Stuff-Core-Release-Process
> )
>
> 2) I needed to set ${javadoc.disabled} to true, to compile everything,
> else the JavaDoc plugin would fail:
>
> Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:2.10.3:jar (attach-javadoc)
> on project wicketstuff-annotation: MavenReportException: Error while
> generating Javadoc:
> Exit code: 1 -
> /home/jr/NetBeansProjects/wicketstuff-newfolderstruct/core/annotation/src/main/java/org/wicketstuff/annotation/mount/MountPath.java:36:
> error: reference not found
> * {@link
> org.apache.wicket.protocol.http.request.WebRequestCodingStrategy#getMountEncoder(org.apache.wicket.IRequestTarget)}
> ^
> /home/jr/NetBeansProjects/wicketstuff-newfolderstruct/core/annotation/src/main/java/org/wicketstuff/annotation/scan/AnnotatedMountScanner.java:126:
> warning: no @param for pattern
> public List<Class<?>> getPackageMatches(String pattern)
> ^
> [...]
>
>
> Is this on purpose? Or should we work-around it (solutions can be found
> here:
> http://stackoverflow.com/questions/15886209/maven-is-not-working-in-java-8-when-javadoc-tags-are-incomplete
> )
>
>
> Joachim
>
> On 08/22/2015 05:03 PM, Martin Grigorov wrote:
>
>> Done.
>> It should be easier to port changes now!
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Sat, Aug 22, 2015 at 8:47 AM, Martin Grigorov <mg...@apache.org>
>> wrote:
>>
>> I start working on this.
>>> Please do not push to WicketStuff 6.x and master until I'm ready.
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>> https://twitter.com/mtgrigorov
>>>
>>> On Sun, Aug 16, 2015 at 7:23 PM, Martin Grigorov <mg...@apache.org>
>>> wrote:
>>>
>>> +1 for toolchains!
>>>>
>>>> I think we should start by introducing m-toolchains-p in the current
>>>> POMs. Just to make sure that running "mvn clean package" on the parent
>>>> project builds successfully all modules.
>>>> Then the second step is to remove jdk-1** middle modules and make the
>>>> flat hierarchy.
>>>>
>>>> @Joachim: do you want to do this yourself? Otherwise I may have the time
>>>> next week
>>>>
>>>> Martin Grigorov
>>>> Wicket Training and Consulting
>>>> https://twitter.com/mtgrigorov
>>>>
>>>> On Wed, Aug 12, 2015 at 3:16 PM, Martijn Dashorst <
>>>> martijn.dashorst@gmail.com> wrote:
>>>>
>>>> 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 <mg...@apache.org>
>>>>> 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 <
>>>>>>
>>>>> mailinglist@joachimrohde.com
>>>>>
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
Re: [wicketstuff] Can't we get rid of the distinction between
JDK-versions on the folder level?
Posted by Joachim Rohde <ma...@joachimrohde.com>.
Thanks for the effort, Martin. This makes things *really* easier.
But just two small issues I encountered while compiling
1) I hadn't had toolchains configured on my machine so I was not able to
compile the project at first. I added a short paragraph in the Wiki
(https://github.com/wicketstuff/core/wiki#toolchains) to point this out.
What I haven't updated is the wiki entry about the release process
(https://github.com/wicketstuff/core/wiki/Wicket-Stuff-Core-Release-Process)
2) I needed to set ${javadoc.disabled} to true, to compile everything,
else the JavaDoc plugin would fail:
Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:2.10.3:jar
(attach-javadoc) on project wicketstuff-annotation:
MavenReportException: Error while generating Javadoc:
Exit code: 1 -
/home/jr/NetBeansProjects/wicketstuff-newfolderstruct/core/annotation/src/main/java/org/wicketstuff/annotation/mount/MountPath.java:36:
error: reference not found
* {@link
org.apache.wicket.protocol.http.request.WebRequestCodingStrategy#getMountEncoder(org.apache.wicket.IRequestTarget)}
^
/home/jr/NetBeansProjects/wicketstuff-newfolderstruct/core/annotation/src/main/java/org/wicketstuff/annotation/scan/AnnotatedMountScanner.java:126:
warning: no @param for pattern
public List<Class<?>> getPackageMatches(String pattern)
^
[...]
Is this on purpose? Or should we work-around it (solutions can be found
here:
http://stackoverflow.com/questions/15886209/maven-is-not-working-in-java-8-when-javadoc-tags-are-incomplete)
Joachim
On 08/22/2015 05:03 PM, Martin Grigorov wrote:
> Done.
> It should be easier to port changes now!
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Sat, Aug 22, 2015 at 8:47 AM, Martin Grigorov <mg...@apache.org>
> wrote:
>
>> I start working on this.
>> Please do not push to WicketStuff 6.x and master until I'm ready.
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Sun, Aug 16, 2015 at 7:23 PM, Martin Grigorov <mg...@apache.org>
>> wrote:
>>
>>> +1 for toolchains!
>>>
>>> I think we should start by introducing m-toolchains-p in the current
>>> POMs. Just to make sure that running "mvn clean package" on the parent
>>> project builds successfully all modules.
>>> Then the second step is to remove jdk-1** middle modules and make the
>>> flat hierarchy.
>>>
>>> @Joachim: do you want to do this yourself? Otherwise I may have the time
>>> next week
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>> https://twitter.com/mtgrigorov
>>>
>>> On Wed, Aug 12, 2015 at 3:16 PM, Martijn Dashorst <
>>> martijn.dashorst@gmail.com> wrote:
>>>
>>>> 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 <mg...@apache.org>
>>>> 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 <
>>>> mailinglist@joachimrohde.com
>>>>>> 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
>>>>
>>>
>>>
>>
>
Re: [wicketstuff] Can't we get rid of the distinction between
JDK-versions on the folder level?
Posted by Martin Grigorov <mg...@apache.org>.
Done.
It should be easier to port changes now!
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Sat, Aug 22, 2015 at 8:47 AM, Martin Grigorov <mg...@apache.org>
wrote:
> I start working on this.
> Please do not push to WicketStuff 6.x and master until I'm ready.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Sun, Aug 16, 2015 at 7:23 PM, Martin Grigorov <mg...@apache.org>
> wrote:
>
>> +1 for toolchains!
>>
>> I think we should start by introducing m-toolchains-p in the current
>> POMs. Just to make sure that running "mvn clean package" on the parent
>> project builds successfully all modules.
>> Then the second step is to remove jdk-1** middle modules and make the
>> flat hierarchy.
>>
>> @Joachim: do you want to do this yourself? Otherwise I may have the time
>> next week
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Wed, Aug 12, 2015 at 3:16 PM, Martijn Dashorst <
>> martijn.dashorst@gmail.com> wrote:
>>
>>> 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 <mg...@apache.org>
>>> 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 <
>>> mailinglist@joachimrohde.com
>>> >> 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
>>>
>>
>>
>
Re: [wicketstuff] Can't we get rid of the distinction between
JDK-versions on the folder level?
Posted by Martin Grigorov <mg...@apache.org>.
I start working on this.
Please do not push to WicketStuff 6.x and master until I'm ready.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Sun, Aug 16, 2015 at 7:23 PM, Martin Grigorov <mg...@apache.org>
wrote:
> +1 for toolchains!
>
> I think we should start by introducing m-toolchains-p in the current POMs.
> Just to make sure that running "mvn clean package" on the parent project
> builds successfully all modules.
> Then the second step is to remove jdk-1** middle modules and make the flat
> hierarchy.
>
> @Joachim: do you want to do this yourself? Otherwise I may have the time
> next week
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Wed, Aug 12, 2015 at 3:16 PM, Martijn Dashorst <
> martijn.dashorst@gmail.com> wrote:
>
>> 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 <mg...@apache.org>
>> 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 <
>> mailinglist@joachimrohde.com
>> >> 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
>>
>
>
Re: [wicketstuff] Can't we get rid of the distinction between
JDK-versions on the folder level?
Posted by Martin Grigorov <mg...@apache.org>.
+1 for toolchains!
I think we should start by introducing m-toolchains-p in the current POMs.
Just to make sure that running "mvn clean package" on the parent project
builds successfully all modules.
Then the second step is to remove jdk-1** middle modules and make the flat
hierarchy.
@Joachim: do you want to do this yourself? Otherwise I may have the time
next week
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Wed, Aug 12, 2015 at 3:16 PM, Martijn Dashorst <
martijn.dashorst@gmail.com> wrote:
> 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 <mg...@apache.org>
> 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 <
> mailinglist@joachimrohde.com
> >> 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
>
Re: [wicketstuff] Can't we get rid of the distinction between
JDK-versions on the folder level?
Posted by Martijn Dashorst <ma...@gmail.com>.
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 <mg...@apache.org> 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 <mailinglist@joachimrohde.com
>> 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
Re: [wicketstuff] Can't we get rid of the distinction between
JDK-versions on the folder level?
Posted by Martin Grigorov <mg...@apache.org>.
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 <mailinglist@joachimrohde.com
> 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
>