Re: VOTE: wicket-datetime (was: VOTE: add Joda time as a dependency)
I normally just copy the string from the console output of the unit test
(without the prefix)
Frank
On 2/5/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
On 2/5/07, Frank Bille <[EMAIL PROTECTED]> wrote:
> On 2/5/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> >
> > Actually, maybe not :) I tried:
> >
> > cssIgnore = new String[] {
> >
> >
"src/java/wicket/extensions/yui/calendar/assets/calendar.css"
> > };
> >
>
>
> "src/main/java/wicket/extensions/yui/calendar/assets/calendar.css"
>
> perhaps?
Duh! Duh! Duh!
Thanks Frank,
Eelco
Re: VOTE: wicket-datetime (was: VOTE: add Joda time as a dependency)
On 2/5/07, Frank Bille <[EMAIL PROTECTED]> wrote:
On 2/5/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> Actually, maybe not :) I tried:
>
> cssIgnore = new String[] {
>
>
"src/java/wicket/extensions/yui/calendar/assets/calendar.css"
> };
>
"src/main/java/wicket/extensions/yui/calendar/assets/calendar.css"
perhaps?
Duh! Duh! Duh!
Thanks Frank,
Eelco
Re: VOTE: wicket-datetime (was: VOTE: add Joda time as a dependency)
On 2/5/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Actually, maybe not :) I tried:
cssIgnore = new String[] {
"src/java/wicket/extensions/yui/calendar/assets/calendar.css"
};
"src/main/java/wicket/extensions/yui/calendar/assets/calendar.css"
perhaps?
Re: VOTE: wicket-datetime (was: VOTE: add Joda time as a dependency)
On 2/5/07, Frank Bille <[EMAIL PROTECTED]> wrote:
On 2/5/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> > So do
> > I just instantiate the appropriate arrays (like cssIgnore) to mark
> > these Yahoo files to be ignored?
>
> Ok, ok, I should read first, than ask. Answer is yes.
>
Yes! :)
Actually, maybe not :) I tried:
cssIgnore = new String[] {
"src/java/wicket/extensions/yui/calendar/assets/calendar.css"
};
That doesn't work. Before I start digging, what did you have in mind?
Are the ignores all directory based rather than work on a single file?
Eelco
Re: VOTE: wicket-datetime (was: VOTE: add Joda time as a dependency)
On 2/5/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > So do > I just instantiate the appropriate arrays (like cssIgnore) to mark > these Yahoo files to be ignored? Ok, ok, I should read first, than ask. Answer is yes. Yes! :) Frank
Re: VOTE: wicket-datetime (was: VOTE: add Joda time as a dependency)
So do I just instantiate the appropriate arrays (like cssIgnore) to mark these Yahoo files to be ignored? Ok, ok, I should read first, than ask. Answer is yes. Eelco
Re: VOTE: wicket-datetime (was: VOTE: add Joda time as a dependency)
On 2/5/07, Frank Bille <[EMAIL PROTECTED]> wrote: On 2/5/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > Martijn/ Frank, I think I got all the headers, notices and patch to > wicket-parent done ok and testing building the whole bunch. But if one > of you could double check please... > * You have included the license header test but not executed it? There is quite a few missing license headers. Duh! I ran maven but with tests off. Anyway, I don't think I actually missed headers, but there are a couple of inclusions from Yahoo. So do I just instantiate the appropriate arrays (like cssIgnore) to mark these Yahoo files to be ignored? * assembly should be under src ;o) Nice. Don't know how that ended up there. I'm actually wondering if we need that licenses dir at all? They should only be needed in core where they are actually used. WDYT? I'll remove them with pleasure. Eelco
Re: VOTE: wicket-datetime (was: VOTE: add Joda time as a dependency)
On 2/5/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: Martijn/ Frank, I think I got all the headers, notices and patch to wicket-parent done ok and testing building the whole bunch. But if one of you could double check please... * You have included the license header test but not executed it? There is quite a few missing license headers. * assembly should be under src ;o) I'm actually wondering if we need that licenses dir at all? They should only be needed in core where they are actually used. WDYT? Frank
Re: VOTE: wicket-datetime (was: VOTE: add Joda time as a dependency)
On 2/3/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: Ok, what about this: we create wicket-datetime, which depends on Joda time, and includes all the date/ time nifty stuff we can come up with, including the dreaded date picker? I went ahead with the project and committed wicket-datetime in the 1.x branch. The components are reasonably stable and feature complete as they are partially based on stuff I already had, and this time (learning from past mistakes) I'm trying to keep them simple (so rather then having everything configurable, people should start implementing their own variations soon with a little bit more hand work). The date picker is based on YUI. I agree with some of you it is a bit on the heavy side, and unfortunately, it doesn't come packed with a bunch of localized texts, but otoh, it looks very decent and is very flexbile and the API is very nice. I have no problem at all with us having multiple datepickers (depending on Joda time or not) in Wicket core projects; I would say more choice == power to our users. So Al/ Igor/ ... if you have one you think is good, please go ahead and commit to wicket-extensions. I hope other people do take a look at wicket-datetime and come up with some useful additions (or suggestions). Martijn/ Frank, I think I got all the headers, notices and patch to wicket-parent done ok and testing building the whole bunch. But if one of you could double check please... Eelco
Re: VOTE: wicket-datetime (was: VOTE: add Joda time as a dependency)
and where does it get the expression from? You give it to the component? So when you say: setFormatString(String) you also initialize the dateconverter? That would be a bit better yes. If the component just makes the converter instead of getting one and then extracting the string. johan On 2/4/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: the one i started in wicket-stuff works a bit different afair. it has javascript that can parse simpledateformat expressions. so you give the expression to the component - or it gets one out of locale, whatever, and then passes it to the javascript. so it stays in sync that way. -igor On 2/4/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > > > One of the issues with the old one was that it depended on the date > > format that was used by the date converter(s). It is/ was pretty ugly > > actually. It would be great if we would have a way to get the pattern > > that will be used for input/ output for date, time and number > > converters used by a component. That way, several components like a > > date field and date picker can work better together than is the case > > now. > > > isn't that how it is done with the old datepicker? > it gets the format out of the converter > and that is as far as i know the only thing how to really do it if you > want > client side validation or have the pattern on the clientside for what ever > reason. > > in the end the converter of the DatePicker converts the string. so that > has > to be in sync > > johan > >
Re: VOTE: wicket-datetime (was: VOTE: add Joda time as a dependency)
isn't that how it is done with the old datepicker?
it gets the format out of the converter
Yeah, with this code:
if (dateConverter == null)
{
// TODO this should be much easier and nicer to do in
2.0
IConverter typeConverter =
target.getConverter(Date.class);
if (typeConverter instanceof DateConverter)
{
dateConverter = (DateConverter)typeConverter;
}
if (dateConverter == null)
{
dateConverter = new DateConverter();
}
}
DateFormat df = dateConverter.getDateFormat(target.getLocale());
if (df instanceof SimpleDateFormat)
{
pattern = ((SimpleDateFormat)df).toPattern();
}
b.append(settings.toScript(target.getLocale(), pattern));
int last = b.length() - 1;
if (',' == b.charAt(last))
{
b.deleteCharAt(last);
}
Looking at that definitively doesn't give me a warm fuzzy feeling inside.
Eelco
Re: VOTE: wicket-datetime (was: VOTE: add Joda time as a dependency)
the one i started in wicket-stuff works a bit different afair. it has javascript that can parse simpledateformat expressions. so you give the expression to the component - or it gets one out of locale, whatever, and then passes it to the javascript. so it stays in sync that way. -igor On 2/4/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > One of the issues with the old one was that it depended on the date > format that was used by the date converter(s). It is/ was pretty ugly > actually. It would be great if we would have a way to get the pattern > that will be used for input/ output for date, time and number > converters used by a component. That way, several components like a > date field and date picker can work better together than is the case > now. isn't that how it is done with the old datepicker? it gets the format out of the converter and that is as far as i know the only thing how to really do it if you want client side validation or have the pattern on the clientside for what ever reason. in the end the converter of the DatePicker converts the string. so that has to be in sync johan
Re: VOTE: wicket-datetime (was: VOTE: add Joda time as a dependency)
One of the issues with the old one was that it depended on the date format that was used by the date converter(s). It is/ was pretty ugly actually. It would be great if we would have a way to get the pattern that will be used for input/ output for date, time and number converters used by a component. That way, several components like a date field and date picker can work better together than is the case now. isn't that how it is done with the old datepicker? it gets the format out of the converter and that is as far as i know the only thing how to really do it if you want client side validation or have the pattern on the clientside for what ever reason. in the end the converter of the DatePicker converts the string. so that has to be in sync johan
Re: VOTE: wicket-datetime (was: VOTE: add Joda time as a dependency)
On 2/3/07, Al Maw <[EMAIL PROTECTED]> wrote: Eelco Hillenius wrote: > Al, are you seriously working on date picker you want to contribute to > Wicket? Yes, but it's really not very far along yet and I don't think we should hold up 1.3 for it (certainly not the first beta at least). Cool. We don't need it for the beta, but for the releases after that, I feel we should have at least one datepicker we all can recommended as a good core component to use. It's relatively easy to make a datepicker if you have either mootools or prototype available. These clash with each other and are both popular. It's a hassle supporting a date picker for each, so the current strategy it stripping out the bits of mootools that I actually need, namespacing them so they can't interfere with anything else, and the writing something from scratch. Sounds good. I don't trust javascript to get the locale and date formatting right for me, so I'm doing that in Java with some
Re: VOTE: wicket-datetime (was: VOTE: add Joda time as a dependency)
Eelco Hillenius wrote: Al, are you seriously working on date picker you want to contribute to Wicket? Yes, but it's really not very far along yet and I don't think we should hold up 1.3 for it (certainly not the first beta at least). It's relatively easy to make a datepicker if you have either mootools or prototype available. These clash with each other and are both popular. It's a hassle supporting a date picker for each, so the current strategy it stripping out the bits of mootools that I actually need, namespacing them so they can't interfere with anything else, and the writing something from scratch. I don't trust javascript to get the locale and date formatting right for me, so I'm doing that in Java with some
Re: VOTE: wicket-datetime (was: VOTE: add Joda time as a dependency)
On 2/3/07, Al Maw <[EMAIL PROTECTED]> wrote: Eelco Hillenius wrote: > On 2/3/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: >> +1 >> >> although almaw is working on his datepicker, and the one in >> wicket-stuff is >> prob 75% there, so we should have a good replacement rsn :) > > That would be cool, and I think a good match for that project as well. > Might be easier to find and stuff. -0 :-) Yes, Joda time is nice, but I want the date picker in core or extensions where it belongs, not in yet another module, so I'm writing one with no Joda-time deps. It's just not necessary IMHO; the date manipulation problem isn't a faff, it's writing the Javascript that is. Yeah, for the datepicker thing itself that is more or less true, though communicating the date pattern *is* a problem unless you introduce a hard dependency on either something like simpledateformat or joda time. But at this point I'm really interested in having a converter (or more) and a couple of components that work well together and that by default solve the time zone problem. Like I said, I'm not gonna write that based on that horrible JDK date/time API (though other's are welcome to try that), and as the proposal to fix that in core based on joda time just got voted away, I want a project that focusses on everything date/time that is consistent. But anyway, a datepicker in extensions would be fine. It would probably just mean we'll have multiple (which we already do as there is the Dojo one as well). Eelco
Re: VOTE: wicket-datetime (was: VOTE: add Joda time as a dependency)
+1 (non-binding) Eelco Hillenius wrote: > > Ok, what about this: we create wicket-datetime, which depends on Joda > time, and includes all the date/ time nifty stuff we can come up with, > including the dreaded date picker? > > Eelco > > > On 2/3/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: >> -1 for core >> +0 for extensions >> +1 for a wicket-joda core module >> >> extensions is getting pretty big, its hard to find things. if i am using >> joda in my project and see wicket-joda i immediately know what it is and >> i >> can easily browse the contents and only see things that interest me. >> >> -igor >> >> >> On 2/3/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: >> > >> > And jar size doesn't really matter on the server, does it? I find that >> > argument pretty much a non-issue. >> > >> > I don't like the fact that we are going to depend on a library and >> > find out that in Java 7 it is no longer necessary (it is now a JSR). >> > The problem is that they are not rubberstamping Joda but again doing a >> > whole committee thing. This would mean new api's etc. At least with >> > concurrent.jar they just rubberstamped the lot and incorporated it in >> > java 5. >> > >> > Even though java.util.Date and java.util.Calendar are not perfect, >> > they are the most used date implementations available and for instance >> > Hibernate/JDBC/ibatis/etc. works directly with that. For such bindings >> > you have to resort to yet another library/dependency if I'm not >> > mistaken. >> > >> > I'm -0 for core, but +1 for extensions. It is not that we want to >> > change the world by making the whole Java experience better, just the >> > HTML serving part. Adding it to extensions and seeing the response to >> > that will give us time to mature it and see if we can build more on >> > top of it. >> > >> > Martijn >> > >> > On 2/3/07, Johan Compagner <[EMAIL PROTECTED]> wrote: >> > > why is it so big? complete wicket is 1.5 so only some date >> manipulations >> > are >> > > 1/3th? >> > > >> > > johan >> > > >> > > >> > > On 2/2/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: >> > > > >> > > > Hi all, >> > > > >> > > > For those who don't know, Joda Time: >> http://joda-time.sourceforge.net/ >> > > > is a *much* better replacement of the Java date and time APIs it >> many >> > > > ways (see their 'why Joda time section'). Also, Joda time will be >> the >> > > > basis of JSR 310 (http://jcp.org/en/jsr/detail?id=310). >> > > > >> > > > Date/ time handling wouldn't normally be part of Wicket's >> > > > responsibility, wouldn't it be the fact that our date related >> > > > components suffer from the JDKs API being bad. I wrote some >> components >> > > > and a converter based on Joda time that work better than the >> current >> > > > ones we have. The most important feature of those components is >> that >> > > > they take the client's time zone into account. I've tried to write >> > > > them against the normal date/time API, but got so sick of battling >> it >> > > > that I gave up. And as soon as I adopted Joda time (which we were >> > > > already using for our project), it worked superb! >> > > > >> > > > My proposal is to include Joda time as a dependency of the wicket >> core >> > > > project. I know *any* extra dependency raises eyebrows and I feel >> > > > great about Wicket hardly having any dependencies at the moment. >> > > > However, I feel this library is so good and could improve our core >> > > > components and converters so much that it is worth having the extra >> > > > dependency. >> > > > >> > > > Joda time is a maven 2 project, is Apache 2.0 licensed, and >> version >> > > > 1.4 is 512KB. >> > > > >> > > > Your thoughts/ votes? >> > > > >> > > > Eelco >> > > > >> > > >> > >> > >> > -- >> > Vote for Wicket at the >> > http://www.thebeststuffintheworld.com/vote_for/wicket >> > Wicket 1.2.4 is as easy as 1-2-4. Download Wicket now! >> > http://wicketframework.org >> > >> >> > > -- View this message in context: http://www.nabble.com/VOTE%3A-wicket-datetime-%28was%3A-VOTE%3A-add-Joda-time-as-a-dependency%29-tf3167425.html#a8788018 Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: VOTE: wicket-datetime (was: VOTE: add Joda time as a dependency)
On 2/3/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: +1 although almaw is working on his datepicker, and the one in wicket-stuff is prob 75% there, so we should have a good replacement rsn :) I just took a look at the one in wicket-stuff (trunk only, as in the branches the project with the same name contains the old datepicker). It looks very nice, but also looks like it still has quite a way to go (including *lots* of test hours as this one is developed from scratch). Also, the idea of the continuous calendar is cool, but probably not for everyone, so while this would be great to have alongside a more traditional datepicker, I don't think it will do as a replacement. Al, are you seriously working on date picker you want to contribute to Wicket? I'm thinking about just creating one based on YUI. The test hours such a widget gets are hard to beat, and though it is not for everyone due to it's size it is very complete and flexible and stuff. The Dojo one is best kept in the Dojo project, as that project (other than the contrib YUI project) *is* under active development. But if Al has serious plans contributing a date picker soon, I'd be happy to wait for that of course. Eelco
Re: VOTE: wicket-datetime (was: VOTE: add Joda time as a dependency)
Eelco Hillenius wrote: On 2/3/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: +1 although almaw is working on his datepicker, and the one in wicket-stuff is prob 75% there, so we should have a good replacement rsn :) That would be cool, and I think a good match for that project as well. Might be easier to find and stuff. -0 :-) Yes, Joda time is nice, but I want the date picker in core or extensions where it belongs, not in yet another module, so I'm writing one with no Joda-time deps. It's just not necessary IMHO; the date manipulation problem isn't a faff, it's writing the Javascript that is. Al
Re: VOTE: wicket-datetime (was: VOTE: add Joda time as a dependency)
On 2/3/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: +1 although almaw is working on his datepicker, and the one in wicket-stuff is prob 75% there, so we should have a good replacement rsn :) That would be cool, and I think a good match for that project as well. Might be easier to find and stuff. Eelco
Re: VOTE: wicket-datetime (was: VOTE: add Joda time as a dependency)
+1 although almaw is working on his datepicker, and the one in wicket-stuff is prob 75% there, so we should have a good replacement rsn :) -igor On 2/3/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: Ok, what about this: we create wicket-datetime, which depends on Joda time, and includes all the date/ time nifty stuff we can come up with, including the dreaded date picker? Eelco On 2/3/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > -1 for core > +0 for extensions > +1 for a wicket-joda core module > > extensions is getting pretty big, its hard to find things. if i am using > joda in my project and see wicket-joda i immediately know what it is and i > can easily browse the contents and only see things that interest me. > > -igor > > > On 2/3/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > > > > And jar size doesn't really matter on the server, does it? I find that > > argument pretty much a non-issue. > > > > I don't like the fact that we are going to depend on a library and > > find out that in Java 7 it is no longer necessary (it is now a JSR). > > The problem is that they are not rubberstamping Joda but again doing a > > whole committee thing. This would mean new api's etc. At least with > > concurrent.jar they just rubberstamped the lot and incorporated it in > > java 5. > > > > Even though java.util.Date and java.util.Calendar are not perfect, > > they are the most used date implementations available and for instance > > Hibernate/JDBC/ibatis/etc. works directly with that. For such bindings > > you have to resort to yet another library/dependency if I'm not > > mistaken. > > > > I'm -0 for core, but +1 for extensions. It is not that we want to > > change the world by making the whole Java experience better, just the > > HTML serving part. Adding it to extensions and seeing the response to > > that will give us time to mature it and see if we can build more on > > top of it. > > > > Martijn > > > > On 2/3/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > why is it so big? complete wicket is 1.5 so only some date manipulations > > are > > > 1/3th? > > > > > > johan > > > > > > > > > On 2/2/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi all, > > > > > > > > For those who don't know, Joda Time: http://joda-time.sourceforge.net/ > > > > is a *much* better replacement of the Java date and time APIs it many > > > > ways (see their 'why Joda time section'). Also, Joda time will be the > > > > basis of JSR 310 (http://jcp.org/en/jsr/detail?id=310). > > > > > > > > Date/ time handling wouldn't normally be part of Wicket's > > > > responsibility, wouldn't it be the fact that our date related > > > > components suffer from the JDKs API being bad. I wrote some components > > > > and a converter based on Joda time that work better than the current > > > > ones we have. The most important feature of those components is that > > > > they take the client's time zone into account. I've tried to write > > > > them against the normal date/time API, but got so sick of battling it > > > > that I gave up. And as soon as I adopted Joda time (which we were > > > > already using for our project), it worked superb! > > > > > > > > My proposal is to include Joda time as a dependency of the wicket core > > > > project. I know *any* extra dependency raises eyebrows and I feel > > > > great about Wicket hardly having any dependencies at the moment. > > > > However, I feel this library is so good and could improve our core > > > > components and converters so much that it is worth having the extra > > > > dependency. > > > > > > > > Joda time is a maven 2 project, is Apache 2.0 licensed, and version > > > > 1.4 is 512KB. > > > > > > > > Your thoughts/ votes? > > > > > > > > Eelco > > > > > > > > > > > > > -- > > Vote for Wicket at the > > http://www.thebeststuffintheworld.com/vote_for/wicket > > Wicket 1.2.4 is as easy as 1-2-4. Download Wicket now! > > http://wicketframework.org > > > >
VOTE: wicket-datetime (was: VOTE: add Joda time as a dependency)
Ok, what about this: we create wicket-datetime, which depends on Joda time, and includes all the date/ time nifty stuff we can come up with, including the dreaded date picker? Eelco On 2/3/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: -1 for core +0 for extensions +1 for a wicket-joda core module extensions is getting pretty big, its hard to find things. if i am using joda in my project and see wicket-joda i immediately know what it is and i can easily browse the contents and only see things that interest me. -igor On 2/3/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > > And jar size doesn't really matter on the server, does it? I find that > argument pretty much a non-issue. > > I don't like the fact that we are going to depend on a library and > find out that in Java 7 it is no longer necessary (it is now a JSR). > The problem is that they are not rubberstamping Joda but again doing a > whole committee thing. This would mean new api's etc. At least with > concurrent.jar they just rubberstamped the lot and incorporated it in > java 5. > > Even though java.util.Date and java.util.Calendar are not perfect, > they are the most used date implementations available and for instance > Hibernate/JDBC/ibatis/etc. works directly with that. For such bindings > you have to resort to yet another library/dependency if I'm not > mistaken. > > I'm -0 for core, but +1 for extensions. It is not that we want to > change the world by making the whole Java experience better, just the > HTML serving part. Adding it to extensions and seeing the response to > that will give us time to mature it and see if we can build more on > top of it. > > Martijn > > On 2/3/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > why is it so big? complete wicket is 1.5 so only some date manipulations > are > > 1/3th? > > > > johan > > > > > > On 2/2/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > > > Hi all, > > > > > > For those who don't know, Joda Time: http://joda-time.sourceforge.net/ > > > is a *much* better replacement of the Java date and time APIs it many > > > ways (see their 'why Joda time section'). Also, Joda time will be the > > > basis of JSR 310 (http://jcp.org/en/jsr/detail?id=310). > > > > > > Date/ time handling wouldn't normally be part of Wicket's > > > responsibility, wouldn't it be the fact that our date related > > > components suffer from the JDKs API being bad. I wrote some components > > > and a converter based on Joda time that work better than the current > > > ones we have. The most important feature of those components is that > > > they take the client's time zone into account. I've tried to write > > > them against the normal date/time API, but got so sick of battling it > > > that I gave up. And as soon as I adopted Joda time (which we were > > > already using for our project), it worked superb! > > > > > > My proposal is to include Joda time as a dependency of the wicket core > > > project. I know *any* extra dependency raises eyebrows and I feel > > > great about Wicket hardly having any dependencies at the moment. > > > However, I feel this library is so good and could improve our core > > > components and converters so much that it is worth having the extra > > > dependency. > > > > > > Joda time is a maven 2 project, is Apache 2.0 licensed, and version > > > 1.4 is 512KB. > > > > > > Your thoughts/ votes? > > > > > > Eelco > > > > > > > > -- > Vote for Wicket at the > http://www.thebeststuffintheworld.com/vote_for/wicket > Wicket 1.2.4 is as easy as 1-2-4. Download Wicket now! > http://wicketframework.org >
