Re: [wicketstuff] Can't we get rid of the distinction between JDK-versions on the folder level?
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 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 >
[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: Migration to 7 report
On Mon, May 4, 2015 at 9:26 PM, Martin Grigorov wrote: > What's wrong with 'instanceof'+casting? > Nothing, except it's more verbose. I'll go do that. I was wondering if it might be worth it to add a way to define the error keys with a setter of PatternValidator. We usually override the message to make it understandable by the user (a regexp doesn't qualify as understandable for most users). Are we the only ones? If it's of some interest, I can prepare a PR for that. -- Guillaume
Re: Add IFallback marker interface to AjaxFallback* components
On May 6, 2015 3:10 PM, "Martijn Dashorst"
wrote:
>
> On Wed, May 6, 2015 at 1:35 PM, Martin Grigorov
wrote:
> > +1 to introduce IFallback
> >
> > I don't understand how Optional could help for this use case
>
> Change the onClick signature (perhaps only for Ajax fallback components):
>
> public void onClick(Optional target) {
> }
>
> This expresses clearly that target is optional, and hence that a
> fallback scenario is possible.
Yeah, but how this could be exploited in WicketTester?
>
> Martijn
>
> >
> > On Wed, May 6, 2015 at 12:03 PM, Martijn Dashorst <
> > martijn.dasho...@gmail.com> wrote:
> >
> >> The WicketTester has a click method that doesn't detect all AJAX
> >> capable links (e.g. the Ajax links in the AjaxPagingNavigator are not
> >> testable).
> >>
> >> When trying to fix this by adding support for IAjaxLink, I noticed
> >> that we also don't support AjaxFallbackButton, and probably a lot more
> >> components.
> >>
> >> Should we introduce a marker interface for fallback components?
> >>
> >> (or should we wait until Optional support arrives with Java 8 in
Wicket 8)
> >>
> >> Martijn
> >>
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: Add IFallback marker interface to AjaxFallback* components
On Wed, May 6, 2015 at 1:35 PM, Martin Grigorov wrote:
> +1 to introduce IFallback
>
> I don't understand how Optional could help for this use case
Change the onClick signature (perhaps only for Ajax fallback components):
public void onClick(Optional target) {
}
This expresses clearly that target is optional, and hence that a
fallback scenario is possible.
Martijn
>
> On Wed, May 6, 2015 at 12:03 PM, Martijn Dashorst <
> martijn.dasho...@gmail.com> wrote:
>
>> The WicketTester has a click method that doesn't detect all AJAX
>> capable links (e.g. the Ajax links in the AjaxPagingNavigator are not
>> testable).
>>
>> When trying to fix this by adding support for IAjaxLink, I noticed
>> that we also don't support AjaxFallbackButton, and probably a lot more
>> components.
>>
>> Should we introduce a marker interface for fallback components?
>>
>> (or should we wait until Optional support arrives with Java 8 in Wicket 8)
>>
>> Martijn
>>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: Add IFallback marker interface to AjaxFallback* components
+1 to introduce IFallback I don't understand how Optional could help for this use case On Wed, May 6, 2015 at 12:03 PM, Martijn Dashorst < martijn.dasho...@gmail.com> wrote: > The WicketTester has a click method that doesn't detect all AJAX > capable links (e.g. the Ajax links in the AjaxPagingNavigator are not > testable). > > When trying to fix this by adding support for IAjaxLink, I noticed > that we also don't support AjaxFallbackButton, and probably a lot more > components. > > Should we introduce a marker interface for fallback components? > > (or should we wait until Optional support arrives with Java 8 in Wicket 8) > > Martijn >
Re: wicket git commit: Added WicketTester support for IAjaxLink
Hi,
On Wed, May 6, 2015 at 12:25 PM, wrote:
> Repository: wicket
> Updated Branches:
> refs/heads/wicket-6.x e4c1d939f -> 0199bfab7
>
>
> Added WicketTester support for IAjaxLink
>
> WicketTester didn't click direct IAjaxLink implementations using an
> Ajax request but a normal request. Some components implement
> IAjaxLink directly instead of subclassing AjaxLink or other
> components.
>
> Fixes WICKET-5900
>
>
> Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
> Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/0199bfab
> Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/0199bfab
> Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/0199bfab
>
> Branch: refs/heads/wicket-6.x
> Commit: 0199bfab7cc27e14759d634a1b48f92c9e59a9d2
> Parents: e4c1d93
> Author: Martijn Dashorst
> Authored: Wed May 6 11:22:55 2015 +0200
> Committer: Martijn Dashorst
> Committed: Wed May 6 11:25:22 2015 +0200
>
> --
> .../org/apache/wicket/util/tester/BaseWicketTester.java | 11 +++
> 1 file changed, 11 insertions(+)
> --
>
>
>
> http://git-wip-us.apache.org/repos/asf/wicket/blob/0199bfab/wicket-core/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java
> --
> diff --git
> a/wicket-core/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java
> b/wicket-core/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java
> index 2849c3c..8b230b8 100644
> ---
> a/wicket-core/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java
> +++
> b/wicket-core/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java
> @@ -59,6 +59,7 @@ import org.apache.wicket.ajax.AjaxEventBehavior;
> import org.apache.wicket.ajax.form.AjaxFormSubmitBehavior;
> import org.apache.wicket.ajax.markup.html.AjaxFallbackLink;
> import org.apache.wicket.ajax.markup.html.AjaxLink;
> +import org.apache.wicket.ajax.markup.html.IAjaxLink;
> import org.apache.wicket.ajax.markup.html.form.AjaxSubmitLink;
> import org.apache.wicket.behavior.AbstractAjaxBehavior;
> import
> org.apache.wicket.core.request.handler.BookmarkablePageRequestHandler;
> @@ -1881,6 +1882,16 @@ public class BaseWicketTester
> submitAjaxFormSubmitBehavior(link,
>
> (AjaxFormSubmitBehavior)WicketTesterHelper.findAjaxEventBehavior(link,
> "onclick"));
> }
> + // if the link is an IAjaxLink, use it (do check if AJAX
> is expected)
> + else if (linkComponent instanceof IAjaxLink && isAjax)
>
I see some inconsistencies now:
1) earlier there is a check for AjaxLink that is also IAjaxLink and it has
the same logic
2) it uses fail() in the case when isAjax is false
IMO AjaxPagingNavigationLink should behave the same way. In the browser it
would not act as a **Fallback link
Maybe the code for AjaxLink and IAjaxLink should be merged?!
Additionally we can introduce IFallback marker interface (as you suggested
at dev@) and fail if isAjax is false && isFallback == false.
+ {
> + List behaviors =
> WicketTesterHelper.findAjaxEventBehaviors(
> + linkComponent, "click");
> + for (AjaxEventBehavior behavior : behaviors)
> + {
> + executeBehavior(behavior);
> + }
> + }
> /*
> * If the link is a submitlink then we pretend to have
> clicked it
> */
>
>
Re: Add IFallback marker interface to AjaxFallback* components
I would prefer the interface because Wicket 6 / 7 users should also see that components are not supported. kind regards Tobias > Am 06.05.2015 um 11:03 schrieb Martijn Dashorst : > > The WicketTester has a click method that doesn't detect all AJAX > capable links (e.g. the Ajax links in the AjaxPagingNavigator are not > testable). > > When trying to fix this by adding support for IAjaxLink, I noticed > that we also don't support AjaxFallbackButton, and probably a lot more > components. > > Should we introduce a marker interface for fallback components? > > (or should we wait until Optional support arrives with Java 8 in Wicket 8) > > Martijn
Add IFallback marker interface to AjaxFallback* components
The WicketTester has a click method that doesn't detect all AJAX capable links (e.g. the Ajax links in the AjaxPagingNavigator are not testable). When trying to fix this by adding support for IAjaxLink, I noticed that we also don't support AjaxFallbackButton, and probably a lot more components. Should we introduce a marker interface for fallback components? (or should we wait until Optional support arrives with Java 8 in Wicket 8) Martijn
