subject:"\[wicketstuff\] Can't we get rid of the distinction between JDK\-versions on the folder level\?"

Re: [wicketstuff] Can't we get rid of the distinction between JDK-versions on the folder level?

2015-09-02 Thread Maxim Solodovnik

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 
wrote:

> On Mon, Aug 31, 2015 at 10:16 PM, Joachim Rohde <
> mailingl...@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:
> >
> > 
> > 
> >   
> >   
> > jdk
> > 
> >   1.7
> >   sun
> > 
> > 
> >   /usr/lib/jvm/java-7-openjdk-amd64
> > 
> >   
> >   
> > jdk
> > 
> >   1.8
> >   sun
> > 
> > 
> >   /usr/lib/jvm/java-8-oracle
> > 
> >   
> >
> > 
> >
> > 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 <
> >> mailingl...@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 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 <
> mgrigo...@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 <
> mgrigo...@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.dasho...@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,

Re: [wicketstuff] Can't we get rid of the distinction between JDK-versions on the folder level?

2015-08-31 Thread Martin Grigorov

On Sun, Aug 30, 2015 at 7:57 PM, Joachim Rohde  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 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 
>> 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 
>>> 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.dasho...@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 
> 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 <
>>
> mailingl...@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

Re: [wicketstuff] Can't we get rid of the distinction between JDK-versions on the folder level?

2015-08-31 Thread Joachim Rohde

I get this error when I simply run

mvn install

from the command line using the master branch.

My toolchains.xml looks like:

jdk

1.7
sun

/usr/lib/jvm/java-7-openjdk-amd64

jdk

1.8
sun

/usr/lib/jvm/java-8-oracle

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 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
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
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.dasho...@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
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?

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 <

mailingl...@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

changes due to a different folder structure. Since this was really a

pain

in the neck (and quite

Re: [wicketstuff] Can't we get rid of the distinction between JDK-versions on the folder level?

2015-08-31 Thread Martin Grigorov

On Mon, Aug 31, 2015 at 10:16 PM, Joachim Rohde <
mailingl...@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:
>
> 
> 
>   
>   
> jdk
> 
>   1.7
>   sun
> 
> 
>   /usr/lib/jvm/java-7-openjdk-amd64
> 
>   
>   
> jdk
> 
>   1.8
>   sun
> 
> 
>   /usr/lib/jvm/java-8-oracle
> 
>   
>
> 
>
> 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 <
>> mailingl...@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 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 
 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  >
> 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.dasho...@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 <
>>> mgrigo...@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

Re: [wicketstuff] Can't we get rid of the distinction between JDK-versions on the folder level?

2015-08-30 Thread Joachim Rohde

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 ListClass? 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 mgrigo...@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 mgrigo...@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.dasho...@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 mgrigo...@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?

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

mailingl...@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

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.

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.

is the

fact, that you cannot recognize at a first

Re: [wicketstuff] Can't we get rid of the distinction between JDK-versions on the folder level?

2015-08-22 Thread Martin Grigorov

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 mgrigo...@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.dasho...@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 mgrigo...@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?

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
mailingl...@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?

2015-08-22 Thread Martin Grigorov

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 mgrigo...@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 mgrigo...@apache.org
wrote:

+1 for toolchains!

@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.dasho...@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 mgrigo...@apache.org
wrote:
Hi Joachim,

I think it should work.
Do you want to try it out?

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
mailingl...@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?

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?

2015-07-31 Thread Joachim Rohde

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
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.7/source
target1.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
groupIdorg.codehaus.mojo/groupId
artifactIdanimal-sniffer-maven-plugin/artifactId

executions
execution
idcheck-java-version/id
phasecompile/phase
goals
goalcheck/goal
/goals
configuration
signature

groupIdorg.codehaus.mojo.signature/groupId
artifactIdjava17/artifactId
version1.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
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.8/source
target1.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
groupIdorg.codehaus.mojo/groupId
artifactIdanimal-sniffer-maven-plugin/artifactId

executions
execution
idcheck-java-version/id
phasecompile/phase
goals
goalcheck/goal
/goals
configuration
signature

groupIdcom.ianbrandt.maven.signature/groupId
artifactIdjava1.8/artifactId
version1.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,

Re: [wicketstuff] Can't we get rid of the distinction between JDK-versions on the folder level?

2015-06-20 Thread Martin Grigorov

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 mailingl...@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
mailingl...@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,

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?

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
mailingl...@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.

Joachim

Re: [wicketstuff] Can't we get rid of the distinction between JDK-versions on the folder level?

2015-05-17 Thread Martin Grigorov

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
mailingl...@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?

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
mailingl...@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.

Joachim

Re: [wicketstuff] Can't we get rid of the distinction between JDK-versions on the folder level?

2015-05-07 Thread Martin Grigorov

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 mailingl...@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.

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

[wicketstuff] Can't we get rid of the distinction between JDK-versions on the folder level?

2015-05-06 Thread Joachim Rohde

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.

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?

Re: [wicketstuff] Can't we get rid of the distinction between JDK-versions on the folder level?

Re: [wicketstuff] Can't we get rid of the distinction between JDK-versions on the folder level?

Re: [wicketstuff] Can't we get rid of the distinction between JDK-versions on the folder level?

Re: [wicketstuff] Can't we get rid of the distinction between JDK-versions on the folder level?

Re: [wicketstuff] Can't we get rid of the distinction between JDK-versions on the folder level?

Re: [wicketstuff] Can't we get rid of the distinction between JDK-versions on the folder level?

Re: [wicketstuff] Can't we get rid of the distinction between JDK-versions on the folder level?

Re: [wicketstuff] Can't we get rid of the distinction between JDK-versions on the folder level?

Re: [wicketstuff] Can't we get rid of the distinction between JDK-versions on the folder level?

Re: [wicketstuff] Can't we get rid of the distinction between JDK-versions on the folder level?

[wicketstuff] Can't we get rid of the distinction between JDK-versions on the folder level?

12 matches

Site Navigation

Mail list logo

Footer information