[VOTE] release wicket 1.4-rc6
I've created a release for Wicket 1.4-rc6. Until it is officially released, you can download from the following locations: SVN Tag: http://svn.apache.org/repos/asf/wicket/releases/wicket-1.4-rc6/ M2 Repo: http://people.apache.org/~ivaynberg/wicket-1.4-rc6/m2-repo/ Dist folder: http://people.apache.org/~ivaynberg/wicket-1.4-rc6/dist/ Your vote please (lasts 72h): [ ] Yes release 1.4-rc6 [ ] No, don't release it -igor Announcement: The Apache Wicket team is proud to announce the availability of the fifth release candidate for the newest version of Wicket - 1.4. A lot of bugs have been squashed and several improvements implemented. If you are already using earlier versions of 1.4, it is recommended you update to Wicket 1.4-rc6 at your earliest convenience. Eager people click here to download the distribution, others can read further: http://www.apache.org/dyn/closer.cgi/wicket/1.4-rc6 We thank you for your patience and support. - The Wicket Team Apache Wicket Apache Wicket is a component oriented Java web application framework. With proper mark-up/logic separation, a POJO data model, and a refreshing lack of XML, Apache Wicket makes developing web-apps simple and enjoyable again. Swap the boilerplate, complex debugging and brittle code for powerful, reusable components written with plain Java and HTML. You can find out more about Apache Wicket on our website: http://wicket.apache.org This release This release is the fifth release candidate for the Wicket 1.4 product. This release fixes several bugs and adds some minor improvements. You can find out about the changes at the bottom of this announcement. Migrating from 1.3 If you are coming from Wicket 1.3, you really want to read our migration guide found on the wiki: http://cwiki.apache.org/WICKET/migrate-14.html Downloading the release: You can download the release from the official Apache mirror system, and you can find it through the following link: http://www.apache.org/dyn/closer.cgi/wicket/1.4-rc6/ For the Maven and Ivy fans out there: update your pom's to the following, and everything will be downloaded automatically: dependency groupIdorg.apache.wicket/groupId artifactIdwicket/artifactId version1.4-rc6/version /dependency Substitute the artifact ID with the projects of your liking to get the other projects. Please note that we don't prescribe a Logging implementation for SLF4J. You need to specify yourself which one you prefer. Read more about SLF4J here: http://slf4j.org Validating the release The release has been signed by Jeremy Thomerson, your release manager for today. The public key can be found in the KEYS file in the download area. Download the KEYS file only from the Apache website. http://www.apache.org/dist/wicket/1.4-rc6/KEYS Instructions on how to validate the release can be found here: http://www.apache.org/dev/release-signing.html#check-integrity Reporting bugs In case you do encounter a bug, we would appreciate a report in our JIRA: http://issues.apache.org/jira/browse/WICKET The distribution In the distribution you will find a README. The README contains instructions on how to build from source yourself. You also find a CHANEGELOG-1.4 which contains a list of all things that have been fixed, added and/or removed since the 1.4 branch was created. Release Notes - Wicket - Version 1.4-RC6 ** Bug * [WICKET-1897] - StatelessForm submitted to the wrong page * [WICKET-2127] - Javascript function Wicket.replaceAll is unbearably slow * [WICKET-2202] - Form gets submitted using AjaxSubmitBehavior when sub-form has error's * [WICKET-2268] - NullPointerException NPE in DiskPageStore after Session Timeout * [WICKET-2284] - German translation for NumberValidator.minimum is wrong * [WICKET-2294] - CryptedUrlWebRequestCodingStrategy fails while decoding parameters after the app has been up and running for quite some time. * [WICKET-2325] - IChoiceRenderer generic type parameters are wrong throughout the AbstractChoice class hierarchy * [WICKET-2330] - AjaxFormSubmitBehavior throws an NullPointerException when getForm() is overridden * [WICKET-2333] - RatingPanel doesn't wrap models * [WICKET-2334] - DebugBar throws an java.lang.ExceptionInInitializerError when Tomcat is restarted * [WICKET-2335] - JavaDoc inconsistent to the code * [WICKET-2336] - JavaDoc, point out the need of a super call. * [WICKET-2341] - AbstractSingleSelectChoice nullValid javadocs are misleading. * [WICKET-2345] - ModalWindow.setResizable(false) does not work after 1.4-rc4 * [WICKET-2349] - Time.valueOf(TimeOfDay) needs to use 24 hour clock ** Improvement * [WICKET-2321] - create a Component#onRemove() method * [WICKET-2332] - Open up Markup ctor and MarkupContainer#renderNext * [WICKET-2340] - Make ModificationWatcher replacable * [WICKET-2342] - Cryptic error WicketMessage: Tag Expected when wicket:panel tags are missing * [WICKET-2343] -
Should IStringResourceLoader#loadStringResource(Class,String,Locale,String) exist?
Hi, I am writing a custom IStringResourceLoader and noticed that IStringResourceLoader#loadStringResource(Class,String,Locale,String) is not called from anywhere except from within the implementations themselves. Shall we remove the method from the interface, or did I miss other uses? Regards, Erik. -- Erik van Oosten http://day-to-day-stuff.blogspot.com
Re: Should IStringResourceLoader#loadStringResource(Class,String,Locale,String) exist?
It's part of a public interface. You can't just remove it. Maybe the internal Wicket code doesn't use it, but that doesn't mean that someone else doesn't. Where are you thinking of removing it from? A 1.4-rcx or 1.5? I'd say you probably need to deprecate it before you remove it. On Tue, Jun 30, 2009 at 6:58 AM, Erik van Oostene.vanoos...@grons.nl wrote: Hi, I am writing a custom IStringResourceLoader and noticed that IStringResourceLoader#loadStringResource(Class,String,Locale,String) is not called from anywhere except from within the implementations themselves. Shall we remove the method from the interface, or did I miss other uses? Regards, Erik. -- Erik van Oosten http://day-to-day-stuff.blogspot.com
Re: Should IStringResourceLoader#loadStringResource(Class,String,Locale,String) exist?
Yes, I understand that. However, as you typically register an implementation of IStringResourceLoader in the Application's init. It functions therefore only as a callback mechanism for Wicket itself. At least, that is how I read the intent of the code. Now I understand you are able to request the list of IStringResourceLoaders yourself and then to clever things with them. So my question actually comes down to: do we want to maintain the interface for a method that is not needed for Wicket itself? (Or are there plans to use it from within Wicket?) The deprecation route does not work. Current implementation are rightly using this method and should not get warnings because of that. Regards, Erik. On Tue, 30 Jun 2009 08:04:07 -0400, James Carman jcar...@carmanconsulting.com wrote: It's part of a public interface. You can't just remove it. Maybe the internal Wicket code doesn't use it, but that doesn't mean that someone else doesn't. Where are you thinking of removing it from? A 1.4-rcx or 1.5? I'd say you probably need to deprecate it before you remove it. On Tue, Jun 30, 2009 at 6:58 AM, Erik van Oostene.vanoos...@grons.nl wrote: Hi, I am writing a custom IStringResourceLoader and noticed that IStringResourceLoader#loadStringResource(Class,String,Locale,String) is not called from anywhere except from within the implementations themselves. Shall we remove the method from the interface, or did I miss other uses? Regards, Erik. -- Erik van Oosten http://day-to-day-stuff.blogspot.com
Re: Should IStringResourceLoader#loadStringResource(Class,String,Locale,String) exist?
On Tue, Jun 30, 2009 at 8:32 AM, Erik van Oostene.vanoos...@grons.nl wrote: The deprecation route does not work. Current implementation are rightly using this method and should not get warnings because of that. So how were you going to remove it?
Re: Should IStringResourceLoader#loadStringResource(Class,String,Locale,String) exist?
I am only talking about the declaration on the interface. Regards, Erik. On Tue, 30 Jun 2009 08:42:51 -0400, James Carman jcar...@carmanconsulting.com wrote: On Tue, Jun 30, 2009 at 8:32 AM, Erik van Oostene.vanoos...@grons.nl wrote: The deprecation route does not work. Current implementation are rightly using this method and should not get warnings because of that. So how were you going to remove it?
Re: Should IStringResourceLoader#loadStringResource(Class,String,Locale,String) exist?
On Tue, Jun 30, 2009 at 8:50 AM, Erik van Oostene.vanoos...@grons.nl wrote: I am only talking about the declaration on the interface. So, if deprecating the method on the interface would cause compiler warnings, then removing the method on the interface would cause compiler errors. Right?
Re: Should IStringResourceLoader#loadStringResource(Class,String,Locale,String) exist?
No, no warnings, the method is only referred from classes that implement
the interface and therefore continue to work after the declaration has been
removed from the interface. Those classes might have an {...@inheritdoc} on
the method in question, but that's easy to fix.
Erik.
On Tue, 30 Jun 2009 08:54:20 -0400, James Carman
jcar...@carmanconsulting.com wrote:
On Tue, Jun 30, 2009 at 8:50 AM, Erik van Oostene.vanoos...@grons.nl
wrote:
I am only talking about the declaration on the interface.
So, if deprecating the method on the interface would cause compiler
warnings, then removing the method on the interface would cause
compiler errors. Right?
Re: Should IStringResourceLoader#loadStringResource(Class,String,Locale,String) exist?
Except when you use @override annotation.
On Tuesday, June 30, 2009, Erik van Oosten e.vanoos...@grons.nl wrote:
No, no warnings, the method is only referred from classes that implement
the interface and therefore continue to work after the declaration has been
removed from the interface. Those classes might have an {...@inheritdoc} on
the method in question, but that's easy to fix.
Erik.
On Tue, 30 Jun 2009 08:54:20 -0400, James Carman
jcar...@carmanconsulting.com wrote:
On Tue, Jun 30, 2009 at 8:50 AM, Erik van Oostene.vanoos...@grons.nl
wrote:
I am only talking about the declaration on the interface.
So, if deprecating the method on the interface would cause compiler
warnings, then removing the method on the interface would cause
compiler errors. Right?
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.5 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
Re: Should IStringResourceLoader#loadStringResource(Class,String,Locale,String) exist?
Correct. So its not a thing to do for 1.4 as you will have a compile error
iff you use @Override.
Can we go back to main point now?
Regards,
Erik.
On Tue, 30 Jun 2009 15:03:31 +0200, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
Except when you use @override annotation.
On Tuesday, June 30, 2009, Erik van Oosten e.vanoos...@grons.nl wrote:
No, no warnings, the method is only referred from classes that implement
the interface and therefore continue to work after the declaration has
been
removed from the interface. Those classes might have an {...@inheritdoc} on
the method in question, but that's easy to fix.
Erik.
On Tue, 30 Jun 2009 08:54:20 -0400, James Carman
jcar...@carmanconsulting.com wrote:
On Tue, Jun 30, 2009 at 8:50 AM, Erik van Oostene.vanoos...@grons.nl
wrote:
I am only talking about the declaration on the interface.
So, if deprecating the method on the interface would cause compiler
warnings, then removing the method on the interface would cause
compiler errors. Right?
Re: Should IStringResourceLoader#loadStringResource(Class,String,Locale,String) exist?
On Tue, Jun 30, 2009 at 9:21 AM, Erik van Oostene.vanoos...@grons.nl wrote: Correct. So its not a thing to do for 1.4 as you will have a compile error iff you use @Override. Can we go back to main point now? We are discussing the main point. You're proposing removing a method from an interface in the Wicket API without deprecating it first. I'd vote for deprecation. If there is any client code out there that uses the method, then they'll be notified via the deprecation. You have an opportunity with 1.4 to deprecate it if you want. Then, remove it for 1.5.
Re: Should IStringResourceLoader#loadStringResource(Class,String,Locale,String) exist?
Right, now we are indeed discussing the main point: are there any clients
that are using this method via the interface?
In case there /are/ clients using this method, then we are basically
screwed. You can deprecate the method, but that will (temporarily) hurt the
implementations of the interface with warnings. (You also require people to
implement the full interface even though you know the method will go.) When
the method is really gone, you break backward/forward compatibility of
libraries (between version that is common for Wicket anyway).
Let us assume for a moment /no/ clients are using this method though the
interface. In this case it makes no sense to deprecate the method. We
simply remove the method declaration and fix @Override and {...@inheritdoc}
annotations in the Wicket code base.
I think the assumption is fair. Currently the interface exists solely to
let Wicket do string resource lookups. (Wicket itself does not refer to the
method via the interface.)
Anyway, from what I read in your last e-mail I think you /are/ assuming
there are clients outside of Wicket. So I guess nothing will change.
Regards,
Erik.
On Tue, 30 Jun 2009 09:52:00 -0400, James Carman
jcar...@carmanconsulting.com wrote:
On Tue, Jun 30, 2009 at 9:21 AM, Erik van Oostene.vanoos...@grons.nl
wrote:
Correct. So its not a thing to do for 1.4 as you will have a compile
error
iff you use @Override.
Can we go back to main point now?
We are discussing the main point. You're proposing removing a method
from an interface in the Wicket API without deprecating it first. I'd
vote for deprecation. If there is any client code out there that uses
the method, then they'll be notified via the deprecation. You have an
opportunity with 1.4 to deprecate it if you want. Then, remove it for
1.5.
Re: Should IStringResourceLoader#loadStringResource(Class,String,Locale,String) exist?
On Tue, Jun 30, 2009 at 11:04 AM, Erik van Oostene.vanoos...@grons.nl wrote:
Let us assume for a moment /no/ clients are using this method though the
interface. In this case it makes no sense to deprecate the method. We
simply remove the method declaration and fix @Override and {...@inheritdoc}
annotations in the Wicket code base.
I think the assumption is fair. Currently the interface exists solely to
let Wicket do string resource lookups. (Wicket itself does not refer to the
method via the interface.)
Anyway, from what I read in your last e-mail I think you /are/ assuming
there are clients outside of Wicket. So I guess nothing will change.
Right, I think your assumption is flawed. You can't be sure that
nobody is using it. There could be some crazy framework code out
there that relies on that.
Having a warning in the 1.4 code (we're fudging things a bit here by
deprecating in the 1.4 version, since it's only supposed to be about
generification) is not a big deal, IMHO.
Regards,
Erik.
On Tue, 30 Jun 2009 09:52:00 -0400, James Carman
jcar...@carmanconsulting.com wrote:
On Tue, Jun 30, 2009 at 9:21 AM, Erik van Oostene.vanoos...@grons.nl
wrote:
Correct. So its not a thing to do for 1.4 as you will have a compile
error
iff you use @Override.
Can we go back to main point now?
We are discussing the main point. You're proposing removing a method
from an interface in the Wicket API without deprecating it first. I'd
vote for deprecation. If there is any client code out there that uses
the method, then they'll be notified via the deprecation. You have an
opportunity with 1.4 to deprecate it if you want. Then, remove it for
1.5.
Re: [VOTE] release wicket 1.4-rc6
[X ] Yes release 1.4-rc6 On Tue, Jun 30, 2009 at 09:32, Igor Vaynberg igor.vaynb...@gmail.comwrote: I've created a release for Wicket 1.4-rc6. Until it is officially released, you can download from the following locations: SVN Tag: http://svn.apache.org/repos/asf/wicket/releases/wicket-1.4-rc6/ M2 Repo: http://people.apache.org/~ivaynberg/wicket-1.4-rc6/m2-repo/ Dist folder: http://people.apache.org/~ivaynberg/wicket-1.4-rc6/dist/ Your vote please (lasts 72h): [ ] No, don't release it -igor Announcement: The Apache Wicket team is proud to announce the availability of the fifth release candidate for the newest version of Wicket - 1.4. A lot of bugs have been squashed and several improvements implemented. If you are already using earlier versions of 1.4, it is recommended you update to Wicket 1.4-rc6 at your earliest convenience. Eager people click here to download the distribution, others can read further: http://www.apache.org/dyn/closer.cgi/wicket/1.4-rc6 We thank you for your patience and support. - The Wicket Team Apache Wicket Apache Wicket is a component oriented Java web application framework. With proper mark-up/logic separation, a POJO data model, and a refreshing lack of XML, Apache Wicket makes developing web-apps simple and enjoyable again. Swap the boilerplate, complex debugging and brittle code for powerful, reusable components written with plain Java and HTML. You can find out more about Apache Wicket on our website: http://wicket.apache.org This release This release is the fifth release candidate for the Wicket 1.4 product. This release fixes several bugs and adds some minor improvements. You can find out about the changes at the bottom of this announcement. Migrating from 1.3 If you are coming from Wicket 1.3, you really want to read our migration guide found on the wiki: http://cwiki.apache.org/WICKET/migrate-14.html Downloading the release: You can download the release from the official Apache mirror system, and you can find it through the following link: http://www.apache.org/dyn/closer.cgi/wicket/1.4-rc6/ For the Maven and Ivy fans out there: update your pom's to the following, and everything will be downloaded automatically: dependency groupIdorg.apache.wicket/groupId artifactIdwicket/artifactId version1.4-rc6/version /dependency Substitute the artifact ID with the projects of your liking to get the other projects. Please note that we don't prescribe a Logging implementation for SLF4J. You need to specify yourself which one you prefer. Read more about SLF4J here: http://slf4j.org Validating the release The release has been signed by Jeremy Thomerson, your release manager for today. The public key can be found in the KEYS file in the download area. Download the KEYS file only from the Apache website. http://www.apache.org/dist/wicket/1.4-rc6/KEYS Instructions on how to validate the release can be found here: http://www.apache.org/dev/release-signing.html#check-integrity Reporting bugs In case you do encounter a bug, we would appreciate a report in our JIRA: http://issues.apache.org/jira/browse/WICKET The distribution In the distribution you will find a README. The README contains instructions on how to build from source yourself. You also find a CHANEGELOG-1.4 which contains a list of all things that have been fixed, added and/or removed since the 1.4 branch was created. Release Notes - Wicket - Version 1.4-RC6 ** Bug * [WICKET-1897] - StatelessForm submitted to the wrong page * [WICKET-2127] - Javascript function Wicket.replaceAll is unbearably slow * [WICKET-2202] - Form gets submitted using AjaxSubmitBehavior when sub-form has error's * [WICKET-2268] - NullPointerException NPE in DiskPageStore after Session Timeout * [WICKET-2284] - German translation for NumberValidator.minimum is wrong * [WICKET-2294] - CryptedUrlWebRequestCodingStrategy fails while decoding parameters after the app has been up and running for quite some time. * [WICKET-2325] - IChoiceRenderer generic type parameters are wrong throughout the AbstractChoice class hierarchy * [WICKET-2330] - AjaxFormSubmitBehavior throws an NullPointerException when getForm() is overridden * [WICKET-2333] - RatingPanel doesn't wrap models * [WICKET-2334] - DebugBar throws an java.lang.ExceptionInInitializerError when Tomcat is restarted * [WICKET-2335] - JavaDoc inconsistent to the code * [WICKET-2336] - JavaDoc, point out the need of a super call. * [WICKET-2341] - AbstractSingleSelectChoice nullValid javadocs are misleading. * [WICKET-2345] - ModalWindow.setResizable(false) does not work after 1.4-rc4 * [WICKET-2349] - Time.valueOf(TimeOfDay) needs to use 24 hour clock ** Improvement * [WICKET-2321] - create a Component#onRemove() method * [WICKET-2332] - Open up Markup ctor and MarkupContainer#renderNext *
Re: [VOTE] release wicket 1.4-rc6
[X] Yes release 1.4-rc6 [ ] No, don't release it -- Jeremy Thomerson http://www.wickettraining.com
Re: [VOTE] release wicket 1.4-rc6
[X] Yes release 1.4-rc6 Juergen
Re: Should IStringResourceLoader#loadStringResource(Class,String,Locale,String) exist?
IStringResourceLoader#loadStringResource(Class,String,Locale,String) exists by purpose since we can not gurantee that we always have a Component (the other method of the interface). Via this interface you may look up the property for every class. Juergen
Re: [VOTE] release wicket 1.4-rc6
[X] Yes release 1.4-rc6 [ ] No, don't release it 2009/6/30 Jeremy Thomerson jer...@wickettraining.com: [X] Yes release 1.4-rc6 [ ] No, don't release it -- Jeremy Thomerson http://www.wickettraining.com
