click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Demetrios Kyriakis <>
Subject Re: Incompatibilities
Date Mon, 15 Dec 2008 10:12:19 GMT
>> -1 for YUI. If no other WYSIWYG can be found, than I think none should be
>> deployed (or put the tinymce on google code too).
> I don't see the issue here. RichTextArea is simply an example, its not part
> of Click.
I think it should be a "complete" control (even if not part of Apache 
click - due to license problems).
I think TinyMCE is the most advanced WYSIWYG right now.

>> I think a very important issue with these "external" packages/jars is their
>> version: I think their version number should be the *same* as the click
>> distribution that fits to.
>> It is just a pain in the a.. to match all the time the various component
>> versions with the correct framework (I'm speaking about other frameworks :),
>>  but it looks like click is adopting the same bad strategy :( ).
>> Please fix this.
> How do you propose we do this? Each time a new version of Click is released
> we have to re-release all external packages even if they didn't change?
Yes. This can be simply automated, so it shouldn't be a problem.
On the other hand, the impact on the ease of use for your users will be 
So the users would just take this as another good, simple and intuitive 
"convention" (like many other click already has).

> What is a bug is found in an external project? Its version will get out of
> sync with Click.
No it won't be out of sync. Click changes more than anything else, so if 
a bug is found
than it will be fixed in that trunk and upon next click release that 
external jar will be released too.(tags should be also in sync)

Also I'm not sure if it was a very efficient idea to have so many google 
projects. E.g. Wicket has one huge base: wicket-stuff that has all the 
non-apache compatible things. Tapestry on does not, and it's a pain to 
collect all require components.

Of course, if it's completely automated (and the automation file is 
published), than it's not a big problem on how many google projects the 
components are spread.

Thank you,


View raw message