Incompatibilities

[Bob Schellink <sa...@gmail.com>]

There is a new JIRA [1] for tracking issues we need to resolve before 
we can push our Incubator release.

[1]: http://www.avoka.com/jira/browse/CLK-477

We'll add more tasks as we go along. :)

regards

bob

Re: Incompatibilities

[Demetrios Kyriakis <de...@gmail.com>]

>> No, for the user it is not confusing. It's the same thing like with the
>> controls
>> distributed with Click too: even if they don't change, they still get an
>> updated "version" by being in that jar (or extras jar). I think the same
>> should be true for the "external" jars too. 
> 
> Sorry but if users upgrade Click they should not have to re-download
> extension projects, especially if those projects haven't changed.
Users should not care about individual components much. They should 
think of Click as a whole, and if they want to optimize, than remove 
what's not needed.

I see this problem live every day with Tapestry and other projects and 
it's just a pure pain (and I haven't even gotten yet in the dependency
nightmare with the other Apache projects most projects seems to use - 
e.g. commons).

Please put it in the right context: the users many times don't use the 
latest version of Click, so than hunting the right version is not 
simple: in most cases it's not that simple as "just get the latest 
version from everyting you need".

Thank you,

Demetrios.

Re: Incompatibilities

[Bob Schellink <sa...@gmail.com>]

>
> No, for the user it is not confusing. It's the same thing like with the
> controls
> distributed with Click too: even if they don't change, they still get an
> updated "version" by being in that jar (or extras jar). I think the same
> should be true for the "external" jars too.



Sorry but if users upgrade Click they should not have to re-download
extension projects, especially if those projects haven't changed.
Let's just agree to disagree on this.

bob

Re: Incompatibilities

[Demetrios Kyriakis <de...@gmail.com>]

>> 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. 
> Sure but first somebody needs to step up and create the control and project.
> In case somebody is interested
> I've added our old TinyMCE example to ClickClick.
Good to know.

> 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
>> huge.
>> So the users would just take this as another good, simple and intuitive
>> "convention" (like many other click already has).  
> Sorry to me that is more confusing. Having versions bumped without making
> actual changes seems weird.
No, for the user it is not confusing. It's the same thing like with the 
controls
distributed with Click too: even if they don't change, they still get an
updated "version" by being in that jar (or extras jar). I think the same 
should be true for the "external" jars too. The automation would ensure
that it's not more work: there are even ANT tasks for SVN  and SSH 
operations.

> A much simpler approach is to document the external project which Click
> version it depends on. You can see this very clearly
> here: http://code.google.com/p/click-calendar/
No, it's not. Somebody needs to write that, keep it up to date (and this
often doesn't happen), and the users also need to read it(they usually 
don't - they just ask all the time), than do it: it's just too much work 
for everybody where automation could simply do everything: the users 
would not even notify that those are external.

> Users can also use Click's get-deps task to pull down the latest version of
> of click-calendar.
Advanced users yes, but not many of them. I like get-deps allot, but I think
an automation would be even better (it would be anyway for the 
"building",  not for the "getting" part)

> 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.  
> Wicket-stuff is in constant flux so I don't know why you bring this up as a
> good example.
That "constant flux" is because it's also a "sandbox" with no 
separation. Click on the other
hand already has a clearly separated sandbox directory, so it wouldn't 
be that messy.

> Initially I wanted to integrate calendar with ClickClick but it is not
> maintained currently so was too much effort. Hence
> the calendar specific project was created.
> 
> Keep in mind there are only two projects: calendar and charts. 
With ClickClick there are 3, and there's allot of duplicated information :).

> And I'm not
> sure how popular the chart controls are. 
I used them in several projects, and they're very simple and easy. Of 
course, I think there are many missing features, but they're very 
practical for nice "dashboard" pages (the first users get after login) 
of many web 2.0 apps.

Thank you,

Demetrios.

Re: Incompatibilities

[Bob Schellink <sa...@gmail.com>]

On Mon, Dec 15, 2008 at 12:12 PM, Demetrios Kyriakis <
demetrios.kyriakis@gmail.com> wrote:

> 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.



Sure but first somebody needs to step up and create the control and project.
In case somebody is interested
I've added our old TinyMCE example to ClickClick.


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
> huge.
> So the users would just take this as another good, simple and intuitive
> "convention" (like many other click already has).



Sorry to me that is more confusing. Having versions bumped without making
actual changes seems weird.

A much simpler approach is to document the external project which Click
version it depends on. You can see this very clearly
here: http://code.google.com/p/click-calendar/

Users can also use Click's get-deps task to pull down the latest version of
of click-calendar.


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.


Wicket-stuff is in constant flux so I don't know why you bring this up as a
good example.

Initially I wanted to integrate calendar with ClickClick but it is not
maintained currently so was too much effort. Hence
the calendar specific project was created.

Keep in mind there are only two projects: calendar and charts. And I'm not
sure how popular the chart controls are. Users
will probably only concern themselves with the calendar project.

bob

Re: Incompatibilities

[Demetrios Kyriakis <de...@gmail.com>]

>> -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 
huge.
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,

Demetrios.

Re: Incompatibilities

[Bob Schellink <sa...@gmail.com>]

On Mon, Dec 15, 2008 at 11:36 AM, Demetrios Kyriakis <
demetrios.kyriakis@gmail.com> wrote:

>
> -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 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?

What is a bug is found in an external project? Its version will get out of
sync with Click.

bob

Re: Incompatibilities

[Demetrios Kyriakis <de...@gmail.com>]

> #1 DateField was refactored into a DateField and CalendarField. 
> DateField accepts a date which must be keyed in by the user. It does not 
> support a calendar popup. CalendarField is based on JSCalendar and 
> hosted at Google code: http://code.google.com/p/click-calendar/
> 
> #2 Chart controls and examples was moved to its own Google project as 
> well: http://code.google.com/p/click-charts/
> 
> #3 The JavaScript function addLoadEvent (control.js) was rewritten under 
> Apache license.
> 
> #4 The RichTextArea example, based on TinyMCE, was replaced by YUI 
> editor. YUI is released under BSD so is compatible with Apache license.
-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).


> Next task is to update all the distribution license headers. According 
> to this document [1] the license header should not contain any copyright 
> notices.
> 
> There is also the issue of controls contributed by Ahmed which might be 
> rewritten.
> 
> With these out of the way we can start thinking of releasing our first 
> Apache release. :)
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.

Thank you,

Demetrios.

Re: Incompatibilities

[Malcolm Edgar <ma...@gmail.com>]

Excellent

regards Malcolm Edgar

On Sun, Dec 14, 2008 at 5:26 AM, Bob Schellink <sa...@gmail.com> wrote:
> Just a quick update on recent commits:
>
> #1 DateField was refactored into a DateField and CalendarField. DateField
> accepts a date which must be keyed in by the user. It does not support a
> calendar popup. CalendarField is based on JSCalendar and hosted at Google
> code: http://code.google.com/p/click-calendar/
>
> #2 Chart controls and examples was moved to its own Google project as well:
> http://code.google.com/p/click-charts/
>
> #3 The JavaScript function addLoadEvent (control.js) was rewritten under
> Apache license.
>
> #4 The RichTextArea example, based on TinyMCE, was replaced by YUI editor.
> YUI is released under BSD so is compatible with Apache license.
>
> Next task is to update all the distribution license headers. According to
> this document [1] the license header should not contain any copyright
> notices.
>
> There is also the issue of controls contributed by Ahmed which might be
> rewritten.
>
> With these out of the way we can start thinking of releasing our first
> Apache release. :)
>
> bob
>
> [1] http://www.apache.org/legal/src-headers.html
>
>
> Bob Schellink wrote:
>>
>> There is a new JIRA [1] for tracking issues we need to resolve before we
>> can push our Incubator release.
>>
>> [1]: http://www.avoka.com/jira/browse/CLK-477
>>
>> We'll add more tasks as we go along. :)
>>
>> regards
>>
>> bob
>>
>
>

Re: Incompatibilities

[Demetrios Kyriakis <de...@gmail.com>]

> #1 DateField was refactored into a DateField and CalendarField. 
> DateField accepts a date which must be keyed in by the user. It does not 
> support a calendar popup. CalendarField is based on JSCalendar and 
> hosted at Google code: http://code.google.com/p/click-calendar/
In the new (and "cleaned up") DateField javadoc, I think you could 
mention the
"CalendarField" as an "alternative". I suppose this is not against the 
Apache license. It will save you lot's of future questions.

Thank you,

Demetrios.

Re: Incompatibilities

[Bob Schellink <sa...@gmail.com>]

Just a quick update on recent commits:

#1 DateField was refactored into a DateField and CalendarField. 
DateField accepts a date which must be keyed in by the user. It does 
not support a calendar popup. CalendarField is based on JSCalendar and 
hosted at Google code: http://code.google.com/p/click-calendar/

#2 Chart controls and examples was moved to its own Google project as 
well: http://code.google.com/p/click-charts/

#3 The JavaScript function addLoadEvent (control.js) was rewritten 
under Apache license.

#4 The RichTextArea example, based on TinyMCE, was replaced by YUI 
editor. YUI is released under BSD so is compatible with Apache license.

Next task is to update all the distribution license headers. According 
to this document [1] the license header should not contain any 
copyright notices.

There is also the issue of controls contributed by Ahmed which might 
be rewritten.

With these out of the way we can start thinking of releasing our first 
Apache release. :)

bob

[1] http://www.apache.org/legal/src-headers.html


Bob Schellink wrote:
> There is a new JIRA [1] for tracking issues we need to resolve before we 
> can push our Incubator release.
> 
> [1]: http://www.avoka.com/jira/browse/CLK-477
> 
> We'll add more tasks as we go along. :)
> 
> regards
> 
> bob
>