The Karora open source group has announced the release of Cooee 1.0. Cooee is a Java based web application UI framework that allows developers to work entirely against a Swing based API, removing the need for any HTML or Javascript knowledge. Cooee is originally based on the Echo 2 and EchoPointNG source. The code was forked on 10/3/07 and 27/04/07 respectively. This release has focused around the stablisation of the API and brings new functionality to the framework. The changes include: - Ability to set the width of a TabPane - Ability to set the height of a TabPane - Ability to set the font of a TabPane - Ability to render any component into a TreeTable - Event firing for the switching between tabs in the TabPane - Fix for the TreeModelEvent constructor - Various patches for the AccordionPane, CalendarSelect and MenuBarPane - OSGI Support - Manual refreshing of TreeTables The Karora group has also been doing a lot of work on the documentation for the project, which is available via its wiki at http://www.karora.org . Cooee is licensed under an MPL/LGPL license, just as Echo2 is. The release is available immediately via Karora's website and Karora's maven repository. For further information contact info at karora dot org Message was edited by: joeo@enigmastation.com

I do not get it, what value is this project providing over Echo2? What they show is adding some properties to some components, and some incremental enhancements. Am I missing something?

http://blogs.pathf.com/agileajax/2007/06/cooee_branch_of.html

I very, very briefly looked around Cooee's website, but couldn't find why they chose to fork from Echo2 instead of working w/ them? I'd also be interested in hearing from Nextapp about Karora's reason for forking. I've played w/ Echo2 when it originally came out and liked what they had. Granted there were nuances that I found very irritating (some of which were addressed by Cooee), but certainly I don't think there's any glaring issues w/ Echo2 that warrants forking and starting a whole new project.

Ok...so apparently finding the answer to the big question "why fork" is answered w/ only a little bit more effort (apologies for my laziness in not finding it in my earlier post). Per text at http://www.karora.org/, there's 2 reasons for forking "Cooee is NOT here to compete with Echo2 - quite the opposite. What we're doing is trying to provide a much more open environment to stimulate the growth and acceptance of Echo2 / Cooee" ...and... "To answer the second part of this question - why not just contribute, we've seen what happens to contributions as part of Echo2. They end up scattered across forums. The forums suddenly become used for source control, documentation and not to mention bug tracking." I don't normally like to attack like this, but IMHO both reasons are utter horse manure. So the answer to the problem of low adoption of Echo2 is to start yet another framework from which software dev teams to choose from? Also...since Nextapp doesn't use issue tracking, etc effectively we're going to start a brand new project? That's just plain bunk too. So you're going to start a new project that does use issue tracking,etc? Why not just contribute by setting up a server w/ these tools and providing Nextapp access so they don't have to use the forums in a "do everything" manner?

I don't normally like to attack like this, but IMHO both reasons are utter horse manure. So the answer to the problem of low adoption of Echo2 is to start yet another framework from which software dev teams to choose from? Also...since Nextapp doesn't use issue tracking, etc effectively we're going to start a brand new project? That's just plain bunk too. So you're going to start a new project that does use issue tracking,etc? Why not just contribute by setting up a server w/ these tools and providing Nextapp access so they don't have to use the forums in a "do everything" manner?

Sometimes there are organizatonal/social issues that are perceived to hinder contributions. Whether that's the case with Echo2, I don't know. It usually comes down to an issue of control. Sometimes forking is a good thing, sometimes it's not. But it's probably too early to tell at this point. Remember, GCC was forked at one point.

It's realy not interesting to see these frameworks still "forking" - a "join" like Echo with Wicket or whatever would be better.

Very exciting news! Grabbing through the forum post for little widgets and adds-on to the (excellent, no doubt about that) framework, or installing uncommon named jars in your local maven repo, or, the lack of good documentation, all these are little details that keep the framework back from adoption. Specially when you want to promote it to your management. I once tested the Echo2 framework against other frameworks, like GWT, for example, and I found Echo2 programming much more pleasant the GWT. It's pure Java... not JavaScript disguised in Java. Thus for a server-side Java framework, Echo2 is a great one. And also, as OSGi is the next big step in enterprise java applications, integration if Cooee with OSGi/Equinox is a excellent idea! Great work guys and I hope that the efforts of Korora and Nextapp will merge together for the sake of quality!

Nextapp Karora Echo2 Cooee wicket Dont we have enoguh half baked ideas. Do we need more ...... arent you guys satisfied with struts, spring and web wroks etc. do you really think you have a really different and revolutionary way of creating a silly web applications. How much time are you willing to waste on creating another framework ( which will be forgotten in about 6 months) for a web application ? just because its free downt mean its good. There are more important and complex technological challenges to be dealt with. Why not concentrate on those ? -- no more replies from me on this -- -

Nextapp Karora Echo2 Cooee wicket

Dont we have enoguh half baked ideas. Do we need more ......
arent you guys satisfied with struts, spring and web wroks etc. do you really think you have a really different and revolutionary way of creating a silly web applications.

How much time are you willing to waste on creating another framework ( which will be forgotten in about 6 months) for a web application ? just because its free downt mean its good.

There are more important and complex technological challenges to be dealt with. Why not concentrate on those ?

-- no more replies from me on this --
-

Well, some of us want to create applications and focus on create solutions NOT wiring up actions and tracing through config files. And so we CAN concentrate on "important and complex technological challenges".

Nextapp Karora Echo2 Cooee wicket

Dont we have enoguh half baked ideas. Do we need more ......
arent you guys satisfied with struts, spring and web wroks etc. do you really think you have a really different and revolutionary way of creating a silly web applications.

How much time are you willing to waste on creating another framework ( which will be forgotten in about 6 months) for a web application ? just because its free downt mean its good.

In fact, about half baked ideas, yes we have too much. And I believe that it is the Java trouble in the last times. Java has been attacked by ruby/phyton communities (At least in my environment) about this. But at the end of the day, they end up duplicating most of the Java ideas. However, I'm really tired to deal with Struts, Spring, WebWork, HTML, JavaScript, bla, bla, bla. Just too much noise, too much work to do simply a silly thing. Echo2 (And now Cooee) are just an "oasis" for small-medium (And probably large) scale web developments, used to write tons of actions, meta data, forms, html, etc.

There are more important and complex technological challenges to be dealt with. Why not concentrate on those ?

-- no more replies from me on this --
-

Yes, and there is a lot of people in that... but from my point of view, a lot of the costs of developing webapps goes to GUI development (and you just have not much time to care other important things). So why not to make an effort in making a framework that make us very easy (as much as swing) to develop GUI, so I really can take care of other important things in my apps? About the fork, I think that nextapp just got what they deserve. The idea behind Echo2 is just the product of a genius (we have to admit that). But they just didn't know how to keep the community together, the releases are very far apart, the framework is sometimes full of ugly (and obvious bugs) and some painfully inconsistences, that makes programmers do some nasty workarrounds, etc. Developers in forum responses sometimes seem to not care too much about some evident bug reports and feature requests, etc. So the idea of making a fork and just solve all this is not so crazy as it may look. So good for Cooee, and I'm just checking out ther web site ;-)

Greetings and Salutations! I come from C++/ASM/Java/.NET background and even though Java is the buzz word in the industry. It is in fact a mess of technologies and frameworks. I have never seen Echo2 and I don't know what that is. All I know is that ASP.NET provided a better consistent api that solves most of the problems including ajax (and how simple is their ajax implementation). You just brought balance back in the Force[- Starwars] Now I can concentrate on doing webapplications the way I like. i.e. event-driven desktop app like fashion. I don't want to worry about mixing the thousands of frameworks together. Man some of the Ajax frameworks are absolutely a configuration nightmare and unstable and require so much to be done to achieve so less. This is absolutely cool from the demo I have seen. But a slight hitch. Don't you think the Webapp responds a bit slower than those made using struts/jsf? Do you have any scalability metrics. Or memory usage metrics for just the Web UI (View Layer)? But all in all this is absolutely great. Hope you have a nice day! Aditya CTO, MetaASO Solutions

Greetings and Salutations!

I come from C++/ASM/Java/.NET background and even though Java is the buzz word in the industry. It is in fact a mess of technologies and frameworks. I have never seen Echo2 and I don't know what that is. All I know is that ASP.NET provided a better consistent api that solves most of the problems including ajax (and how simple is their ajax implementation).

I've done enough with ASP.NET to know it isn't perfect either. In fact, it's more of a pain to work with than some of the better Java frameworks, and at least with Java you can pick something that better suits you.