WebGalileo Faces releases components as open source

Discussions

News: WebGalileo Faces releases components as open source

  1. JSCAPE and SoftAspects today announced that their popular WebGalileo Faces component suite will be released as open-source under the Apache License. The decision to go open-source was made in an effort to expand the user base while continuing to offer commercial support options. JSCAPE and SoftAspects will continue to offer support to current licensed customers as well as provide community user forums and paid commercial support options for the newly released open-source version. WebGalileo Faces is a suite of Ajax-enabled Java Server Faces (JSF) components for streamlined development of Rich Internet Applications. Using WebGalileo Faces, developers can create web based applications in a fraction of the time required and with fewer errors. This time savings allows developers to deploy applications much faster and focus more of their efforts on the business logic of the application versus the technical details of writing software. Components include containers, panels, dual lists, menus, date and time components, and a flow chart component. WebGalileo Faces has built-in support for several IDE including Sun Java Studio CreatorTM, IBM Rational Application DeveloperTM, Oracle JDeveloperTM and EclipseTM. For more information or to download WebGalileo Faces go to http://www.javawebcomponents.com Message was edited by: joeo@enigmastation.com

    Threaded Messages (33)

  2. Commercial java tools RIP?[ Go to top ]

    While this is great news in and of itself, i'm getting concerned if there is any commercial potential left in building Java developer tools and frameworks -- it seems that commercial offerings are getting open-sourced one-by-one, and the obvious reason for this trend seems to be simply that people are not surrendering their cash. Now, the problem is not the cash i'm saving. It's the lack of motivation for innovating and building developer tools and frameworks in future, caused by low changes of financial rewards. My point is, are we as Java developers being too stingy? /Henri Karapuu
  3. Surprise?[ Go to top ]

    Have you seen the webgalileo demo? http://javawebcomponents.com/webgalileofaces/ I'm definitely not surprised nobody wants to pay for this.
  4. Re: Surprise?[ Go to top ]

    Have you seen the webgalileo demo?

    http://javawebcomponents.com/webgalileofaces/

    I'm definitely not surprised nobody wants to pay for this.
    I did not have the same impression. Most of these components looked very good indeed. Though I do admit that they did not render the fastest but that may have been due to other factors on the site. The one component I was impressed to hear about was the flowchart tool. However, this is one component that needs quite alot of work - still it was nice to see JSF component vendors pushing beyond the typical controls. Mike
  5. Re: Surprise?[ Go to top ]

    Have you seen the webgalileo demo?

    http://javawebcomponents.com/webgalileofaces/

    I'm definitely not surprised nobody wants to pay for this.
    Don't judge a book by its cover, and don't judge a demo by its CSS :-) Functionality wise, it seems decent. The demo is slow compared to others, but then again, it might depend on their host. I share Henri's comments about lack of commercial potential for JSF and other RIA tools, although I won't exactly call it a 'concern'. It will be interesting though to have comments from WebGalileo folks on their new business model.
  6. Book by cover?[ Go to top ]

    What makes you think i was judging the demo from what it looks like? I don't really care for the CSS (although for a commercial product this really doesn't look great). These are some of my concern: Just for the initial demo page, 500 KB was loaded from the server (no example shown yet). Loading the calculator example increased this number to 800KB. Hell, 800KB? I want to see a calculator example, not download the entire internet. The left navigation tree is in an iframe. IFRAME. What year it is? What is a component based framework for if it still uses iframes? Not to mention that the tree, as simple as it looks like, consists of 150KB of javascript.
  7. another JSF free lib[ Go to top ]

    I actually paid $500 and used it for one of the web project about a year ago. I say it was not worth $500, but free? it is ok to me :) Tree component refresh were painfully slow, it was used to emulate Windows explorer for a site directory instead of file directory. We need another open source to reorganize these UI component into a coherent components repository. Too many overlap JSF components.
  8. Re: Commercial java tools RIP?[ Go to top ]

    While this is great news in and of itself, i'm getting concerned if there is any commercial potential left in building Java developer tools and frameworks -- it seems that commercial offerings are getting open-sourced one-by-one, and the obvious reason for this trend seems to be simply that people are not surrendering their cash.

    Now, the problem is not the cash i'm saving.

    It's the lack of motivation for innovating and building developer tools and frameworks in future, caused by low changes of financial rewards.

    My point is, are we as Java developers being too stingy?

    /Henri Karapuu
    Wait a few more years, and then the fallout of everything going open source is really going to hit. It's not going to be pretty in the Java world.
  9. Re: Commercial java tools RIP?[ Go to top ]

    While this is great news in and of itself, i'm getting concerned if there is any commercial potential left in building Java developer tools and frameworks -- it seems that commercial offerings are getting open-sourced one-by-one, and the obvious reason for this trend seems to be simply that people are not surrendering their cash.

    Now, the problem is not the cash i'm saving.

    It's the lack of motivation for innovating and building developer tools and frameworks in future, caused by low changes of financial rewards.

    My point is, are we as Java developers being too stingy?

    /Henri Karapuu


    Wait a few more years, and then the fallout of everything going open source is really going to hit. It's not going to be pretty in the Java world.
    fallout? How exactly will this materialise? Please explain. I don't see it.
  10. Re: Commercial java tools RIP?[ Go to top ]

    Wait a few more years, and then the fallout of everything going open source is really going to hit. It's not going to be pretty in the Java world.


    fallout? How exactly will this materialise? Please explain. I don't see it.
    Me neither, I had the main problem in the past that component vendors went bankrupt and left me hanging in the air with binaries, or abandoned the products without releasing the sources. Noadays even if a project is abandoned at least there is the source. There never really was a fully working component market (although they still try it in the .net world) and probably never will be.
  11. Component and tool vendors have for years been selling their wares by promising fancy schmancy features that never quite deliver in practise. If this open sourcification means that we'll have more offerings like Spring which actually deliver the long term value they promise, and less offerings that push 800kb of JavaScript to fill some perceived need for bling that exists only in some salesperson's head, I'm all for it. That's what I expect from JPA 1.2, JSF 2.0, Seam 3.0 and Spring 3.0. Steady and reliable long term execution, with the possibility of adding bling on top by hiring a graphics design firm to do a CSS skin on top of the application.
  12. f this open sourcification means that we'll have more offerings like Spring which actually deliver the long term value they promise, and less offerings that push 800kb of JavaScript to fill some perceived need for bling that exists only in some salesperson's head, I'm all for it.
    I can't personally see how/why removing the possibility of financial success would increase quality of frameworks and tools. Quite the opposite, if Java community would be used to paying for frameworks i think we would see much more innovation -- Money and fame is better motivation for doing something, than just fame alone. /Henri Karapuu
  13. I can't personally see how/why removing the possibility of financial success would increase quality of frameworks and tools.

    Quite the opposite, if Java community would be used to paying for frameworks i think we would see much more innovation -- Money and fame is better motivation for doing something, than just fame alone.

    /Henri Karapuu
    I'm not so sure. I wouldn't mind to get paid for all the hours I spend on participating in open source projects myself (I could've bought a house from that by now), but it is not my main motivation, and neither is it the motivation of *any* other open source developer that I know (but hey, maybe I just know the wrong people). Sure, if there is sponsoring, it means more developer hours, which probably means faster and better results. Otoh, it means that besides having to deliver a technical edge over competitors, you now also have to deliver a commercial one - I'm not so sure that's often in the interest of end-users. It raises the stakes for people involved in such projects (e.g. now their mortgage depend on it) so it's likely that these projects will be less transparent and less willing to give up their position for the greater benefit (they'll be more inclined to start a publicity/ marketing war). Just my 2c
  14. I can't personally see how/why removing the possibility of financial success would increase quality of frameworks and tools.

    Quite the opposite, if Java community would be used to paying for frameworks i think we would see much more innovation -- Money and fame is better motivation for doing something, than just fame alone.

    /Henri Karapuu


    I'm not so sure. I wouldn't mind to get paid for all the hours I spend on participating in open source projects myself (I could've bought a house from that by now), but it is not my main motivation, and neither is it the motivation of *any* other open source developer that I know (but hey, maybe I just know the wrong people).

    Sure, if there is sponsoring, it means more developer hours, which probably means faster and better results. Otoh, it means that besides having to deliver a technical edge over competitors, you now also have to deliver a commercial one - I'm not so sure that's often in the interest of end-users. It raises the stakes for people involved in such projects (e.g. now their mortgage depend on it) so it's likely that these projects will be less transparent and less willing to give up their position for the greater benefit (they'll be more inclined to start a publicity/ marketing war).

    Just my 2c
    Btw, in my experience the biggest motivations for open source developers are not money or fame, but rather scratching their itch and simply the satisfaction and learning experience from trying to create something that's technically good.
  15. I'm not so sure. I wouldn't mind to get paid for all the hours I spend on participating in open source projects myself (I could've bought a house from that by now), but it is not my main motivation, and neither is it the motivation of *any* other open source developer that I know (but hey, maybe I just know the wrong people).
    Heh. Go to any non-profit organization, where the members are non-paid volunteers, and ask if they are helping the organization because of the money. [what money!!] .. :) Okey it's not perfect analogy. With open source you have some chance for getting cash. The point is: almost by definition money is not the primary motivation for open source developers. But i wasn't talking about open source Java component, tool and framework developers. I was talking about commercial Java component, tool and framework developers. Specifically the ones who do not exist, because it's too difficult to get money from these kind of products currently. I'm claiming that if the current atmosphere wasn't so, hmm, miserly and against commercial Java tools we would have a lot more people developing interesting, innovative software for other Java developers. And they would be able to do it full time. If it would be norm in our industry that people pay 200 USD per developer per year for a web framework, where would you imagine Wicket would be today with the additional resources, i.e. 10 hired full time developers? /Henri Karapuu
  16. I'm not so sure. I wouldn't mind to get paid for all the hours I spend on participating in open source projects myself (I could've bought a house from that by now), but it is not my main motivation, and neither is it the motivation of *any* other open source developer that I know (but hey, maybe I just know the wrong people).


    Heh. Go to any non-profit organization, where the members are non-paid volunteers, and ask if they are helping the organization because of the money. [what money!!] .. :)

    Okey it's not perfect analogy. With open source you have some chance for getting cash. The point is: almost by definition money is not the primary motivation for open source developers.

    But i wasn't talking about open source Java component, tool and framework developers.

    I was talking about commercial Java component, tool and framework developers. Specifically the ones who do not exist, because it's too difficult to get money from these kind of products currently.

    I'm claiming that if the current atmosphere wasn't so, hmm, miserly and against commercial Java tools we would have a lot more people developing interesting, innovative software for other Java developers. And they would be able to do it full time.

    If it would be norm in our industry that people pay 200 USD per developer per year for a web framework, where would you imagine Wicket would be today with the additional resources, i.e. 10 hired full time developers?

    /Henri Karapuu
    Money and corporate backing can definitively help of course. Without companies like Voicetribe and Topicus being willing to function as early adaptors Wicket (which meant an investement for them) probably wouldn't exist today. About paying developers 200 USD a year... I don't think that works. In fact, in the early days of Wicket I tried to hire people for working on documentation and some advanced components for a limited budget. I couldn't find people where were sufficiently interested. Sure, If I could pay a fulltime salary things would be different, though even in that case, it would be a very good and motivated developer to make enough of a difference. Anyway, it's not that I enterely disagree with your assumption that money can make a difference. Sure it does; look at Eclipse and JBoss etc. But I disagree with the Java community having a bleak outlook because some areas proved to be difficult to earn money in. There's plenty of money to earn out there, but vendors have to provide something that really adds value and that is worth the extra hassle of administrative cost, possible vendor lock-in etc. I just don't think component libraries are such opportunities, and end-users are better off having competing open source libraries where competition is solely (you'd hope) about technical merrits and is not blurred by lots of marketing. To get back to component libs for JSF. I think it's good for JSF that there are are many competing alternatives. People often complain about too much choice in web frameworks, javascript/ ajax libraries and now JSF libraries, but you bet it drives innovation. :)
  17. If it would be norm in our industry that people pay 200 USD per developer per year for a web framework, where would you imagine Wicket would be today with the additional resources, i.e. 10 hired full time developers?
    About paying developers 200 USD a year... I don't think that works.
    Sorry, i wrote that badly. With 'people pay' i meant 'users of wicket pay'. So basically wicket project would get income of $200 x number of users per year. And the question was wouldn't wicket be more advanced that way? Of course this was just idle speculation, as in this universe people would hardly pay $200 for a web framework.. ..which was my point.
    But I disagree with the Java community having a bleak outlook because some areas proved to be difficult to earn money in. There's plenty of money to earn out there, but vendors have to provide something that really adds value and that is worth the extra hassle of administrative cost, possible vendor lock-in etc.
    Java community as a whole doesn't have a bleak outlook, but developing tools, frameworks and components FOR the Java community has outlook far worse than just bleak, IMHO. It seems to be normal to pay 25$ for small digital camera utility or operating system tool, but in Java tools that kind of stuff (almost) does not exist. Instead, the stuff is open source, and then if you want support you have to drop a 2000-4000 USD per year for it. In practice it means that the 0.05% who buy the support actually pay for all of the development costs of that software and all of it's 'free community' support, while the costs that they cause when using the commercial support is likely to be a fraction of what they paid. IMHO we'd be far better off if everybody would pay 500$ for a tool/framework. Everybody would get commercial support. With full time developers frameworks and tools would advance faster and have better documentation. There would be more vendors entering the market and more tools to choose from. Everybody wins? /Henri Karapuu
  18. So basically wicket project would get income of $200 x number of users per year. And the question was wouldn't wicket be more advanced that way?
    Probably. Though one of the main reasons for Wicket being where it is today is because we've been eating our own dog food (using it in non-trivial projects) from day one. I'm sure we'd welcome the money, though speaking for myself, I wouldn't have been interested in making Wicket my full time job from the start. The main reason I got involved is because it scratched the big itch of the company I was working for. If there is anything that would (have) help(ed) it is corporate backing. If one of the big players in Java land would back the project up, and divert some marketing and developer resources (e.g. for IDE plugins) that would make a huge difference. In fact, we are very thankful for some Sun/ Netbeans people who wrote articles for us, got us on JavaOne the first year and in general have had a sports-like attitude.
    IMHO we'd be far better off if everybody would pay 500$ for a tool/framework.
    I would be better off for sure! ;)
    Everybody would get commercial support. With full time developers frameworks and tools would advance faster and have better documentation. There would be more vendors entering the market and more tools to choose from. Everybody wins?
    Yeah, if that would apply to all tools and frameworks that would work. It would also be great if outsourcing never resulted in people losing their jobs :) Without it's users, Wicket would've been half as good. All the patches, bug reports and feature requests we've received made it so much better than it would otherwise have been. So as - like you said - probably only a minority is willing to pay for such frameworks and components, I believe that only because of having less users the products wouldn't always be better even if they would receive enough funding to work fulltime on them. I'm sure the same applies for the JSF component libraries out there (though a but... on my but... it also largely depends on how talented the developers are). Pffff... I'm getting tired of my own writings now. Henri, I wouldn't say 'no' to your contribution to my bank account in case you are considering it ;) Cheers.
  19. Without it's users, Wicket would've been half as good. All the patches, bug reports and feature requests we've received made it so much better than it would otherwise have been. So as - like you said - probably only a minority is willing to pay for such frameworks and components, I believe that only because of having less users the products wouldn't always be better even if they would receive enough funding to work fulltime on them.
    Indeed. I'm sure the commercial model would not had worked for Wicket. I was mainly trying to illustrate what is problematic in the behavior of Java community by using this imaginary universe where developers would (normally) pay for their tools, frameworks and components. I'm not trying to change anything. Just point out why the way things are now in Java community may not be optimal.
    Henri, I wouldn't say 'no' to your contribution to my bank account in case you are considering it ;) Cheers.
    Right :) /Henri Karapuu
  20. Sure, if there is sponsoring, it means more developer hours, which probably means faster and better results. Otoh, it means that besides having to deliver a technical edge over competitors, you now also have to deliver a commercial one - I'm not so sure that's often in the interest of end-users. It raises the stakes for people involved in such projects (e.g. now their mortgage depend on it) so it's likely that these projects will be less transparent and less willing to give up their position for the greater benefit (they'll be more inclined to start a publicity/ marketing war).
    Btw i do agree with your point here. It's just that the slight negatives caused by financial concerns would be, IMHO, massively out-weighted by increased number of tool developers and product offerings, as well as improved development speed from working full time. /Henri Karapuu
  21. I can't personally see how/why removing the possibility of financial success would increase quality of frameworks and tools.
    I'm pretty sure the Spring developers get paid. Why not use that model, which seems to work in practise today, and even better than the model it has replaced? But perhaps I'm not getting what you really mean?
  22. I'm pretty sure the Spring developers get paid. Why not use that model, which seems to work in practise today, and even better than the model it has replaced?

    But perhaps I'm not getting what you really mean?
    Yes, i was exaggerating. Some do earn money with open source, and the possibility of 'financial success' is not removed, merely becomes much more difficult when you don't sell a product, but only services for that product. Where i strongly disagree with you is that the business model of providing services for open source product 'seems to work in practice today'. From all i'v seen it looks like only some majors like jboss and spring get sizable revenue in, and even those have been awfully quiet about how much they actually earn. Other problems with that business model are that it's more difficult to set up for startups (easier to sell shareware online than to organize world wide training our), and after leaving startup phase it doesn't scale well (if you want to offer twice the amount of training sessions you need twice the amount of trainers). /Henri Karapuu
  23. Where i strongly disagree with you is that the business model of providing services for open source product 'seems to work in practice today'.
    I'm not necessarily disagreeing with you here. It's just that I don't really care if that particular business model is viable or not, as long as I get enough components that have some other profit model that's viable on the long term, such as developing components through user organization contributions, or developing components as a side effect from consulting gigs, like the Spring guys have succeeded in doing. I don't expect any of those business models to be permanently viable, either. I don't have any specific objection to horse buggies, it's just that they aren't very relevant to me, and as long as I can get from point A to point B somehow, it's not worth to me to subsidize the horse buggy industry.
  24. Does this WebGalileo Faces support JSF 1.2 (I don't see anything about which JSF version it supports on http://www.javawebcomponents.com/)? And WHEN will it be open-sourced? I don't know if anybody has the same thought as mine, but it seems to me that no JSF component suit is perfect. I always have a feeling that I want some components from this suit, some other components from another suit .... If anybody can come up with what component can work with what component (and of course how), then it'll be very helpful for me, at least, and a lot of people, I think.
  25. Does this WebGalileo Faces support JSF 1.2 (I don't see anything about which JSF version it supports on http://www.javawebcomponents.com/)?
    It supports JSF 1.1.
  26. I always have a feeling that I want some components from this suit, some other components from another suit .... If anybody can come up with what component can work with what component (and of course how), then it'll be very helpful for me, at least, and a lot of people, I think.
    Wasn't that the entire idea of the JSF framework in the fist place? Providing a standard component model with a standard event system, so lots of people can develop components to interoperate with each other? At least for the simpler sets I've been able to do just that; mixing tomahawk components, with some Sun blueprint components, standard JSF components and some of my own custom components. Perhaps we need some more of those sets; just a collection of individually usable components where the 'set' does not try to be a mini-framework of its own.
  27. I always have a feeling that I want some components from this suit, some other components from another suit .... If anybody can come up with what component can work with what component (and of course how), then it'll be very helpful for me, at least, and a lot of people, I think.


    Wasn't that the entire idea of the JSF framework in the fist place? Providing a standard component model with a standard event system, so lots of people can develop components to interoperate with each other?

    At least for the simpler sets I've been able to do just that; mixing tomahawk components, with some Sun blueprint components, standard JSF components and some of my own custom components.

    Perhaps we need some more of those sets; just a collection of individually usable components where the 'set' does not try to be a mini-framework of its own.
    Actually most imperoperability problems in between the various component sets stem from the fact that they try something frameworkish some of them implement their own virtual forms to bypass some limitations of the html forms regarding ajax, others simply dont use standard layout mechanisms etc.... By core every component should work with another one, the frameworks which do not add too much framework infrastructure succeed in this to a good degree, the main problems are mainly components or component sets which add a lot of framework infrastructure themselves (most of this infrastructure usually is ajax related by doing something in a different way than everyone expects it to behave) I agree with you, the component set programmers should see their stuff on an isolation by component level, and not on framework level then most problems would go away, but the main problem is, that with all the ajax craze and html deficits you end up with less isolation than it should be and until jsf as cleared up all the ajax infrastructure on spec level (which is one of the goals for 2.0) we always will run into those problems.
  28. While this may not be getting "off topic" my question is this, is WebGallio just using Apache license or will it be going under MyFaces. What controls will Apache MyFaces, as a subproject, as its project evolve. Also, is Apache MyFaces about providing an alternative JSF implementation or should the focus be on providing components and extensions (aka Orchestra) for the JSF community. AJAX is the real incompatibility issues with JSF frameworks with respect to if they will "work" together, the core specification is not. Should Apache MyFaces be about providing a better framework for implementation of components and try to provide a standard approach to AJAX implementation. This is my point about the introduction of WebGallio, I applaud them for providing the open source but the question is what should the community do with it? My concern is quality control, if you were a new user and picked up some of the Tomahawk components your opnion of JSF might be influences by the quality (performance, defects, lack documentation) of those components. Its one thing to use the license its quite another to place stuff under a "project". Its really a question as to what expectation one might have when they go to an open source community like Apache.
  29. While this may not be getting "off topic" my question is this, is WebGallio just using Apache license or will it be going under MyFaces.
    I havent heard anything about Webgalileo having approached myfaces, I cannot speak officially here though since myfaces is a huge project. To my knowledge for now they just use the license, which is a very good license for libraries.
    What controls will Apache MyFaces, as a subproject, as its project evolve.

    Also, is Apache MyFaces about providing an alternative JSF implementation or should the focus be on providing components and extensions (aka Orchestra) for the JSF community.
    For now status quo, core implementation and component sets. Orchestra was just a spinoff of some work already done which then was pushed into a sideproject. The main problem was that most of the work done in orchestra didnt fit into the existing projects (which are implementation and component sets). I dont know where orchestra will evolve into, but it would not be the first project which was moved from subproject status to somewhere else within the apache realm. The current status is more or less provide a core implementation and then have some complibs on top of it. As for the core implementation, the MyFaces 1.2 release is immininent, the vote for the release was started yesterday. All this information of course is unofficial since I cannot speak neither for myfaces nor the ASF.

    AJAX is the real incompatibility issues with JSF frameworks with respect to if they will "work" together, the core specification is not. Should Apache MyFaces be about providing a better framework for implementation of components and try to provide a standard approach to AJAX implementation.
    That is one of the aspects which have to be resolved in the long run by the spec itself, to my knowledge jsf 2.0 wants to tackle the entire ajax path, client side events etc... Once this is in, component interoperability will become better to a big degree I assume. There are other roadblocks to a universal compatibility but Ajax proably is the biggest one.
  30. I started using Delphi when it first came out, and it uses a framework for GUI components to build user interfaces. The components all work together since they are based on the same 'standard' component design interface. As someone has already mentioned the JSF standard should provide this interface for component, and toolset builders to code to. Using one library with another should be as simple as including the jar file in the build, and referencing it in a web page. When Delphi first came out, people would create simple components such as money editors so the currency would appear in the text box and they would charge small amounts of money for this. As time went on, these components became free, and the simple controls which were just subclassed from edit boxes with a little code behind them were open sourced. However, there were still commercial component vendors who wrote component sets that were so good that they could not be duplicated by such a small team of open source enthusiasts. Take a look at http://www.devexpress.com for their Delphi and now .net controls for example. This company is one of the most recommended component companies for Delphi. I paid for their grid and editors out of my own pocket for side projects (about $400). They provide controls such as grids that let you drag columns to group by them, and cool looking and multifunctional editors. My point is that re-hashing one of the default components that comes with JSF isn't enough. It needs to really add on the functionality, and that kind of scale of functionality probably requires a commercial backing. I really recommend downloading their win32 expressgrid demo, or visit their online .net demos, just so you can see the caliber of components the JSF companies need to work towards if they want people to pay for it. A dataTable derivative with a couple of enhancements isn't enough to open peoples wallets, especially when most of the enhancements can be coded yourself (i.e. column sorting by clicking on the column header). The other factor in all this was that the Delphi Component market was/is a significantly smaller one. Perhaps this is also why one or two companies thrived so well in a market which would be considered too small to enter for many big companies. The other issue is that at the end of the day, this is the web, and I even noticed some large performance slow downs on devexpress' online .net grid demo, which may suggest that the same kind of rich functionality may not be possible as it is on the desktop, and there really is no market for web component sets due to the fact that complex components lead to slow but commercial, and simple components lead to usable, but uncommercial.
  31. I was a bit concerned to hear this although the demo of WebGalileo never impressed me BECAUSE of the speed and fact demo seemed to hang. Bad news because there is a question if there is a market place for components at all, JSF specifically, Java in general. I suppose it also means that either JSF is not doing well or people are doing well enough for the rest of the free stuff. I now think Apache Myfaces has a hugh problem on its hands. We have Tomahawk (which should be retired, it has little value over Tobago or Trinidad and of questionable quality), Tobago, Trinidad, and now WebGalileo. None of them really "work" together. I will mention(to be somewhat inclusive) that JBoss now seems to have the Exadel components which were better than Galileo but not Trinidad. This being the other open source alternative. IBM (RAD) has some JSF stuff but I have lost track of what is going on with them. Apache needs to consolidate or it all these offerings will just confuse people.
  32. Bad news because there is a question if there is a market place for components at all, JSF specifically, Java in general.
    Tbh, I've never believed in component markets too much myself. Bad experiences with .NET projects, EJB promises and things like IBM's San Fransisco project. Moreover, I think it's not so much that people have to pay for component suites that make them unattractive, but that source and support is 'closed' and that it is much more of a pain to properly evaluate them.
    None of them really "work" together.

    I will mention(to be somewhat inclusive) that JBoss now seems to have the Exadel components which were better than Galileo but not Trinidad. This being the other open source alternative. IBM (RAD) has some JSF stuff but I have lost track of what is going on with them.

    Apache needs to consolidate or it all these offerings will just confuse people.
    I'm not sure whether this is something Apache should do. Though WebGalileo uses an Apache license, to my knowledge it is not an Apache project (nor is it incubating). If anyone, JSF's stake holders might want to take a look at consolidating the efforts.
  33. Apache needs to consolidate or it all these offerings will just confuse people.
    Actually Trinidad and Tomahawk work together if not then it is a bug, the problems between those two frameworks have been cleared up a while ago. Tobago is a different issue, it uses its own layouting renderer so it is harder to integrated (as far as I have seen the Tobago guys are working on it) As for further consolidation of Tomahawk and Trinidad, things are discussed, but to consolidate it into a single codebase is a huge isse, lots of people have used Tomahawk in the past, it used to be the first and only oss component set there was (not anymore, the more the better), so breaking APIs is not really something which should be achieved. On the other hand there is a huge overlap in functionality simply due to the fact that all these component frameworks were developed by independend entities some of them at the same time and all of them basically try to solve the fundamental issues of web development one way or the other. While the overlap of Trinidad and Tomahawk is a somewhat nasty issue it is due to historical reasons. Same goes for Tobago and the rest. But I agree the component frameworks should be better integrated in a sense that mixing the frameworks in and out on a plug and play base still is a thing which is not fully achieved yet due to various reasons. But the spec also is partially to blame there, because there are holes in the spec which caused the situation to a certain degree. As for a commercial component market, I do not think there will be one in the future, there are simply too many good frameworks out in the wild under very liberal licenses. We will never see the situation of .Net where you have to pay for every button huge amounts. A framework which can charge money on the JSF side has to do things significantly better than the rest otherwise it will fail, and given the current offerings, I cannot really see how you can achieve that.
  34. We have Tomahawk (which should be retired, it has little value over Tobago or Trinidad and of questionable quality), Tobago, Trinidad, and now WebGalileo.
    Actually WebGalileo just uses the Apache license it is not under the apache umbrella, currently only Tomahawk Trinidad and Tobago are. Tomahawk used to the the only component set under MyFaces Trinidad was born out of the ADF donation from Oracle and and Tobago also joined the party some time between the incubation of myfaces and the ADF donation. The idea was to have all the apache related jsf component set projects under the myfaces umbrella. Anything, while I applaud the opensourcing of the Webgalileo components, cannot really say MyFaces has anything to do with it except that the guys chose the Apache license.