Re: New hudson server reveals java 6 isms in some wicketstuff-core projects
May help : !-- make sure our code doesn't have 1.6 dependencies except where we know it see * http://mojo.codehaus.org/animal-sniffer/index.html * http://weblogs.java.net/blog/kohsuke/archive/2008/11/compiling_with.html -- groupIdorg.codehaus.mojo/groupId artifactIdanimal-sniffer-maven-plugin/artifactId version1.5/version configuration signature groupIdorg.codehaus.mojo.signature/groupId artifactIdjava15/artifactId version1.0/version /signature /configuration /plugin On Fri, Jul 23, 2010 at 05:28, Michael O'Cleirigh michael.ocleir...@rivulet.ca wrote: Hello, The hudson server I had running used Java 6 for some internal projects and I was relying on the maven compiler plugin to ensure that the wicketstuff-core projects were built in a way compatible with Java 5. With the switch to the wicketstuff.org based hudson a 1.5 JDK is being used for building and it has revealed issues in a few of the modules that use Java 6 features that break the build. According to this question the java 6 JDK is buggy in this regard and is probably not generating valid java 5 class files: http://stackoverflow.com/questions/1193184/does-maven-really-honor-the-source-tag-in-the-compiler-plugin I think its likely that the wicketstuff-core releases and snapshots that I've been building are not 100% java 5 compatible. What I am thinking is that a separate maven project tree needs to be created that can be build the java 6 projects using the java 6 JDK. This is the structure I am envisaging: /trunk/ wicketstuff-core/ this is the existing project tree (or maybe it should be refactored to wicketstuff-core-java5 for consistency) wicketstuff-core-java6/ this is the project tree for java6 projects The wicketstuff-core-java6/pom.xml would declare a parent of wicketstuff-core/pom.xml but would override the maven compiler plugin for 1.6 instead of 1.5. Hudson would have a separate builder for the java6 projects that would use the java 6 JDK. I think the groupID and artifactID's can remain the same with this approach and it would decouple from any version change with wicket 1.5 as projects could migrate to the java6 tree as required. Some of the project problems are: 1. @Override annotation on interface implementing method (invalid in java 5 default in java 6) 2. Inclusion of Java 6 compiled dependencies (class file has wrong version 50.0, should be 49.0) 3. Use of Java 6 API like string.isEmpty() method. Once we figure out how to handle java5 vs java6 I will create a 1.4.9.3 release to make things 100% compatible. Regards, Mike
Re: remove oninitialize/onconfigure from 1.4.x?
we (servoy) dont care much about those changes, they can be left in (we dont use it and they also dont give us a problem (after my fix ;) ) the only problem is by the way onInitialize and onConfigure() Because initialize and also doInitialize() are package scope so they are not a problem as far as i know... for example doinitialize() is final but a subclass of component in another package can just create such a method just fine... configure() you made public final.. i think we just should do the same, make it package scope final... then that method shouldnt also be a big problem. The it is just the 2 overridable protected methods onInitialize and onConfigure johan On Thu, Jul 22, 2010 at 19:33, Igor Vaynberg igor.vaynb...@gmail.com wrote: i just thought of something, i added oninitialize and onconfigure features to 1.4.x as well as trunk, but they can create an incompatibility for 1.4.x users if they have declared a method on their components with the same name. impacted method names are component#configure(), onConfigure(), initialize(), onInitialize(). should we remove these features from 1.4.x to remove the chance of an incompatibility? -igor
Re: remove oninitialize/onconfigure from 1.4.x?
+1 for Johan's changes to make the surface area of the change smaller. I didn't find onInitialize and onConfigure in our code base as well. The benefits are evident. So that is +0 from me to keep them in. Pushing them to only 1.5 ensures we get enough folks trying 1.5 though :) Martijn On Fri, Jul 23, 2010 at 10:38 AM, Johan Compagner jcompag...@gmail.com wrote: we (servoy) dont care much about those changes, they can be left in (we dont use it and they also dont give us a problem (after my fix ;) ) the only problem is by the way onInitialize and onConfigure() Because initialize and also doInitialize() are package scope so they are not a problem as far as i know... for example doinitialize() is final but a subclass of component in another package can just create such a method just fine... configure() you made public final.. i think we just should do the same, make it package scope final... then that method shouldnt also be a big problem. The it is just the 2 overridable protected methods onInitialize and onConfigure johan On Thu, Jul 22, 2010 at 19:33, Igor Vaynberg igor.vaynb...@gmail.com wrote: i just thought of something, i added oninitialize and onconfigure features to 1.4.x as well as trunk, but they can create an incompatibility for 1.4.x users if they have declared a method on their components with the same name. impacted method names are component#configure(), onConfigure(), initialize(), onInitialize(). should we remove these features from 1.4.x to remove the chance of an incompatibility? -igor -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8
Re: remove oninitialize/onconfigure from 1.4.x?
I'm also +1 to keep them in 1.4. Addition of new code is not exactly backward incompatible change. The names of the methods are common so the chance of clash is bigger but still there is such chance with any other addition. On Fri, Jul 23, 2010 at 10:50 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: +1 for Johan's changes to make the surface area of the change smaller. I didn't find onInitialize and onConfigure in our code base as well. The benefits are evident. So that is +0 from me to keep them in. Pushing them to only 1.5 ensures we get enough folks trying 1.5 though :) Martijn On Fri, Jul 23, 2010 at 10:38 AM, Johan Compagner jcompag...@gmail.com wrote: we (servoy) dont care much about those changes, they can be left in (we dont use it and they also dont give us a problem (after my fix ;) ) the only problem is by the way onInitialize and onConfigure() Because initialize and also doInitialize() are package scope so they are not a problem as far as i know... for example doinitialize() is final but a subclass of component in another package can just create such a method just fine... configure() you made public final.. i think we just should do the same, make it package scope final... then that method shouldnt also be a big problem. The it is just the 2 overridable protected methods onInitialize and onConfigure johan On Thu, Jul 22, 2010 at 19:33, Igor Vaynberg igor.vaynb...@gmail.com wrote: i just thought of something, i added oninitialize and onconfigure features to 1.4.x as well as trunk, but they can create an incompatibility for 1.4.x users if they have declared a method on their components with the same name. impacted method names are component#configure(), onConfigure(), initialize(), onInitialize(). should we remove these features from 1.4.x to remove the chance of an incompatibility? -igor -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8
Re: remove oninitialize/onconfigure from 1.4.x?
Which is why it is rather inadvisable. This way it is not a drop-in release, which we usually promise (unless a security issue or blocker forces us to forego binary compatibility) However, I do think that the benefit of having these methods available now are significant. Martijn On Fri, Jul 23, 2010 at 12:21 PM, Martin Grigorov mgrigo...@apache.org wrote: I'm also +1 to keep them in 1.4. Addition of new code is not exactly backward incompatible change. The names of the methods are common so the chance of clash is bigger but still there is such chance with any other addition. On Fri, Jul 23, 2010 at 10:50 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: +1 for Johan's changes to make the surface area of the change smaller. I didn't find onInitialize and onConfigure in our code base as well. The benefits are evident. So that is +0 from me to keep them in. Pushing them to only 1.5 ensures we get enough folks trying 1.5 though :) Martijn On Fri, Jul 23, 2010 at 10:38 AM, Johan Compagner jcompag...@gmail.com wrote: we (servoy) dont care much about those changes, they can be left in (we dont use it and they also dont give us a problem (after my fix ;) ) the only problem is by the way onInitialize and onConfigure() Because initialize and also doInitialize() are package scope so they are not a problem as far as i know... for example doinitialize() is final but a subclass of component in another package can just create such a method just fine... configure() you made public final.. i think we just should do the same, make it package scope final... then that method shouldnt also be a big problem. The it is just the 2 overridable protected methods onInitialize and onConfigure johan On Thu, Jul 22, 2010 at 19:33, Igor Vaynberg igor.vaynb...@gmail.com wrote: i just thought of something, i added oninitialize and onconfigure features to 1.4.x as well as trunk, but they can create an incompatibility for 1.4.x users if they have declared a method on their components with the same name. impacted method names are component#configure(), onConfigure(), initialize(), onInitialize(). should we remove these features from 1.4.x to remove the chance of an incompatibility? -igor -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8 -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8
Contributing to Wicket
Dear Wicket team, as I'm using wicket for some time now, I would like to contribute back to the community. An additional motivation is getting to know the insides of Wicket better - and the best way I can imagine is by working on Wicket itself. :-) I have looked at the list of open issues in JIRA and found some that seem to be easy to fix. This seems to be a good starting point for me. What are your procedures for letting me submit changes / patches? Is there a link pointing to a description of building Wicket from source (/contribute/building-from-svn.html on wicket.apache.org is broken - and yes, I did a forced reload of the page :-) Cheers, Erich
Re: Contributing to Wicket
On Fri, Jul 23, 2010 at 1:53 PM, James Carman ja...@carmanconsulting.com wrote: Attach some patches to the JIRAs. Unified diff is preferred, and be sure to tick the Allow for inclusion button. If you're getting serious you can make life for us easier, especially with larger contributions by submitting an ICLA to the secretary of The ASF: http://www.apache.org/licenses/icla.txt Martijn On Fri, Jul 23, 2010 at 7:50 AM, Erich W Schreiner eschrei...@yahoo.com wrote: Dear Wicket team, as I'm using wicket for some time now, I would like to contribute back to the community. An additional motivation is getting to know the insides of Wicket better - and the best way I can imagine is by working on Wicket itself. :-) I have looked at the list of open issues in JIRA and found some that seem to be easy to fix. This seems to be a good starting point for me. What are your procedures for letting me submit changes / patches? Is there a link pointing to a description of building Wicket from source (/contribute/building-from-svn.html on wicket.apache.org is broken - and yes, I did a forced reload of the page :-) Cheers, Erich -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8
Re: remove oninitialize/onconfigure from 1.4.x?
Hi Johan, actually it is 2 overridable protected methods that can execute an rule already implemented by some custom component. I attached an test to via Jira site showing the possible problem. https://issues.apache.org/jira/browse/WICKET-2960 On Fri, Jul 23, 2010 at 5:38 AM, Johan Compagner jcompag...@gmail.comwrote: we (servoy) dont care much about those changes, they can be left in (we dont use it and they also dont give us a problem (after my fix ;) ) the only problem is by the way onInitialize and onConfigure() Because initialize and also doInitialize() are package scope so they are not a problem as far as i know... for example doinitialize() is final but a subclass of component in another package can just create such a method just fine... configure() you made public final.. i think we just should do the same, make it package scope final... then that method shouldnt also be a big problem. The it is just the 2 overridable protected methods onInitialize and onConfigure johan On Thu, Jul 22, 2010 at 19:33, Igor Vaynberg igor.vaynb...@gmail.com wrote: i just thought of something, i added oninitialize and onconfigure features to 1.4.x as well as trunk, but they can create an incompatibility for 1.4.x users if they have declared a method on their components with the same name. impacted method names are component#configure(), onConfigure(), initialize(), onInitialize(). should we remove these features from 1.4.x to remove the chance of an incompatibility? -igor -- Pedro Henrique Oliveira dos Santos
Re: remove oninitialize/onconfigure from 1.4.x?
yes if you use the package org.apache.wicket!!! But that is something i definitely dont see as a problem because you shouldnt do that. org.apache.wicket is the package of wicket itself (just like java.lang is of java itself) johan On Fri, Jul 23, 2010 at 14:02, Pedro Santos pedros...@gmail.com wrote: Hi Johan, actually it is 2 overridable protected methods that can execute an rule already implemented by some custom component. I attached an test to via Jira site showing the possible problem. https://issues.apache.org/jira/browse/WICKET-2960 On Fri, Jul 23, 2010 at 5:38 AM, Johan Compagner jcompag...@gmail.comwrote: we (servoy) dont care much about those changes, they can be left in (we dont use it and they also dont give us a problem (after my fix ;) ) the only problem is by the way onInitialize and onConfigure() Because initialize and also doInitialize() are package scope so they are not a problem as far as i know... for example doinitialize() is final but a subclass of component in another package can just create such a method just fine... configure() you made public final.. i think we just should do the same, make it package scope final... then that method shouldnt also be a big problem. The it is just the 2 overridable protected methods onInitialize and onConfigure johan On Thu, Jul 22, 2010 at 19:33, Igor Vaynberg igor.vaynb...@gmail.com wrote: i just thought of something, i added oninitialize and onconfigure features to 1.4.x as well as trunk, but they can create an incompatibility for 1.4.x users if they have declared a method on their components with the same name. impacted method names are component#configure(), onConfigure(), initialize(), onInitialize(). should we remove these features from 1.4.x to remove the chance of an incompatibility? -igor -- Pedro Henrique Oliveira dos Santos
Re: remove oninitialize/onconfigure from 1.4.x?
Good point, I used an test case that was in the same package that the component, what invalidate the test. But the described problem remains. I attached in the Jira another test case, in another package... On Fri, Jul 23, 2010 at 9:06 AM, Johan Compagner jcompag...@gmail.comwrote: yes if you use the package org.apache.wicket!!! But that is something i definitely dont see as a problem because you shouldnt do that. org.apache.wicket is the package of wicket itself (just like java.lang is of java itself) johan On Fri, Jul 23, 2010 at 14:02, Pedro Santos pedros...@gmail.com wrote: Hi Johan, actually it is 2 overridable protected methods that can execute an rule already implemented by some custom component. I attached an test to via Jira site showing the possible problem. https://issues.apache.org/jira/browse/WICKET-2960 On Fri, Jul 23, 2010 at 5:38 AM, Johan Compagner jcompag...@gmail.com wrote: we (servoy) dont care much about those changes, they can be left in (we dont use it and they also dont give us a problem (after my fix ;) ) the only problem is by the way onInitialize and onConfigure() Because initialize and also doInitialize() are package scope so they are not a problem as far as i know... for example doinitialize() is final but a subclass of component in another package can just create such a method just fine... configure() you made public final.. i think we just should do the same, make it package scope final... then that method shouldnt also be a big problem. The it is just the 2 overridable protected methods onInitialize and onConfigure johan On Thu, Jul 22, 2010 at 19:33, Igor Vaynberg igor.vaynb...@gmail.com wrote: i just thought of something, i added oninitialize and onconfigure features to 1.4.x as well as trunk, but they can create an incompatibility for 1.4.x users if they have declared a method on their components with the same name. impacted method names are component#configure(), onConfigure(), initialize(), onInitialize(). should we remove these features from 1.4.x to remove the chance of an incompatibility? -igor -- Pedro Henrique Oliveira dos Santos -- Pedro Henrique Oliveira dos Santos
Re: remove oninitialize/onconfigure from 1.4.x?
And that test just tells us what we already know and that if they have onInitialize() or onConfigure() that those are the problem. On Fri, Jul 23, 2010 at 14:22, Pedro Santos pedros...@gmail.com wrote: Good point, I used an test case that was in the same package that the component, what invalidate the test. But the described problem remains. I attached in the Jira another test case, in another package... On Fri, Jul 23, 2010 at 9:06 AM, Johan Compagner jcompag...@gmail.comwrote: yes if you use the package org.apache.wicket!!! But that is something i definitely dont see as a problem because you shouldnt do that. org.apache.wicket is the package of wicket itself (just like java.lang is of java itself) johan On Fri, Jul 23, 2010 at 14:02, Pedro Santos pedros...@gmail.com wrote: Hi Johan, actually it is 2 overridable protected methods that can execute an rule already implemented by some custom component. I attached an test to via Jira site showing the possible problem. https://issues.apache.org/jira/browse/WICKET-2960 On Fri, Jul 23, 2010 at 5:38 AM, Johan Compagner jcompag...@gmail.com wrote: we (servoy) dont care much about those changes, they can be left in (we dont use it and they also dont give us a problem (after my fix ;) ) the only problem is by the way onInitialize and onConfigure() Because initialize and also doInitialize() are package scope so they are not a problem as far as i know... for example doinitialize() is final but a subclass of component in another package can just create such a method just fine... configure() you made public final.. i think we just should do the same, make it package scope final... then that method shouldnt also be a big problem. The it is just the 2 overridable protected methods onInitialize and onConfigure johan On Thu, Jul 22, 2010 at 19:33, Igor Vaynberg igor.vaynb...@gmail.com wrote: i just thought of something, i added oninitialize and onconfigure features to 1.4.x as well as trunk, but they can create an incompatibility for 1.4.x users if they have declared a method on their components with the same name. impacted method names are component#configure(), onConfigure(), initialize(), onInitialize(). should we remove these features from 1.4.x to remove the chance of an incompatibility? -igor -- Pedro Henrique Oliveira dos Santos -- Pedro Henrique Oliveira dos Santos
Re: remove oninitialize/onconfigure from 1.4.x?
Definitely +1 from me for keeping these methods in 1.4.x, with the additional scope-narrowing changes from Johan. Good ideas! These new methods will make some things much easier for us. I'm not sure how quickly we could move to 1.5 once it comes out. On a related note, is there any documentation on what is changing between 1.4.x and 1.5, both on the surface and internally? Thanks Carl-Eric -- Carl-Eric Menzel http://www.wicketbuch.de/ On Fri, 23 Jul 2010 10:38:47 +0200 Johan Compagner jcompag...@gmail.com wrote: we (servoy) dont care much about those changes, they can be left in (we dont use it and they also dont give us a problem (after my fix ;) ) the only problem is by the way onInitialize and onConfigure() Because initialize and also doInitialize() are package scope so they are not a problem as far as i know... for example doinitialize() is final but a subclass of component in another package can just create such a method just fine... configure() you made public final.. i think we just should do the same, make it package scope final... then that method shouldnt also be a big problem. The it is just the 2 overridable protected methods onInitialize and onConfigure johan On Thu, Jul 22, 2010 at 19:33, Igor Vaynberg igor.vaynb...@gmail.com wrote: i just thought of something, i added oninitialize and onconfigure features to 1.4.x as well as trunk, but they can create an incompatibility for 1.4.x users if they have declared a method on their components with the same name. impacted method names are component#configure(), onConfigure(), initialize(), onInitialize(). should we remove these features from 1.4.x to remove the chance of an incompatibility? -igor
Re: remove oninitialize/onconfigure from 1.4.x?
https://cwiki.apache.org/WICKET/migration-to-wicket-15.html On Fri, Jul 23, 2010 at 2:38 PM, Carl-Eric Menzel cmen...@wicketbuch.dewrote: Definitely +1 from me for keeping these methods in 1.4.x, with the additional scope-narrowing changes from Johan. Good ideas! These new methods will make some things much easier for us. I'm not sure how quickly we could move to 1.5 once it comes out. On a related note, is there any documentation on what is changing between 1.4.x and 1.5, both on the surface and internally? Thanks Carl-Eric -- Carl-Eric Menzel http://www.wicketbuch.de/ On Fri, 23 Jul 2010 10:38:47 +0200 Johan Compagner jcompag...@gmail.com wrote: we (servoy) dont care much about those changes, they can be left in (we dont use it and they also dont give us a problem (after my fix ;) ) the only problem is by the way onInitialize and onConfigure() Because initialize and also doInitialize() are package scope so they are not a problem as far as i know... for example doinitialize() is final but a subclass of component in another package can just create such a method just fine... configure() you made public final.. i think we just should do the same, make it package scope final... then that method shouldnt also be a big problem. The it is just the 2 overridable protected methods onInitialize and onConfigure johan On Thu, Jul 22, 2010 at 19:33, Igor Vaynberg igor.vaynb...@gmail.com wrote: i just thought of something, i added oninitialize and onconfigure features to 1.4.x as well as trunk, but they can create an incompatibility for 1.4.x users if they have declared a method on their components with the same name. impacted method names are component#configure(), onConfigure(), initialize(), onInitialize(). should we remove these features from 1.4.x to remove the chance of an incompatibility? -igor
Re: Contributing to Wicket
Dear team, I have submitted a patch for https://issues.apache.org/jira/browse/WICKET-2812 Please verify the format of the patch and let me know if I can improve on it. Cheers, Erich PS: I've also mailed the ICLA to the secretary. From: Martijn Dashorst martijn.dasho...@gmail.com To: dev@wicket.apache.org Sent: Fri, July 23, 2010 1:56:45 PM Subject: Re: Contributing to Wicket On Fri, Jul 23, 2010 at 1:53 PM, James Carman ja...@carmanconsulting.com wrote: Attach some patches to the JIRAs. Unified diff is preferred, and be sure to tick the Allow for inclusion button. If you're getting serious you can make life for us easier, especially with larger contributions by submitting an ICLA to the secretary of The ASF: http://www.apache.org/licenses/icla.txt Martijn On Fri, Jul 23, 2010 at 7:50 AM, Erich W Schreiner eschrei...@yahoo.com wrote: Dear Wicket team, as I'm using wicket for some time now, I would like to contribute back to the community. An additional motivation is getting to know the insides of Wicket better - and the best way I can imagine is by working on Wicket itself. :-) I have looked at the list of open issues in JIRA and found some that seem to be easy to fix. This seems to be a good starting point for me. What are your procedures for letting me submit changes / patches? Is there a link pointing to a description of building Wicket from source (/contribute/building-from-svn.html on wicket.apache.org is broken - and yes, I did a forced reload of the page :-) Cheers, Erich -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8
Re: remove oninitialize/onconfigure from 1.4.x?
Great, thanks! On Fri, 23 Jul 2010 14:55:06 +0200 Martin Grigorov mgrigo...@apache.org wrote: https://cwiki.apache.org/WICKET/migration-to-wicket-15.html On Fri, Jul 23, 2010 at 2:38 PM, Carl-Eric Menzel cmen...@wicketbuch.dewrote: Definitely +1 from me for keeping these methods in 1.4.x, with the additional scope-narrowing changes from Johan. Good ideas! These new methods will make some things much easier for us. I'm not sure how quickly we could move to 1.5 once it comes out. On a related note, is there any documentation on what is changing between 1.4.x and 1.5, both on the surface and internally? Thanks Carl-Eric -- Carl-Eric Menzel http://www.wicketbuch.de/ On Fri, 23 Jul 2010 10:38:47 +0200 Johan Compagner jcompag...@gmail.com wrote: we (servoy) dont care much about those changes, they can be left in (we dont use it and they also dont give us a problem (after my fix ;) ) the only problem is by the way onInitialize and onConfigure() Because initialize and also doInitialize() are package scope so they are not a problem as far as i know... for example doinitialize() is final but a subclass of component in another package can just create such a method just fine... configure() you made public final.. i think we just should do the same, make it package scope final... then that method shouldnt also be a big problem. The it is just the 2 overridable protected methods onInitialize and onConfigure johan On Thu, Jul 22, 2010 at 19:33, Igor Vaynberg igor.vaynb...@gmail.com wrote: i just thought of something, i added oninitialize and onconfigure features to 1.4.x as well as trunk, but they can create an incompatibility for 1.4.x users if they have declared a method on their components with the same name. impacted method names are component#configure(), onConfigure(), initialize(), onInitialize(). should we remove these features from 1.4.x to remove the chance of an incompatibility? -igor
Re: remove oninitialize/onconfigure from 1.4.x?
since this has turned into more of a vote should we take it to the user list so we get a wider range of responses? -igor On Fri, Jul 23, 2010 at 1:50 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: +1 for Johan's changes to make the surface area of the change smaller. I didn't find onInitialize and onConfigure in our code base as well. The benefits are evident. So that is +0 from me to keep them in. Pushing them to only 1.5 ensures we get enough folks trying 1.5 though :) Martijn On Fri, Jul 23, 2010 at 10:38 AM, Johan Compagner jcompag...@gmail.com wrote: we (servoy) dont care much about those changes, they can be left in (we dont use it and they also dont give us a problem (after my fix ;) ) the only problem is by the way onInitialize and onConfigure() Because initialize and also doInitialize() are package scope so they are not a problem as far as i know... for example doinitialize() is final but a subclass of component in another package can just create such a method just fine... configure() you made public final.. i think we just should do the same, make it package scope final... then that method shouldnt also be a big problem. The it is just the 2 overridable protected methods onInitialize and onConfigure johan On Thu, Jul 22, 2010 at 19:33, Igor Vaynberg igor.vaynb...@gmail.com wrote: i just thought of something, i added oninitialize and onconfigure features to 1.4.x as well as trunk, but they can create an incompatibility for 1.4.x users if they have declared a method on their components with the same name. impacted method names are component#configure(), onConfigure(), initialize(), onInitialize(). should we remove these features from 1.4.x to remove the chance of an incompatibility? -igor -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8
Re: Contributing to Wicket
format is good, patch applied. thanks. -igor On Fri, Jul 23, 2010 at 6:29 AM, Erich W Schreiner eschrei...@yahoo.com wrote: Dear team, I have submitted a patch for https://issues.apache.org/jira/browse/WICKET-2812 Please verify the format of the patch and let me know if I can improve on it. Cheers, Erich PS: I've also mailed the ICLA to the secretary. From: Martijn Dashorst martijn.dasho...@gmail.com To: dev@wicket.apache.org Sent: Fri, July 23, 2010 1:56:45 PM Subject: Re: Contributing to Wicket On Fri, Jul 23, 2010 at 1:53 PM, James Carman ja...@carmanconsulting.com wrote: Attach some patches to the JIRAs. Unified diff is preferred, and be sure to tick the Allow for inclusion button. If you're getting serious you can make life for us easier, especially with larger contributions by submitting an ICLA to the secretary of The ASF: http://www.apache.org/licenses/icla.txt Martijn On Fri, Jul 23, 2010 at 7:50 AM, Erich W Schreiner eschrei...@yahoo.com wrote: Dear Wicket team, as I'm using wicket for some time now, I would like to contribute back to the community. An additional motivation is getting to know the insides of Wicket better - and the best way I can imagine is by working on Wicket itself. :-) I have looked at the list of open issues in JIRA and found some that seem to be easy to fix. This seems to be a good starting point for me. What are your procedures for letting me submit changes / patches? Is there a link pointing to a description of building Wicket from source (/contribute/building-from-svn.html on wicket.apache.org is broken - and yes, I did a forced reload of the page :-) Cheers, Erich -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8
