On Sun, Mar 23, 2008 at 5:47 PM, Johan Compagner <[EMAIL PROTECTED]> wrote:
> hmm for 1.3 i will test it that i will always just give a cloned version
> Then we can keep the map and the method just fine.
>
> That fix is fine by me then
>
That sounds like it will work. I don't know what would be
hmm for 1.3 i will test it that i will always just give a cloned version
Then we can keep the map and the method just fine.
That fix is fine by me then
johan
On Sun, Mar 23, 2008 at 6:48 PM, James Carman <[EMAIL PROTECTED]>
wrote:
> NumberFormat objects are cloneable. So, maybe you could use
hmm
i am really not a fan for also using thread locals for that
Then we have to use a threadlocal map that hold per locale a number format..
I dont know if clone is really faster then just new (ok the parsing doesn't
have to happen then)
Then i could keep the map and always return a cloned versio
I dont think 1.4 will be a drop in replacement for 1.3
there are fixes that break stuff.
So a rebuild/compile is i think really needed
But that shouldn't be to much of a problem
But i dont think there will be anybody that will drop in 1.4 jar in a
production system that is now on 1.3.x..
I guess
[ ] do it for 1.3
[ x ] do it for 1.4
Otherwise before you know we'll get on that slippery slope again of
what is important enough to warrant a break on a current release and
what is not.
Eelco
[ ] remove the map and the method for 1.3
[ x ] remove the map and the method for 1.4
I don't think users benefit much from being able to set the formatter
directly anyway.
Eelco
NumberFormat objects are cloneable. So, maybe you could use the
format passed in to setNumberFormat() as a "prototype" to create one
for the current thread/invocation (I don't know if you use thread
locals for this or not)?
On Sun, Mar 23, 2008 at 11:43 AM, Johan Compagner <[EMAIL PROTECTED]> wro
hrm. but what would happen if you run the jar through
retrotranslator/weaver. it should make it compatible again... at least
that way people who have 1.3 in production and do not want to rebuild
the app can use 1.4 jars and so we dont have to really maintain 1.3
after the branch. at least this was
1.4 will not be a drop in replacement without a recompile anyway.
For example i noticed when i do only generics i suddenly have compile
errors at specific places because. Dont know why exactly but i guess
generics sometimes makes a method narrower in the call or something.
Also i have now more the
im not sure we should fix those things that break the api in 1.4. then
1.4 stops being a drop in replacement for 1.3 and we will have to do
more 1.3 releases instead of telling people to drop in 1.4 jar...
-igor
On Sun, Mar 23, 2008 at 3:08 AM, Johan Compagner <[EMAIL PROTECTED]> wrote:
> Generi
[] remove the map and the method for 1.3
[X] remove the map and the method for 1.4
Non-binding
>
> [] remove the map and the method for 1.3
> [X] remove the map and the method for 1.4
>
>
Non-binding.
I was looking to fix this issue:
https://issues.apache.org/jira/browse/WICKET-1421
and then i came across AbstractDecimalConverter which still caches Format
objects
Those are not thread safe so we should really remove those.
The problem is then we also have to remove setNumberFormat(LocalemFormat
[ ] do it for 1.3
[x] do it for 1.4
https://issues.apache.org/jira/browse/WICKET-1371
that patch does have an api break. Most of the time i guess only an api
break for the onces that really need this fix
But should i commit it for 1.3 or wait for 1.4?
[ ] do it for 1.3
[ ] do it for 1.4
You can download the release here:
http://sourceforge.net/project/platformdownload.php?group_id=119783
Or update the wicket version in your maven pom's to 1.2.7.
Martijn
On 3/23/08, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> The Wicket team announces the last maintenance release of Wicket 1.
On Sat, 2008-03-22 at 21:49 -0700, Igor Vaynberg wrote:
> since we have the archetype can we remove wicket-quickstart from svn for 1.4?
>
> -igor
>
Not all users use/like Maven.
Martin
The Wicket team announces the last maintenance release of Wicket 1.2:
Wicket 1.2.7.
This release fixes the remaining issues for Wicket 1.2. For future
support we ask you to upgrade to Apache Wicket 1.3 or newer.
This release of the Wicket project is not endorsed or approved by the
Apache Software
hm...
I somehow started to like wicket-quickstart.
As much as the archetype is great for show off, setting up a complete wicket
app with a maven one liner, the quickstart is nice for comming up with diffs
to describe a problem.
I'd keep em.
mf
2008/3/23, Igor Vaynberg <[EMAIL PROTECTED]>:
>
> s
Generics only and really simple stuff that would break api for 1.3.x
(like bugs that need fixing but are api breaks for 1.3.x)
On 3/23/08, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> i assigned a bunch of stuff to 1.3.3 that i think would be nice to get
> done for that release. if we have time grea
ok. Since this isn't an Apache release, I'll just go ahead and release it.
On 3/23/08, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> shall we release 1.2.7 and eol 1.2.x? all the bugs are closed now.
>
>
> -igor
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.2 is release
21 matches
Mail list logo
