Discussions

News: Red Hat, Exadel partner around open source tools for JBoss

  1. Exadel, a provider of rich application components and tooling, today announced plans to open source its commercial products, Exadel Studio Pro and its RichFaces component library, to JBoss.org under LGPL. As part of the partnership with Red Hat, Exadel will also migrate its Ajax4jsf project from java.net to JBoss.org. Red Hat's Gavin King will lead efforts to integrate the three projects into the JBoss Enterprise Middleware Suite (JEMS). TheServerSide.com sat down with Sacha Labourey, CTO of Red Hat's JBoss Division, to learn more about the partnership with Exadel, and its effects and benefits for the enterprise and the open-source communities. TheServerSide.com. What is the extent of the partnership between Exadel and Red Hat? Sacha Labourey. The Red Hat and Exadel partnership is twofold. First, Exadel will open source its commercial products -- Exadel Studio Pro and RichFaces -- at JBoss.org as Red Hat Studio Developer and JBoss RichFaces, respectively. Exadel is also moving its popular Ajax4jsf project, currently hosted on java.net, to JBoss.org, where it will become JBoss Ajax4jsf. Second, Red Hat and Exadel will continue developing the three projects going forward, including integration with existing JBoss platform technologies such as JBoss Seam. This ongoing development will be done under JBoss's leadership. In 2007, one of our engineering focus is on the "JEMS Grand Unification". This unification takes place at the management, tooling and programming model. The management part is something that was already initiated about 2 years ago with JBoss ON and led by Greg Hinkle and Richard Friedman. The tooling aspect has now been initiated by this partnership and Seam is taking care of the programming model. The very good news here is that Gavin King is taking a leadership role in that "Grand Unification" and will lead the vision of these two strategic aspects: tooling and programming model. Given Gavin's credibility in giving back productivity to the developers, you should expect great innovations. I am personally thrilled to see Gavin take on that strategic responsibility. TSS. What's the main benefit that your users can expect from this partnership? SL. For the first time, developers will have access to a very rich Eclipse-based toolset that is entirely available in open source. Now, developing on any platform, and in particular the JBoss platform, will be easier than ever, as developers benefit from an integrated, highly productive, and rich development experience. Also, thanks to the Exadel engineers, you should expect an acceleration in the number of JEMS plugins that will be made available in Red Hat Developers Studio. TSS. Which products are included in the partnership? SL. Ajax4jsf, currently one of the most popular open source projects on java.net, will become JBoss Ajax4jsf. Ajax4jsf is a rich component development framework that extends the benefits of JSF to AJAX development. JBoss Ajax4jsf is available since Monday, March 5 at JBoss.org. RichFaces, currently a commercial product, will become JBoss RichFaces. **RichFaces** is a rich component library for JSF built on top of Ajax4jsf, an advanced framework for easily integrating AJAX capabilities into business application development. RichFaces allows users to quickly incorporate AJAX and flexible design through skinnability into their JSF applications. JBoss RichFaces is available in open source, for the first time, since March 5 at JBoss.org. Exadel Studio Pro, currently a commercial product, will become Red Hat Developer Studio. Exadel Studio Pro is an Eclipse-based development environment combining visual and source-oriented development approaches with support for multiple open source technologies and frameworks, including JSF, Struts, Hibernate, MyFaces, Oracle ADF, Shale, Spring, and others. Red Hat Developer Studio will be available in open source by summer 2007. TSS. Does the partnership also include services, or will Exadel continue to operate that part of their business independently? SL. Exadel will continue to provide professional services around these three products. This was already a very strong part of Exadel's business. By moving software development and product management to Red Hat, Exadel can focus exclusively on this core strength. TSS. What are the benefits for enterprise development organizations regarding this partnership? SL. Enterprise developers now have a mature, Eclipse-based development environment that is entirely available in open source. Though Red Hat will be optimizing Red Hat Developer Studio for the JBoss platform, we will continue to support our tools on other platforms like WebSphere and WebLogic. This partnership also lays the groundwork for a much more comprehensive developer program that Red Hat will launch in conjunction with the availability of Red Hat Developer Studio. This program is aimed at enterprise developers that want to leverage our 108 developer portal (launched in May 2006 and in beta now), certified tools and runtimes for out of the box development, and subscriptions which provide access to valuable support and services. We will announce this new program in the next months, so stay tuned. TSS. And the benefits for independent and open-source developers? SL. Independent and open source developers also benefit from having a high caliber Eclipse-based developer toolset available in open source. They can download and use Red Hat Developer Studio, JBoss Ajax4jsf, and JBoss RichFaces in the same manner that they use other JBoss.org projects. They are welcomed to contribute to the future development of these projects. Because we will be using GPL-based licenses -- a first for the tools space -- these projects will remain in open source and available to all developers. TSS. Can you provide a time line for the Red Hat Developer Studio? SL. Because Exadel Studio Pro is a more mature product that's been in development for several years, it has a much larger code base for us to go through, sanitize, and prepare for open sourcing. We expect to release Red Hat Developer Studio under a GPL-based license by summer 2007. TSS. The products are released as open-source under the LGPL license rather than Eclipse's. Are you concerned that this may turn off potential users due to perceived issues of redistribution involved in the LGPL/GPL licenses? Some enterprises see the Eclipse license as more IP-friendly. SL. No, in fact. With a GPL-based license, users can have confidence that these products will always remain in open source, available for all to use. The license ensures that any changes/additions to the code base go back to open source, thus making for a much more stable distribution in the long run. Even though, some companies (usually proprietary software vendors) have a vested interest to generate FUD around the GPL and LGPL licenses, most of the open source projects are based on these two licenses. And as you know, for a few months now, this includes Java SE (OpenJDK). TSS. Will users incur in any redistribution issues for code produced by these tools due to the licensing changes? SL. No, absolutely no changes. What you generate is your code. TSS. What is the upgrade path for existing JBoss and Exadel customers? SL. Starting March 5, Exadel is making an extended evaluation version of Exadel Studio Pro available at no cost. This evaluation version should expire around the time that Red Hat Developer Studio is available in open source. To get the extended evaluation of Exadel Studio Pro, visit http://jboss.org/projects/rhdevstudio TSS. Are there any end-of-life support issues for existing Exadel customers after the transition? SL. No, any Exadel customer will get what they are expecting from Exadel. TSS. What's next? SL. While we cannot talk about those yet, you should expect more announcements in the next months, so stay tuned. The partnership with Exadel was a great example of collaboration inside Red Hat, 6 months after the merger: this partnership has been initiated and led by Bryan Che (PM for developers at Red Hat) and Ram Venkataraman (PM for JBoss). While engineering wasn't leading that partnership, we remained in close touch with Ram and Bryan. We think it is a fantastic opportunity. I'd like to also thank some people that have been involved at various levels and helped make it happen on time for EclipseCon: Max Andersen, Gavin King, Ryan Campbell, Eric Brown, Bob McWhirter and James Cobb.

    Threaded Messages (102)

  2. Page [Product] Not Found[ Go to top ]

    http://jboss.org/projects/rhdevstudio change to http://labs.jboss.com/portal/rhdevstudio/
  3. Exadel[ Go to top ]

    Always had for me this basic geniality with some of the tools being the best in the Eclipse space, and they always failed by the buggyness of the entire package. The Price hike once the underlying WTP went out of beta (and still was unusable) made me go away from the platform and revert back to myeclipse which could not do that much in JSF but at least worked 100% at the parts I needed. I just wonder how the entire package is nowadays, I always thought, if the rest of the ide (db tools, server management, generally the underlying wtp) was as good as their html and jsf editors this ide would have been awesome. Anyway this is great news, especially since I am moving towards facelets currently!
  4. Ajax4JSF vs GWT[ Go to top ]

    Can anyone please explain the benefits of using JSF over GWT. So far I see: To implement simple Web2.0 UI with JSF developer must Learn JSF + Facelets and find out that it makes him write a lot of stuff like new forms writing language,backing beans, as well as force to use huge XML mappings. To get rid of half of mappings and replace backing beans with other backing beans developer must learn SEAM and find out that it is not a peace of cake to run SEAM on anything but JBOSS4. After that he understands that he still haven't done anything that makes his application look and feel like Web2.0 application. And now he must learn IceFaces or NetAdvantage or Ajax4JSF. uuuuf. Quite a steep learning curve, isn't it? Did I miss something? Probably yes. I missed unit testing for UI, clusterization problem, HARRRRD to DEBUG UI (does your IDE provide good means to debug JSF code? Place your ads here ;-) ). What will happen with Java developer if he choose different Web2.0 component based framework, let's say GWT. He will be able understand framework in one day. With GWT he will be able to write UI in a language he already knows - java. He will be able to do unit testing for UI. He will be able to debug UI just like you debug your AWT/SWT/SWING application. He won't write 100K xml mappings files. He will be able to store client state on client(in this case he won't need to use distributed cache and the clustering will be peace of cake). He won't have to learn complex client states (just like he does when he develops AWT/Swing applications). Did I miss something? Probably there are better choices?
  5. Re: Ajax4JSF vs GWT[ Go to top ]

    Can anyone please explain the benefits of using JSF over GWT.

    So far I see:
    To implement simple Web2.0 UI with JSF developer must
    Learn JSF + Facelets and find out that it makes him write a lot of stuff like new forms writing language,backing beans, as well as force to use huge XML mappings. To get rid of half of mappings and replace backing beans with other backing beans developer must learn SEAM and find out that it is not a peace of cake to run SEAM on anything but JBOSS4. After that he understands that he still haven't done anything that makes his application look and feel like Web2.0 application. And now he must learn IceFaces or NetAdvantage or Ajax4JSF. uuuuf.
    Quite a steep learning curve, isn't it?
    Did I miss something?
    Probably yes. I missed unit testing for UI, clusterization problem, HARRRRD to DEBUG UI (does your IDE provide good means to debug JSF code? Place your ads here ;-) ).


    What will happen with Java developer if he choose different Web2.0 component based framework, let's say GWT.
    He will be able understand framework in one day.
    With GWT he will be able to write UI in a language he already knows - java.
    He will be able to do unit testing for UI.
    He will be able to debug UI just like you debug your AWT/SWT/SWING application.
    He won't write 100K xml mappings files.
    He will be able to store client state on client(in this case he won't need to use distributed cache and the clustering will be peace of cake).
    He won't have to learn complex client states (just like he does when he develops AWT/Swing applications).

    Did I miss something?

    Probably there are better choices?
    That's a good questions. Right now, I am exploring our next generation of front-end technology. Yesterday, I spent a few hours playing with GWT, putting up a simple page that uses a service to integrate with an existing Spring/Struts/Hibernate based app's business object. Except for the 70% of that time spent figuring out how to get the thing to deploy on Tomcat, it seemed pretty straightforward. The next step will be to put a GWT page into an existing app and see how this goes. Then, repeat the process with JSF/MyFaces/Icefaces. What's next, zk?
  6. Re: Ajax4JSF vs GWT[ Go to top ]

    Can anyone please explain the benefits of using JSF over GWT.

    So far I see:
    To implement simple Web2.0 UI with JSF developer must
    Learn JSF + Facelets and find out that it makes him write a lot of stuff like new forms writing language,backing beans, as well as force to use huge XML mappings. To get rid of half of mappings and replace backing beans with other backing beans developer must learn SEAM and find out that it is not a peace of cake to run SEAM on anything but JBOSS4. After that he understands that he still haven't done anything that makes his application look and feel like Web2.0 application. And now he must learn IceFaces or NetAdvantage or Ajax4JSF. uuuuf.
    Quite a steep learning curve, isn't it?
    Did I miss something?
    Probably yes. I missed unit testing for UI, clusterization problem, HARRRRD to DEBUG UI (does your IDE provide good means to debug JSF code? Place your ads here ;-) ).


    What will happen with Java developer if he choose different Web2.0 component based framework, let's say GWT.
    He will be able understand framework in one day.
    With GWT he will be able to write UI in a language he already knows - java.
    He will be able to do unit testing for UI.
    He will be able to debug UI just like you debug your AWT/SWT/SWING application.
    He won't write 100K xml mappings files.
    He will be able to store client state on client(in this case he won't need to use distributed cache and the clustering will be peace of cake).
    He won't have to learn complex client states (just like he does when he develops AWT/Swing applications).

    Did I miss something?

    Probably there are better choices?



    That's a good questions. Right now, I am exploring our next generation of front-end technology. Yesterday, I spent a few hours playing with GWT, putting up a simple page that uses a service to integrate with an existing Spring/Struts/Hibernate based app's business object.

    Except for the 70% of that time spent figuring out how to get the thing to deploy on Tomcat, it seemed pretty straightforward. The next step will be to put a GWT page into an existing app and see how this goes.

    Then, repeat the process with JSF/MyFaces/Icefaces.

    What's next, zk?
    If you want to reproduce your Struts application try Stripes. If you need web2.0 GWT seems the best. Echo 2 uses same approach but it is too slow. --Mark
  7. Re: Ajax4JSF vs GWT[ Go to top ]

    Can anyone please explain the benefits of using JSF over GWT.
    Not much ... I've always thought of JSF as being little more than JSP 3.0. There's some work on integrating Seam and GWT -- Seam is a whole lot more than JSF. Of course once you treat your web app as a monolithic event-driven GUI thing, one wonders what the advantage of GWT is over Swing. Certainly the programming model doesn't appear to be any less verbose.
  8. Re: Ajax4JSF vs GWT[ Go to top ]

    Can anyone please explain the benefits of using JSF over GWT.


    Not much ... I've always thought of JSF as being little more than JSP 3.0.
    There are some comparisons that are so odd, it is hard to know where to start commenting. "JSF little more than JSP 3.0"??
  9. Re: Ajax4JSF vs GWT[ Go to top ]

    Can anyone please explain the benefits of using JSF over GWT.
    JSF and GWT are not competitive, but complementary technologies. I explained our position in the article on the server side site time ago: http://www.theserverside.com/tt/articles/article.tss?l=GWTandJSF G4jsf is a subproject of Ajax4jsf that is dedicated to solve the problem of integration. Rob Jellinghaus is working on integration between GWT and JBoss Seam using G4jsf codebase. See: http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/90c82f3b92191e0c/ https://ajax4jsf.dev.java.net/servlets/ReadMsg?list=users&msgNo=2719
  10. Re: Ajax4JSF vs GWT[ Go to top ]

    Can anyone please explain the benefits of using JSF over GWT.


    JSF and GWT are not competitive, but complementary technologies. I explained our position in the article on the server side site time ago:
    I agree with author and totally disagree with you. Both technologies are used in same problem domain. Building Web2.0 applications. Yes, they have different approach. With GWT it is simple. With JSF it is complex and error prone. Learning JSF,Facelets,ICEFaces + SEAM to make simple WEB2.0 forms works sounds like overengineering . PS You article doesn't show WHY we should use JSF. What are the benefits of JSF? And doesn't it look strange that your “framework” made the size of simple GWT application 2 times bigger in case you include all mapping files? ;-) --Mark
  11. Re: Ajax4JSF vs GWT[ Go to top ]

    Both [JSF and GWT] are used in same problem domain. Building Web2.0 applications.
    As much as I like GWT, it requires Javascript + XHR. I had thought that JSF does too, but JSF proponents have explained -- and not just once -- that JSF in its puriety does not depend on Javascript. Therefore JSF app can be compatible with older or less capable browsers and more accessible. It is another question how many users have their Javascript disabled. On the other hand, I believe JSF could have become a better spec/framework if it were in fact made on top of JSP, not as a parallel spec. They are so different that on early stages of JSF development some suggested to part with JSP at all. I don't get why J2EE needs two similar but different view technologies. The latest JSP 2.1 spec tries to integrate JSP and JSF better, but these technologies are still different. Nevertheless, I want to congratulate Exadel and Red Hat guys for strengthening Java server market. Appears that with JBoss, Seam, Hibernate, RichFaces and with development tools, Red Hat can become a viable one-stop shopping mall. This may threaten other Java frameworks but should make server-side Java more attractive when compared to well-integrated ASP.Net offering.
  12. Re: Ajax4JSF vs GWT[ Go to top ]

    I don't get why J2EE needs two similar but different view technologies. The latest JSP 2.1 spec tries to integrate JSP and JSF better, but these technologies are still different.
    That is because JSF is not a view technology. It is a framework that can use different technologies to render the view. JSP is just one of these. Perhaps it would have been wiser for JSF to use a different approach for its HTML rendering.
  13. JSF tags vs JSP tags[ Go to top ]

    I don't get why J2EE needs two similar but different view technologies. The latest JSP 2.1 spec tries to integrate JSP and JSF better, but these technologies are still different.
    That is because JSF is not a view technology. It is a framework that can use different technologies to render the view. JSP is just one of these. Perhaps it would have been wiser for JSF to use a different approach for its HTML rendering.
    My bad. I meant to say that the "JSF engine" could be used together with JSP presentation technology instead of developing proprietary JSF tags. Current JSP 2.1 spec with Unified EL shows that this is entirely possible. You would probably mention different page lifecycle, but I think this is a weak justification for a totally different tag set of JSF. After all, if looking at the big picture it is all the same: request comes in, processed on the server, the markup is returned back. The internal differences of the lifecycle could be worked out using new JSP actions instead of creating separate tags.
  14. I don't get why J2EE needs two similar but different view technologies. The latest JSP 2.1 spec tries to integrate JSP and JSF better, but these technologies are still different.
    That is because JSF is not a view technology. It is a framework that can use different technologies to render the view. JSP is just one of these. Perhaps it would have been wiser for JSF to use a different approach for its HTML rendering.
    My bad. I meant to say that the "JSF engine" could be used together with JSP presentation technology instead of developing proprietary JSF tags. Current JSP 2.1 spec with Unified EL shows that this is entirely possible.

    You would probably mention different page lifecycle, but I think this is a weak justification for a totally different tag set of JSF. After all, if looking at the big picture it is all the same: request comes in, processed on the server, the markup is returned back. The internal differences of the lifecycle could be worked out using new JSP actions instead of creating separate tags.
    See this article, explains the issues : http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html Some of them come directly from JSP main responsability, rendering and not interpreting the page layout so I think some of the problems are quite unsolvable. Actually, JSF doesn't need tags in the sense of a piece of rendering code but a way to define the view composition in a declarative way, something JSP has never meant to be.
  15. I meant to say that the "JSF engine" could be used together with JSP presentation technology instead of developing proprietary JSF tags. Current JSP 2.1 spec with Unified EL shows that this is entirely possible.

    You would probably mention different page lifecycle, but I think this is a weak justification for a totally different tag set of JSF. After all, if looking at the big picture it is all the same: request comes in, processed on the server, the markup is returned back. The internal differences of the lifecycle could be worked out using new JSP actions instead of creating separate tags.
    See this article, explains the issues :
    http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html
    I've read this article. It explains integration issues of JSP and JSF as these technologies have got developed to date, I don't argue with that. My point was that these discrepancies could have been avoided if JSF was developed as next version of JSP instead of becoming an external band-aid to servlet engine.
    Some of them come directly from JSP main responsability, rendering and not interpreting the page layout so I think some of the problems are quite unsolvable.

    Actually, JSF doesn't need tags in the sense of a piece of rendering code but a way to define the view composition in a declarative way, something JSP has never meant to be.
    Come on, you can do better than that. Who cares what it was or was not meant to be? While time passes new approaches and techniques are developed, so if they can be applied to old technology without breaking it -- why not? I am pretty much sure that JSP could have been extended to what JSF is now without breaking compatibility with legacy JSP code, while gaining new features like declaring view composition. Old applications would not have known about new tags and everyone would have been happy. Instead, JSP is de-facto being pushed into oblivion by the shiny JSF. Anyway, too late ranting now, because of the subject of this thread ;-)
  16. I meant to say that the "JSF engine" could be used together with JSP presentation technology instead of developing proprietary JSF tags. Current JSP 2.1 spec with Unified EL shows that this is entirely possible.

    You would probably mention different page lifecycle, but I think this is a weak justification for a totally different tag set of JSF. After all, if looking at the big picture it is all the same: request comes in, processed on the server, the markup is returned back. The internal differences of the lifecycle could be worked out using new JSP actions instead of creating separate tags.
    See this article, explains the issues :
    http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html
    I've read this article. It explains integration issues of JSP and JSF as these technologies have got developed to date, I don't argue with that. My point was that these discrepancies could have been avoided if JSF was developed as next version of JSP instead of becoming an external band-aid to servlet engine.

    Some of them come directly from JSP main responsability, rendering and not interpreting the page layout so I think some of the problems are quite unsolvable.

    Actually, JSF doesn't need tags in the sense of a piece of rendering code but a way to define the view composition in a declarative way, something JSP has never meant to be.
    Come on, you can do better than that. Who cares what it was or was not meant to be? While time passes new approaches and techniques are developed, so if they can be applied to old technology without breaking it -- why not?

    I am pretty much sure that JSP could have been extended to what JSF is now without breaking compatibility with legacy JSP code, while gaining new features like declaring view composition. Old applications would not have known about new tags and everyone would have been happy. Instead, JSP is de-facto being pushed into oblivion by the shiny JSF.

    Anyway, too late ranting now, because of the subject of this thread ;-)
    Well the problem is that JSP is an imperative programming language by nature. There is nothing interpreting the whole page but this is what JSF needs. In JSF, a page is a definition not a program as in JSP. For instance, how would you deal with c:if (even if you are supposed to used the rendered attribute in jsf)? The tag c:if doesn't execute the nested code in jsp if the condition is not met which is what we want normally but this isn't the case in jsf. In Jsf, we want the component to be created even when it isn't displayed as in Swing. I'm not sure how you can solve this problem without rewriting every c:if tags implementation out there and this is only one simple example. It's not that jsp model is not useful but it isn't made to deal with component based framework since it is mainly a programming language used to render a view which is in contradiction with the component approach needing only a view definition, the logic being handled by components. Hope I made it clear, it's kind of hard to explain in a foreign language ;-)
  17. Re: Ajax4JSF vs GWT[ Go to top ]

    Both [JSF and GWT] are used in same problem domain. Building Web2.0 applications.

    As much as I like GWT, it requires Javascript + XHR. I had thought that JSF does too, but JSF proponents have explained -- and not just once -- that JSF in its puriety does not depend on Javascript. Therefore JSF app can be compatible with older or less capable browsers and more accessible. It is another question how many users have their Javascript disabled.

    On the other hand, I believe JSF could have become a better spec/framework if it were in fact made on top of JSP, not as a parallel spec. They are so different that on early stages of JSF development some suggested to part with JSP at all. I don't get why J2EE needs two similar but different view technologies. The latest JSP 2.1 spec tries to integrate JSP and JSF better, but these technologies are still different.

    Nevertheless, I want to congratulate Exadel and Red Hat guys for strengthening Java server market. Appears that with JBoss, Seam, Hibernate, RichFaces and with development tools, Red Hat can become a viable one-stop shopping mall. This may threaten other Java frameworks but should make server-side Java more attractive when compared to well-integrated ASP.Net offering.
    Well the main problem in my opinion is jsp itself, jsf has not really parted which is one of the problems why the component api is overly complicated, the entire taglib binding layer is a pain to use for the component programmer. JSF has only parted so much that they decoupled themselves to some degree from jsp but kept backwards compatibility. Facelets has been very successful because it departed entirely, while most of the original jsf problems arose from the fact that the departure only was halfway. (which made problems worse like having two different view layers over a blank jsp page, the classical taglib loop problem and verbatim problem) JSP has its merits as quick hack technology, but it has its limits and I think somehwere you have to depart from it, to some degree. Facelets and also Velocity have earned a lot of additional speed in the caching area by handling their own view layers!
  18. Re: Ajax4JSF vs GWT[ Go to top ]

    I agree with author and totally disagree with you.
    Both technologies are used in same problem domain.
    Building Web2.0 applications.
    I'm going to have to go ahead and disagree with you there.. JSF is NOT a Web 2.0 app framework - it is a web application framework. Due to its pluggable nature, you can add Web 2.0 capabilities (ajax4jsf) or even make complete Web 2.0 apps (ICEfaces). Comparing JSF to GWT to is apples and oranges - comparing ICEfaces to GWT might make a little more sense. At any rate, I think GWT is cool, and some of the widgets might be useful, but I think the approach JSF takes is better in a lot of cases. Writing your webapp in Java kind of keeps your designers less in the process. With JSF, all our view code is in xhtml, meaning that it is very easy for designers to go in and modify look and feel of the app, change text, move stuff around, etc.. There very well may be specific cases where GWT is a better choice for a project, but to argue that it is generally a direct "competitor" to JSF is not even remotely accurate.
  19. Re: Ajax4JSF vs GWT[ Go to top ]

    Posted by Spencer Uresk: With JSF, all our view code is in xhtml
    I had an impression that with JSF all view code is made up with JSF tags, or at least this is how it is supposed to be.
    Posted by Rob Jellinghaus: GWT, on the other hand, keeps all your state on the client, but is essentially unsearchable (since it's all Javascript, search engines can't see it).
    Why would you need searchable application output? Websites should be searchable, webapps don't have to.
  20. Re: Ajax4JSF vs GWT[ Go to top ]

    Websites should be searchable, webapps don't have to.
    One site should be searchable, but the other ones might be not. Do not say you believe all sites equal to each other and all of them are just a bunch of hyperlinked text page. The world is not b/w
  21. Re: Ajax4JSF vs GWT[ Go to top ]

    I had an impression that with JSF all view code is made up with JSF tags, or at least this is how it is supposed to be.
    Not really. The only time you use a JSF tag is when you are using a component. So, for example, if you have someone filling out a registration form, typically you'll only have a few components: one for the form, one for each input element, and one for the submit. So, the upside is that a designer can hand me an html prototype (so long as it is xhtml compliant - which it should be anyway ;) )of this registration form, and I can simply replace the form elements with JSF tags, and then I am done with the view code. Should a designer decide to change the layout, change some text, or whatever, then they can just edit that same xhtml file. It is even pretty simple and straightforward for someone with no Java experience to change certain attributes on JSF components by simply editing attributes in the tag. Now, you certainly can run into situations where you have a really complex or poorly designed custom component that makes it difficult for a designer to work with, but the vast majority of the time, I've found it quite possible to let the Java devs do their job and the designers do theirs :)
  22. Re: Ajax4JSF vs GWT[ Go to top ]

    I had an impression that with JSF all view code is made up with JSF tags, or at least this is how it is supposed to be.


    Not really. The only time you use a JSF tag is when you are using a component. So, for example, if you have someone filling out a registration form, typically you'll only have a few components: one for the form, one for each input element, and one for the submit.

    So, the upside is that a designer can hand me an html prototype (so long as it is xhtml compliant - which it should be anyway ;) )of this registration form, and I can simply replace the form elements with JSF tags, and then I am done with the view code.

    Should a designer decide to change the layout, change some text, or whatever, then they can just edit that same xhtml file. It is even pretty simple and straightforward for someone with no Java experience to change certain attributes on JSF components by simply editing attributes in the tag.

    Now, you certainly can run into situations where you have a really complex or poorly designed custom component that makes it difficult for a designer to work with, but the vast majority of the time, I've found it quite possible to let the Java devs do their job and the designers do theirs :)
    I think the original poster was referring to the verbatim problem in jsf 1.0 and 1.1 where you had to push the thml code into verbatim to be placed correctly. This problem is solved, in JSF 1.1 you can use facelets instead of jsp as view technology, jsf 1.2 does not need verbatims anymore as well. Facelets also have the advantage that you can work with standard components and you can map them into their jsf counterparts with a jsfc attribute in the tag, which is even designer friendlier. But in the end I do not see a big deal in giving jsf to designers, dreamweaver tools are available so that dreamweaver can work with facelets and jsf and that is basically what most designers need, because they rely on this program heavily.
  23. Re: Ajax4JSF vs GWT[ Go to top ]

    Posted by Spencer Uresk:
    With JSF, all our view code is in xhtml
    I had an impression that with JSF all view code is made up with JSF tags, or at least this is how it is supposed to be.

    Posted by Rob Jellinghaus:
    GWT, on the other hand, keeps all your state on the client, but is essentially unsearchable (since it's all Javascript, search engines can't see it).
    Why would you need searchable application output? Websites should be searchable, webapps don't have to.
    Hi Micheal, You're partially right and partially wrong. The layout using facelets is in XHTML and of course the visual aspect is provided by the css but of course the components are designed using Java or Velocity in my case. This makes the collaboration with a web designer a lot more simple. For instance, in my previous job, the web designer used to provide me some XHTML prototypes and the only thing left to do was to give life to the page, replacing the at the moment "static" components by JSF's one. It's quite easy using facelets.
  24. Re: Ajax4JSF vs GWT[ Go to top ]

    Posted by Spencer Uresk:
    With JSF, all our view code is in xhtml
    I had an impression that with JSF all view code is made up with JSF tags, or at least this is how it is supposed to be.
    Hi Micheal,

    You're partially right and partially wrong. The layout using facelets is in XHTML and of course the visual aspect is provided by the css but of course the components are designed using Java or Velocity in my case.
    Don't facelets defeat the original idea of JSF, which is if I understand correctly is defining view with device-independent tags and emitting device-specific markup? In regards to facelets: if you know a good article that compares Tapestry and facelets, I would appreciate the link.
    http://java.sun.com/developer/technicalArticles/GUI/JavaServerFaces/ The JSF technology consists of two main components: 1. Java APIs to represent UI components, manage state, handle events, and validate input. The API has support for internationalization and accessibility. 2. Two JSP custom tag libraries for expressing user interface (UI) components within a JSP page, and for wiring components to server-side objects. Page authors can easily add UI components to their pages.
    Is it correct to assume that facelets is a new view technology for JSF and replace JSP custom libraries? If this is the case, will JSF/JSP tags be deprecated in favor of facelets?
  25. JSP vs Facelets for JSF[ Go to top ]

    (Changed the subject as it's no longer about GWT vs. JSF, which has been thoroughly discussed in this thread.)
    Is it correct to assume that facelets is a new view technology for JSF and replace JSP custom libraries? If this is the case, will JSF/JSP tags be deprecated in favor of facelets?
    Certainly the Seam team strongly recommends using facelets exclusively, and the majority of new JSF development (including most of the JSF users in this thread) are using facelets. So effectively, yes, I see JSP being de facto deprecated as a view layer for JSF.
  26. Re: JSP vs Facelets for JSF[ Go to top ]

    So effectively, yes, I see JSP being de facto deprecated as a view layer for JSF.
    Not necessarily deprecated. It just depends on your situation. I tried to sort out the JSP 2.1 vs. Facelets question on our wiki. This page was reviewed by Jacob Hookum, the Facelets lead. http://wiki.jboss.org/wiki/Wiki.jsp?page=JSP2_1_vs_Facelets Stan Silvert http://jsf.jboss.org
  27. Re: Ajax4JSF vs GWT[ Go to top ]

    Posted by Spencer Uresk:
    With JSF, all our view code is in xhtml
    I had an impression that with JSF all view code is made up with JSF tags, or at least this is how it is supposed to be.
    Hi Micheal,

    You're partially right and partially wrong. The layout using facelets is in XHTML and of course the visual aspect is provided by the css but of course the components are designed using Java or Velocity in my case.
    Don't facelets defeat the original idea of JSF, which is if I understand correctly is defining view with device-independent tags and emitting device-specific markup? In regards to facelets: if you know a good article that compares Tapestry and facelets, I would appreciate the link.
    I know that is one of the features of JSF, but I personally don't know of a single project that has actually uses it. I'd be surprised if very many people were. In any case, if you actually need to support multiple output types, your problem isn't necessarily that you are using facelets - it is that you are mixing in device-specific code into the view. You could run into the exact same issue using JSPs. On the projects I've been on that use JSF, this is fine - we have almost a 0% chance of needing to support anything but a web browser on a pc, and we gain a lot of benefit by mixing in HTML. If you did have a need to support mutliple devices, you'd approach it differently, and perhaps in that case a different view technology may be better than facelets.
  28. Re: Ajax4JSF vs GWT[ Go to top ]

    I know that is one of the features of JSF, but I personally don't know of a single project that has actually uses it. I'd be surprised if very many people were.
    I am working on a project that will be using this feature, and the ability to render the same page to different document types is, for me, an exciting feature of Seam 1.1.
  29. Re: Ajax4JSF vs GWT[ Go to top ]

    Don't facelets defeat the original idea of JSF, which is if I understand correctly is defining view with device-independent tags and emitting device-specific markup?
    I never understood this goal in JSF. Anyone who has made a new frontend to an existing webapp for, say, a mobile device, can tell you that the user-interface of the mobile device (no keyboard?) demands that the UI/flow must be reconsidered. So many the JSF components that were uses in the original webapp are rendered useless. Hans
  30. Re: Ajax4JSF vs GWT[ Go to top ]

    Don't facelets defeat the original idea of JSF, which is if I understand correctly is defining view with device-independent tags and emitting device-specific markup?


    I never understood this goal in JSF. Anyone who has made a new frontend to an existing webapp for, say, a mobile device, can tell you that the user-interface of the mobile device (no keyboard?) demands that the UI/flow must be reconsidered. So many the JSF components that were uses in the original webapp are rendered useless.

    Hans
    I totally agree with you, the application pages will have to be changed in order to make it accessible on a different device but at least you can use the same tags to do it so which makes the task a little bit easier. Actually, I find the possibility to use different renderers quite useful when I want to support two different outputs of a same component in the same technology. For instance, JSF use it to represent a list of choices as a combo box or as a list box. I did the same kind of things too to integrate an external component since the outputted markup wasn't really what we wanted. It was great to not have to rewrite the entire component but just the renderer in order to do so.
  31. Re: Ajax4JSF vs GWT[ Go to top ]

    Learning JSF,Facelets,ICEFaces + SEAM to make simple WEB2.0 forms works sounds like overengineering .
    If that's all you're doing, it probably is overengineering. But some people are doing a lot more than that. Your post above reminds me of someone saying, "Learning Hibernate just to store some form data in a database sounds like overengineering." Well, yes, it probably is. That doesn't mean there aren't a lot of business problems that do need Hibernate. Large frameworks are built for those who need them. All technologies have tradeoffs. The best situation is when major frameworks have good interoperability, so each can be used (or not used) where most appropriate, and so they can be integrated gracefully when that makes sense for the business problem.
  32. Re: Ajax4JSF vs GWT[ Go to top ]

    Thanks Sergey, I'm glad you saved those links :-) There are a lot of overlaps between GWT and JSF. But there are also a lot of potential synergies. Very frequently in the open source world, people become emotionally invested in false dichotomies ("why use X when you can just use Y?"). It's even easier to fall into this mindset when both X and Y are fairly complex -- GWT doesn't exactly have a short learning curve if you're just getting started with it! But over time, as more examples of integrating GWT and JSF come out, and as the tools for both GWT and JSF get better, all of those barriers to entry will start to fall. Once upon a time, JSP was black magic too.... I think this Exadel / JBoss announcement is great. The Java world has really needed an open source answer to .NET, and I think this is a big step in the right direction. That said, it's true that any JSF IDE is going to wind up building apps that keep most of their state on the server. Seam makes that a whole lot easier to manage (which is a huge Seam selling point -- all your persistence synchronization problems are greatly alleviated), but it's still a potential scalability issue. GWT, on the other hand, keeps all your state on the client, but is essentially unsearchable (since it's all Javascript, search engines can't see it) and is designed using a custom widget set, not using HTML / DOM tools. Also, since all your state is on the client, you have to manage all the client/server state management yourself -- you've got to prune your object graph when sending from the server, and then you've got to reassociate everything yourself when replying from the client. Of course, all of that is fixable with more software :-) Over time, there's no reason why the GWT / JSF / Seam integration can't be made tighter and tighter, to the point where one day you can design GWT applications inline in your JSF IDE, and to where the GWT client state management can use infrastructure support to simplify all the reassociation / synchronization problems. This is particularly possible because GWT is based on Java source, so (especially once GWT supports Java 5) you can use Java components in your GWT app, and you can write Java state management code that can run on both client and server. (And of course GWT's huge advantage over Swing is that all major browsers can run it with no JDK.) Anyway, all of this is really to say that JSF and GWT have many overlaps but different focuses, and that there are all kinds of integration possibilities that haven't been deeply explored yet. Once GWT, JSF, and Seam can interoperate at a basic level, those possibilities become a lot more accessible.
  33. Re: Ajax4JSF vs GWT[ Go to top ]

    Can anyone please explain the benefits of using JSF over GWT.


    JSF and GWT are not competitive, but complementary technologies.
    Why they can't be competitive? ;-) Both technologies can live without each other and solve same problems. But one(GWT) can do it with a lot of benefits Unit testing for UI, debuging, writing UI in java (not xml), easy clustering,easy to maintain... The other(JSF) brings a lot of complexity - developer have to know JSP,JSF,Facelets, SEAM + IceFaces,MyFaces and others. Have to deal with huge XML files, have to write UI in XML. So, my question remains: what benefits does JSF have over GWT?
  34. Re: Ajax4JSF vs GWT[ Go to top ]

    The other(JSF) brings a lot of complexity - developer have to know JSP,JSF,Facelets, SEAM + IceFaces,MyFaces and others.
    Plain FUD again... JSP and Facelets are exclusive and are almost used the same way. The big difference is behind the scene : Facelet process the page to construct a JSF component tree while JSP doesn't have a clue about JSF (BTW JSP doesn't work well with JSF because it is translated as a servlet at runtime, you loose the original page layout which is problematic when you have a loop for instance). MyFaces is an implementation of JSF. There is nothing almost nothing to learn there except some minor configurations settings if you already know JSF. IceFaces is a set of components and extension to allow Ajax since JSF is a general Web framework and that Ajax wasn't really out there while JSF was worked on. Every general frameworks as the same kind of extensions. But you have to remember that it's not everyone who is ready to jump in the Ajax ship. Finally, Seam is much more than a Web framework, and therefore it cover a lot more ground than a view technology as GWT. I guess it could be useful to GWT too. From what I know (I could be wrong), Seam doesn't add anything directly to the presentation tier but just bind it to the business layer. So you shouldn't mention it in your comparaison JSF versus GWT. As you can see, there isn't that much to learn once we clear the FUD...
  35. Re: Ajax4JSF vs GWT[ Go to top ]

    The other(JSF) brings a lot of complexity - developer have to know JSP,JSF,Facelets, SEAM + IceFaces,MyFaces and others.


    Plain FUD again...
    JSP and Facelets are exclusive and are almost used the same way. The big difference is behind the scene : Facelet process the page to construct a JSF component tree while JSP doesn't have a clue about JSF (BTW JSP doesn't work well with JSF because it is translated as a servlet at runtime, you loose the original page layout which is problematic when you have a loop for instance).

    MyFaces is an implementation of JSF. There is nothing almost nothing to learn there except some minor configurations settings if you already know JSF.

    IceFaces is a set of components and extension to allow Ajax since JSF is a general Web framework and that Ajax wasn't really out there while JSF was worked on. Every general frameworks as the same kind of extensions. But you have to remember that it's not everyone who is ready to jump in the Ajax ship.

    Finally, Seam is much more than a Web framework, and therefore it cover a lot more ground than a view technology as GWT. I guess it could be useful to GWT too. From what I know (I could be wrong), Seam doesn't add anything directly to the presentation tier but just bind it to the business layer. So you shouldn't mention it in your comparaison JSF versus GWT.

    As you can see, there isn't that much to learn once we clear the FUD...
  36. Re: Ajax4JSF vs GWT[ Go to top ]

    Can anyone please explain the benefits of using JSF over GWT.
    For one I'd like to see a lot more components in the GWT. The current code base is pretty sparse and nowhere near compares to some JSF libraries out there. After that, I think it is, in a large part, a matter of preference. If you're a swing programmer I think GWT is far more intuitive. I for one have quite often found myself working with a team where the site was designed as an HTML prototype by a design team and our job was to add life to it. Doing this with JSF, or even JSP for that matter, is a lot easier than doing it with GWT.
  37. Re: Ajax4JSF vs GWT[ Go to top ]

    Can anyone please explain the benefits of using JSF over GWT.


    For one I'd like to see a lot more components in the GWT.
    Thanks for an opinion. Can you please list components that You use in your JSF applications that GWT miss?
    After that, I think it is, in a large part, a matter of preference.
    I agree, everything is matter of preference. Do you prefer do Unit Testing for UI(GWT) or you prefer to find bugs manually (JSF)? Do you prefer to be able to debug UI (GWT) or you don't like to use debugger (JSF)? You prefer to play with huge XML mappingfiles(JSF) or you prefer to keep everything in pure Java Code(GWT)? Do you like to spend a month on education of your team (JSF,Facelets,SEAM + MyFaces,HisFaces,YourOwnFaces) or you want to have a framework that allows to do same things but doesn't have such steep learning curve (GWT)?
    If you're a swing programmer I think GWT is far more intuitive.
    Yes, indeed. But I think it is more intuitive in anyway because if JSF approach was more intuitive we'd already have such framework over AWT/SWT/SWING. Here is my experience. I spent one week to teach PHP programmer to write web apps with with GWT(she knew nothing about debugger at that time, knew nothing about AWT/Swing for sure, she new nothing about servlets/jsp). After that she was able to do quite complex stuff including Trees, Tables with Paging and even Tree Tables ;-). This proves that using GWT is quite simple even if you haven't written a single Swing/AWT/SWT application.


    I for one have quite often found myself working with a team where the site was designed as an HTML prototype by a design team and our job was to add life to it. Doing this with JSF, or even JSP for that matter, is a lot easier than doing it with GWT.
    One question, have you tried to do the same with GWT? ;-)
  38. Re: Ajax4JSF vs GWT[ Go to top ]

    Can anyone please explain the benefits of using JSF over GWT.


    For one I'd like to see a lot more components in the GWT.

    Thanks for an opinion.
    Can you please list components that You use in your JSF applications that GWT miss?


    After that, I think it is, in a large part, a matter of preference.

    I agree, everything is matter of preference.
    Do you prefer do Unit Testing for UI(GWT) or you prefer to find bugs manually (JSF)?
    Do you prefer to be able to debug UI (GWT) or you don't like to use debugger (JSF)?
    You prefer to play with huge XML mappingfiles(JSF) or you prefer to keep everything in pure Java Code(GWT)?
    Do you like to spend a month on education of your team (JSF,Facelets,SEAM + MyFaces,HisFaces,YourOwnFaces) or you want to have a framework that allows to do same things but doesn't have such steep learning curve (GWT)?


    If you're a swing programmer I think GWT is far more intuitive.

    Yes, indeed. But I think it is more intuitive in anyway because if JSF approach was more intuitive we'd already have such framework over AWT/SWT/SWING.
    Here is my experience.
    I spent one week to teach PHP programmer to write web apps with with GWT(she knew nothing about debugger at that time, knew nothing about AWT/Swing for sure, she new nothing about servlets/jsp).
    After that she was able to do quite complex stuff including Trees, Tables with Paging and even Tree Tables ;-).
    This proves that using GWT is quite simple even if you haven't written a single Swing/AWT/SWT application.




    I for one have quite often found myself working with a team where the site was designed as an HTML prototype by a design team and our job was to add life to it. Doing this with JSF, or even JSP for that matter, is a lot easier than doing it with GWT.


    One question, have you tried to do the same with GWT? ;-)
    Then, it's like you said, if you believe so. Can we continue now with Exadel & JBoss story, please?
  39. Re: Ajax4JSF vs GWT[ Go to top ]

    Do you prefer do Unit Testing for UI(GWT) or you prefer to find bugs manually (JSF)?
    Do you prefer to be able to debug UI (GWT) or you don't like to use debugger (JSF)?
    You prefer to play with huge XML mappingfiles(JSF) or you prefer to keep everything in pure Java Code(GWT)
    This is totally untrue. Unfortunately since I am at work I don't have the time to post the details.
  40. Re: Ajax4JSF vs GWT[ Go to top ]

    Do you prefer do Unit Testing for UI(GWT) or you prefer to find bugs manually (JSF)?
    Do you prefer to be able to debug UI (GWT) or you don't like to use debugger (JSF)?
    You prefer to play with huge XML mappingfiles(JSF) or you prefer to keep everything in pure Java Code(GWT)


    This is totally untrue. Unfortunately since I am at work I don't have the time to post the details.
    Nice arguments you have ;-) Probably you should post when you get home. And by the way do you have GWT background?
  41. Re: Ajax4JSF vs GWT[ Go to top ]

    Do you prefer do Unit Testing for UI(GWT) or you prefer to find bugs manually (JSF)?
    Do you prefer to be able to debug UI (GWT) or you don't like to use debugger (JSF)?
    You prefer to play with huge XML mappingfiles(JSF) or you prefer to keep everything in pure Java Code(GWT)


    This is totally untrue. Unfortunately since I am at work I don't have the time to post the details.


    Nice arguments you have ;-)
    Probably you should post when you get home.
    And by the way do you have GWT background?
    Thank. Glad you like it. Actually, it was so big that I couldn't let this pass and of course I was going to come back latter to discuss it further. About GWT, no I don't have any experience with it but I know the concept : translating Java code in Javascript. My point is not about GWT but about the false facts spread around about JSF. Unit testing a JSF application is pretty simple. Managed beans are regular pojos and therefore are easy to test. Components and renderers don't have any dependency on the container object so they are also quite easy to test. The only tricky part is testing the view definition, you have to instantiate the application ViewHandler using mock objects (included in Seam) and invoke the createView() method and test the result. Of course, you can't unit test your Javascript in Java but this is considering you have a lot which is not always the case. If you want to do integration testing without having to start a web container, Seam makes it quite easy to do so : http://docs.jboss.com/seam/1.1GA/reference/en/html/testing.html About debugging using the debugger, I find this point kind of arrogant because it's not everyone who has jump on the Ajax ship (a lot haven't from what I know) so there isn't going to be a tons of JavaScript in every JSF applications. Also, GWT might be very nice and I am going to give it a try in the future but don't forget you aren't really debugging the real code. There may be translation issues you weren't expecting between your Java code and Javascript. It would be like pretending you can use Hibernate without knowing any SQL, only HSQL. Also, there are a lot of Javascript debuggers out there to those not using GWT. My point is not to say that GWT is not a nice tool but that it may have its own issues too, that it gets very useful only in a Ajax application and that it is totally untrue to pretend it's impossible to debug using a debugger in a JSF application. Finally, about the huge mapping files. This is plain FUD. My xml file has never been that big and I was using plain vanilla JSF with Facelets. Actually, if you are using Spring 2.0, your beans should be declared in the Spring context file so it doesn't add a lot of config. Finally, a Seam application declare its managed beans using annotations so there is zero, nada extra configuration involved in a xml file for this part. Well, hope I made it clears what I was disagreeing with.
  42. Re: Ajax4JSF vs GWT[ Go to top ]

    Do you prefer do Unit Testing for UI(GWT) or you prefer to find bugs manually (JSF)?
    Do you prefer to be able to debug UI (GWT) or you don't like to use debugger (JSF)?
    You prefer to play with huge XML mappingfiles(JSF) or you prefer to keep everything in pure Java Code(GWT)


    This is totally untrue. Unfortunately since I am at work I don't have the time to post the details.


    Nice arguments you have ;-)
    Probably you should post when you get home.
    And by the way do you have GWT background?


    Thank. Glad you like it. Actually, it was so big that I couldn't let this pass and of course I was going to come back latter to discuss it further.

    About GWT, no I don't have any experience with it but I know the concept : translating Java code in Javascript.
    ;-) The concept is to let Java developers to write AJAX application not in XML neither in JavaScript but in Java. I suggest you to try GWT first and than participate in topic named Ajax4JSF vs GWT. PS The most funny thing guys who advocate JSF here didn't try GWT.
  43. Re: Ajax4JSF vs GWT[ Go to top ]

    Do you prefer do Unit Testing for UI(GWT) or you prefer to find bugs manually (JSF)?
    Do you prefer to be able to debug UI (GWT) or you don't like to use debugger (JSF)?
    You prefer to play with huge XML mappingfiles(JSF) or you prefer to keep everything in pure Java Code(GWT)


    This is totally untrue. Unfortunately since I am at work I don't have the time to post the details.


    Nice arguments you have ;-)
    Probably you should post when you get home.
    And by the way do you have GWT background?


    Thank. Glad you like it. Actually, it was so big that I couldn't let this pass and of course I was going to come back latter to discuss it further.

    About GWT, no I don't have any experience with it but I know the concept : translating Java code in Javascript.

    ;-)
    The concept is to let Java developers to write AJAX application not in XML neither in JavaScript but in Java.
    I suggest you to try GWT first and than participate in topic named Ajax4JSF vs GWT.

    PS The most funny thing guys who advocate JSF here didn't try GWT.
    I suggest you to take some reading lesson as I specifically said that I was not advocating JSF over GWT since I have zero experience using it but merely correcting completely false facts about JSF and pointout out that not everyone is building entire Ajax-based applications...
  44. Re: Ajax4JSF vs GWT[ Go to top ]

    Let's not go crazy over GWT. It does have a few drawbacks (at least last time I checked): a) calling Java business logic from the client is cumbersome compared to JSF where it is straightforward. Requires custom interfaces, JSON, etc. Not just a straight method call. b) does not support regular Serializable interface, need to implement a CUSTOM GWT interface on all your objects in order to be able to pass them between the server and the client. This means for example I may have to add GWT-specific code to my entity objects, which theoretically should have no view-related code in them. c) potentially exposes your internal Java code when translated to openly viewable Javascript. Maybe that's something you would prefer to avoid. I think a MUCH better option than GWT is Echo2: 100% Ajax, 100% Java. No Java->Javascript translation: http://nextapp.com/platform/echo2/echo/demo/ Why Echo2 has not caught on while GWT gets all the hype, I really don't understand. It just seems like a superior solution. And why Eclipse is re-developing Echo2 from scratch under the name Ajax Toolkit is beyond me too. You have a great implementation already but due to "not invented here syndrome" they will do it again from the beginning. Pointless waste of resources.
  45. Re: Ajax4JSF vs GWT[ Go to top ]

    Let's not go crazy over GWT.

    It does have a few drawbacks (at least last time I checked):

    a) calling Java business logic from the client is cumbersome compared to JSF where it is straightforward. Requires custom interfaces, JSON, etc. Not just a straight method call.

    b) does not support regular Serializable interface, need to implement a CUSTOM GWT interface on all your objects in order to be able to pass them between the server and the client.

    This means for example I may have to add GWT-specific code to my entity objects, which theoretically should have no view-related code in them.

    c) potentially exposes your internal Java code when translated to openly viewable Javascript. Maybe that's something you would prefer to avoid.

    I think a MUCH better option than GWT is Echo2: 100% Ajax, 100% Java. No Java->Javascript translation:
    http://nextapp.com/platform/echo2/echo/demo/

    Why Echo2 has not caught on while GWT gets all the hype, I really don't understand. It just seems like a superior solution.

    And why Eclipse is re-developing Echo2 from scratch under the name Ajax Toolkit is beyond me too. You have a great implementation already but due to "not invented here syndrome" they will do it again from the beginning. Pointless waste of resources.
    I've just started working with GWT, but I don't think those drawbacks are a big deal... a)It is a pretty straightforward callback. I had not problem picking it up. And it is only located in the actual GWT client. And the service itself is just a servlet. All in all, I think, pretty clean separation. b)True. They have something called IsSerialiable. Worst case, I figure I can extend my existing classes and add the interface and cast in the GWT client to the IsSerializable version. Your service code can use the original one with no problems. Or you can copy stuff from into a GWT version. Plenty of ways to do that, included a library I saw in this site. I tried adding a GWT page to an existing app, and I did not have to add any GWT-specific code to my existing objects. In fact, I from what I see and what I have, I would say that you don't have to do that. c)I don't think this is so. The only thing that is translated, at least what I've done, is the GWT client. This is strictly take, say, a list of items, and add it into a tree control. I don't believe any internal code would be necessary. In fact, considering they GWT supports a subset of JDK 1.4x, I don't think you can do all that much. I bigger drawback, IMO, is no layout manager out the box.
  46. Echo2[ Go to top ]

    I still like the Echo2 approach much more: no mess of crossing the Javascript and Java domain. Pure Java, 100% of the time. And so far I have to yet see a single GWT demo that impresses me as much as the Echo2 demo, in particular this one: http://demo.nextapp.com/Demo/app When you can do this in GWT, let us know and show us a sample.
  47. Re: Echo2[ Go to top ]

    I still like the Echo2 approach much more: no mess of crossing the Javascript and Java domain. Pure Java, 100% of the time.

    And so far I have to yet see a single GWT demo that impresses me as much as the Echo2 demo, in particular this one:
    http://demo.nextapp.com/Demo/app

    When you can do this in GWT, let us know and show us a sample.
    Shrug. I'm not selling it, I'm just addressing what you wrote based on my, admitedly limited experience. I've seen Echo2, aa couple of times, over the past couple of years. It looks good. I haven't used it and I just haven't heard enough people using it to have a level enough level of comfort. GWT "seems" to have more traction. It is certainly backed by a company with deep pockets,and that is always a selling point. Have you written an app in Echo2? Do you have customers using it? What was their feedback?
  48. Re: Echo2[ Go to top ]

    I agree on the traction thing, it seems the Google name just can't be beat. No, I have not written a full Echo2 app yet (but neither have I done a full one in GWT either). However, in the Echo2 forums quite a few people have and they seemed quite satisfied with it. It's just a pity that such a promising Java framework seems to be so low under the radar, where it offers a pretty revolutionary approach to web development, IMHO.
  49. Re: Echo2[ Go to top ]

    I agree on the traction thing, it seems the Google name just can't be beat.

    No, I have not written a full Echo2 app yet (but neither have I done a full one in GWT either). However, in the Echo2 forums quite a few people have and they seemed quite satisfied with it.

    It's just a pity that such a promising Java framework seems to be so low under the radar, where it offers a pretty revolutionary approach to web development, IMHO.
    Maybe they need a better PR guy! I'm most likely going for it on the GWT front on my next project. JSF and Icesoft is still a contender, but I still have close to two months to iron it all out. We see how I feel about GWT when the dust settles.
  50. Re: Echo2[ Go to top ]

    I agree on the traction thing, it seems the Google name just can't be beat.

    No, I have not written a full Echo2 app yet (but neither have I done a full one in GWT either). However, in the Echo2 forums quite a few people have and they seemed quite satisfied with it.

    It's just a pity that such a promising Java framework seems to be so low under the radar, where it offers a pretty revolutionary approach to web development, IMHO.
    GWT portlets look simple to program and are visually unintrusive, while Echo2 (as well as Laszlo) showcases a whole windowing system inside a browser page. Thanks, but no thanks. I have my native windowing system in the host OS and I don't want another one inside a page. This is the major reason why I would prefer simpler and leaner GWT approach to heavyweight Echo2 or Laszlo. And these frameworks are slow! I mean ok, the machine I am working on is seven years old, it is 900MHz Athlon with built-in graphics, but it is more than enough for native Windows app, it is enough for Java Swing, but Echo2 or Flash UI is slow. I can see the window content, frame and the header moving independently, looks really ugly. I believe that for intranet usage with known client hardware Echo2 is a good fit, but native Windows app is an even better fit. For internet usage, one cannot assume that every user has a machine with powerful graphics card. Maybe in a year or two when the majority upgrades to Vista, Echo2 will shine.
  51. Re: Echo2[ Go to top ]

    I still like the Echo2 approach much more: no mess of crossing the Javascript and Java domain. Pure Java, 100% of the time.

    And so far I have to yet see a single GWT demo that impresses me as much as the Echo2 demo, in particular this one:
    http://demo.nextapp.com/Demo/app

    When you can do this in GWT, let us know and show us a sample.


    Shrug. I'm not selling it, I'm just addressing what you wrote based on my, admitedly limited experience.

    I've seen Echo2, aa couple of times, over the past couple of years. It looks good. I haven't used it and I just haven't heard enough people using it to have a level enough level of comfort. GWT "seems" to have more traction. It is certainly backed by a company with deep pockets,and that is always a selling point.

    Have you written an app in Echo2? Do you have customers using it? What was their feedback?
    Another one not yet mentioned is ZK. ( http://www.zkoss.org/ ) Alot of components, coding is pure Java and it works very well. I experimented alot with it last year and wrote an intro article http://www.developer.com/design/article.php/3610476 . I don't think I've ever built a java-based web app in less amount of time. It's really a good framework. However, my concern (then and even moreso now) is it will be squeezed out by the increasingly free, standards-based platforms. Mike
  52. Re: Echo2[ Go to top ]

    Interesting. From a look-and-feel issue, doesn't seem quite as polished as the Echo2 demo (but that is probably just minor CSS issues). I am not quite sure if I like the XML UI approach vs. Swing-type UI coding (Echo2's approach), I guess it's a matter of personal preference. How was the ZK performance in your test? I recall checking it out a long time ago and it seemed a lot more sluggish than Echo2, so I didn't look much further into it, but maybe that was just a server issue...
  53. Re: Ajax4JSF vs GWT[ Go to top ]

    Can anyone please explain the benefits of using JSF over GWT.


    For one I'd like to see a lot more components in the GWT.

    Thanks for an opinion.
    Can you please list components that You use in your JSF applications that GWT miss?


    After that, I think it is, in a large part, a matter of preference.

    I agree, everything is matter of preference.
    Do you prefer do Unit Testing for UI(GWT) or you prefer to find bugs manually (JSF)?
    Do you prefer to be able to debug UI (GWT) or you don't like to use debugger (JSF)?
    You prefer to play with huge XML mappingfiles(JSF) or you prefer to keep everything in pure Java Code(GWT)?
    Do you like to spend a month on education of your team (JSF,Facelets,SEAM + MyFaces,HisFaces,YourOwnFaces) or you want to have a framework that allows to do same things but doesn't have such steep learning curve (GWT)?


    If you're a swing programmer I think GWT is far more intuitive.

    Yes, indeed. But I think it is more intuitive in anyway because if JSF approach was more intuitive we'd already have such framework over AWT/SWT/SWING.
    Here is my experience.
    I spent one week to teach PHP programmer to write web apps with with GWT(she knew nothing about debugger at that time, knew nothing about AWT/Swing for sure, she new nothing about servlets/jsp).
    After that she was able to do quite complex stuff including Trees, Tables with Paging and even Tree Tables ;-).
    This proves that using GWT is quite simple even if you haven't written a single Swing/AWT/SWT application.




    I for one have quite often found myself working with a team where the site was designed as an HTML prototype by a design team and our job was to add life to it. Doing this with JSF, or even JSP for that matter, is a lot easier than doing it with GWT.


    One question, have you tried to do the same with GWT? ;-)
    I would say that a look at the Icesoft tags may answer that questions. Their stuff looks pretty good and, for me anyway, is the primary reason why JSF is on the table.
  54. Ajax4JSF vs GWT[ Go to top ]

    IMO, GWT is a new model of web development which is different than MVC based frameworks. It's not just matter of learning new APIs and tools. It needs new design patterns and best practices. Just think of EJBs and other JEE technologies. AFAIR, it took years for Java community to come up with the required design patterns and trade-offs. For now, I would prefer to go with well known MVC based frameworks and keep an eye on GWT.
  55. Re: Ajax4JSF vs GWT[ Go to top ]

    IMO, GWT is a new model of web development which is different than MVC based frameworks. It's not just matter of learning new APIs and tools. It needs new design patterns and best practices.
    Just think of EJBs and other JEE technologies. AFAIR, it took years for Java community to come up with the required design patterns and trade-offs.

    For now, I would prefer to go with well known MVC based frameworks and keep an eye on GWT.
    Well, this is where the innovation comes in. While I'm the first to look to the past to determine how best to succeed and avoid potholes, there is also something to be said for taking a calculated risk via pioneering. My personal belief is that GWT has reached the level needed to take off. Time will tell... Regardless,I think that a well-considered strategy and perhaps, some balls( or to be more PC, vision), is now necessary to reach the next plateau. I would submit that this combination catapulted the likes of Hibernate, Spring, etc to the top.
  56. Very cool. I hope the new IDE will add integrated support for Seam soon, that should make it the perfect combo: Ajax4JSF + RichFaces + Seam.
  57. I might be wrong.. But sounds to me like Exadels business hasn't worked out, and they are winding down business by open sourcing and letting JBoss/Red Hat take over the development.. - 2 years ago, Exadel Pro was priced at $99. - Recently prices where hiked up a few hundred percent. - Now their open sourcing the lot. Sounds to me like the business model never really worked out. But Exadels stuff does have some promise, so not being an Exadel shareholder, I'm happy to see it open sourced!
  58. Me thinks that compititon from MyEclipse has caused Exedel to make this move.
  59. Me thinks that compititon from MyEclipse has caused Exedel to make this move.
    Hehe. I know some guys from the JBoss IDE team who are just itching for some competition with MyEclipse. :-> Some of us believe that Genuitec are skirting waaay to close to an LGPL violation over bundled modifications to Hibernate Tools. Repeated attempts on our part to get them to modify their behavior in this respect as resulted in nothing but empty promises. That's one reason why we decided to go GPL on the Exadel toolset - to break the Genuitec model of "take but never give back".
  60. Better than MyEclipse[ Go to top ]

    FWIW Beyond having a better license, what would make something better than MyEclipse for me would be that if the whole is truly greater than sum of its parts. That is, rather than just being a bundle of plugins, there needs to be a real unified vision full of the necessary "opinions" and "conventions" to create a much more productive environment.
  61. Re: Better than MyEclipse[ Go to top ]

    Beyond having a better license, what would make something better than MyEclipse for me would be that if the whole is truly greater than sum of its parts. That is, rather than just being a bundle of plugins, there needs to be a real unified vision full of the necessary "opinions" and "conventions" to create a much more productive environment.
    Precisely. This requires framework and a toolset to be developed hand-in-hand by the same team.
  62. Precisely.

    This requires framework and a toolset to be developed hand-in-hand by the same team.
    Yes. I just recently spent some time with .NET and one can see how someone developing both together makes possible the otherwise impossible. You have some great open source frameworks to start with. And it's obvious that you know that JEE productivity needs more than just wizards in an IDE, it needs newer frameworks like SEAM or other improvements that can't happen by an IDE alone. (And vice versa.) Anyway, this is all good news. Congratulations to all of you. I look forward more great stuff.
  63. Re: Better than MyEclipse[ Go to top ]

    FWIW
    Beyond having a better license, what would make something better than MyEclipse for me would be that if the whole is truly greater than sum of its parts. That is, rather than just being a bundle of plugins, there needs to be a real unified vision full of the necessary "opinions" and "conventions" to create a much more productive environment.
    I think MyEclipse has always tried to compete based on price - what is it, like $25 for a copy? Unfortunately, they've always been very slow to support new technologies (at least the ones we use), which lead me to drop all our licenses. Honestly, I'd rather pay $2,500 for a good IDE that made me significantly more productive than $25 for one that was of marginal use.
  64. Re: Better than MyEclipse[ Go to top ]

    Lucky you, you can spent 2'500 on IDE. Fortunately you do not have to do so. It all LGPL now. :-) Best, Igor Shabalov.
  65. One of the things I really liked about Exadel was its Hibernate tooling.
  66. I might be wrong.. But sounds to me like Exadels business hasn't worked out, and they are winding down business by open sourcing and letting JBoss/Red Hat take over the development..
    Seems like their business has actually worked out pretty damn well, given that we just paid them a whole bundle of money to get this deal done. ;-) This is not a typical case of a commercial vendor deciding to give away a product they couldn't sell, in a last-ditch attempt to get users. Rather, this is an acquisition of successful technology, for money. It follows the model of JBoss Transactions, which was acquired from Arjuna, and JBoss ESB, which was acquired from Aviva. To be clear, development of these products is most certainly not being "wound down" - the deal very explicitly specifies the resources that will go into ongoing development of RichFaces and the tooling. I have absolutely zero doubt that we will be able to build a super-vibrant community around these excellent projects, now that they are open source, hosted at JBoss, and being integrated with the Seam and Hibernate communities. We've wanted to do something like this for a Long Time :-)
  67. Seems like their business has actually worked out pretty damn well, given that we just paid them a whole bundle of money to get this deal done. ;-)
    I stand corrected, although the pattern of pricing to open source would have implied something completely different. :) I used to be an Exadel customer, the product sure had a lot of promise, however it was plagued by some extremely peculiar bugs and performance issues when I was using it (the IDE would freeze to build the workspace for minutes at a time). This caused me to drop Exadel after a while, as the pain outstripped the benefit. ..so, I hope you take care of it and make it fulfill it's promise!
  68. I might be wrong.. But sounds to me like Exadels business hasn't worked out, and they are winding down business by open sourcing and letting JBoss/Red Hat take over the development..


    Seems like their business has actually worked out pretty damn well, given that we just paid them a whole bundle of money to get this deal done. ;-)

    This is not a typical case of a commercial vendor deciding to give away a product they couldn't sell, in a last-ditch attempt to get users. Rather, this is an acquisition of successful technology, for money.
    My day at EclipseCon revealed a somewhat different perspective. I overheard an Exadel exec commenting on the fact that this deal was largely 'an admission of throwing in towel' with regards to non profitable tools and Ajax components in exchange for guaranteed services from JBoss for some period of time. Not exactly a grandiose exit and definitely an over hyped representation of the situation. While this may prove to be a decent strategy for JBoss over time, I'm somewhat disappointed in the JBoss selection of Ajax4JSF over Icefaces which I believe is a far superior solution that provides distinctive advantages. A superior component offering, Ajax push, and a common Ajax bridge that completely isolates us Java heads from the JavaScript nightmare, just to name a few. Let's hope the Icefaces guys will continue to support Seam moving forward. Bob
  69. Bob, I'm confident that you DID NOT overhear an Exadel exec discussing tht contributing its products to open source represents "throwing in the towel". Quite the contrary. Exadel has always embraced open source software and this plan demonstrates our committment to open source and improving the lives and efficiencies of developers who use these products. Should you have any continued doubts, I invite you to attned our talk this afternoon at Eclipsecon. The talk is titled "JBoss introduces New Open Source Tools and Frameworks for building Rich Internet Applications and will take place Wednesday, 4:30 p.m. Red Hat and Exadel will discuss the motivations for executing this strategy and what benefits there are to Exadel, Red Hat and the developer community. We will be happy to entertain any discussions with you after the session.
  70. Congrats![ Go to top ]

    I always knew that something like that could happen. The community needs only ONE faces library. Gavin did it with persistence, I hope he can do it again. And please, aim your efforts on constructing a solid and stable library with useful components, don't waste time in visual editors.
  71. Re: Congrats![ Go to top ]

    I always knew that something like that could happen.
    The community needs only ONE faces library.
    One of the great strengths of Java over alternatives is choice. The whole point of standards like JSF and JPA is to allow competing implementations, which is good for both vendors and developers.
  72. Re: Congrats![ Go to top ]

    I always knew that something like that could happen.
    The community needs only ONE faces library.


    One of the great strengths of Java over alternatives is choice. The whole point of standards like JSF and JPA is to allow competing implementations, which is good for both vendors and developers.
    What I mean is that we need ONE useful and stable library. I'm tired of search, test, configure and learn libraries in every single new proyect. I want the definitive one.
  73. Re: ONE library[ Go to top ]

    What I mean is that we need ONE useful and stable library. I'm tired of search, test, configure and learn libraries in every single new proyect. I want the definitive one.
    You've missed the point. An API specification, as Steve mentioned, DEFINES the API. You have no more to learn. All implementations of a specification *have* that API. How hard is it ? That is why specifications are important. There is no such thing as a "definitive" library, that implements a specification, because they all do it internally in their own way to give particular benefits. So some run faster etc. That is why a specification is important and that is also why multiple implementations is a good thing because they push each other to implement it better and add on value
  74. Mac OS X support[ Go to top ]

    I hope Mac OS X support is on the way. Eclipse and Java are available for the Apple platform, last I checked.
  75. Re: Mac OS X support[ Go to top ]

    I hope Mac OS X support is on the way.
    Since so many of us at JBoss are using Mac now (including me), this is also a high priority for us ;-)
  76. Re: Mac OS X support[ Go to top ]

    I hope Mac OS X support is on the way. Eclipse and Java are available for the Apple platform, last I checked.
    Actually, I was just looking through the forums and found this: http://forum.exadel.com/viewtopic.php?t=4822 It looks like Exadel works unofficially on OS X (except for the visual designer), so I imagine we'll be able to use the new Red Had Developer Studio in a similar manner until full OS X support comes out.
  77. Re: Mac OS X support[ Go to top ]

    Yes, full support for OS X is in our top priority list. We have preliminary support for OS X (without VPE - Visual Page Editor) and we will add VPE at next major release time frame (which is few months from now) Best, Igor.
  78. This is great news - Exadel has always had a great product for JSF development (the lack of OS X support is unfortunate, however), and I'm excited to see where the product goes after the partnership with JBoss. The feature I think would be most useful for JSF/Seam development is allowing the view layer to participate in refactoring operations - ie, if I refactor a method name on a managed bean, I have the option of having that changed in all the xhtml pages it is referenced. Does anyone know if Exadel Studio Pro/Red Hat Developer Studio already supports this or will support it in the future? I've been trying all morning to download a trial copy to see the new features, but it looks like everyone else had the same idea :)
  79. The feature I think would be most useful for JSF/Seam development is allowing the view layer to participate in refactoring operations - ie, if I refactor a method name on a managed bean, I have the option of having that changed in all the xhtml pages it is referenced.
    Yes, we are prioritizing EL navigation/search/refactoring/autocomplete/errors/quickfix for both JSF managed beans and Seam components. A lot of this is already in the Exadel codebase. Note that this goes beyond just the view, including other Seam artefacts such as jBPM orchestration, pages.xml, components.xml, etc.
  80. The feature I think would be most useful for JSF/Seam development is allowing the view layer to participate in refactoring operations - ie, if I refactor a method name on a managed bean, I have the option of having that changed in all the xhtml pages it is referenced.
    Hi there, Actually, with SeamTools for Dreamweaver you can already do this. It supports site-wide JSF EL validation, and you can run a global find/replace to fix EL problems. http://www.jsftoolbox.com/products/seam Ian -- JavaServer Faces for Dreamweaver http://www.jsftoolbox.com
  81. seeing as how Exadel is eclipse based, I don't suppose you guys have it in your plans to develope the equivalent for netbeans platform do you?
  82. If you're interested, check out my blog here: http://blog.hibernate.org/cgi-bin/blosxom.cgi/2007/03/05#exadeljboss Or, come to the tutorial at 1PM at Eclipsecon today (or come by the booth).
  83. tutorial at 1PM at Eclipsecon[ Go to top ]

    Any chance this could get recorded and made available via internet? Further: congratulation - I'm looking forward to enjoy this together with Seam. Just don't waste any time with the visual stuff until content & refactoring assist, which is IMHO much more important, really work.
  84. Congratulations on this move, Gaving (and Red Hat). Java has a lot of interesting and world-class APIs and libraries, but they rarely come with the sort of integrated dev tools that allow them to be used at maximum productivity. I am glad to see Red Hat is focused on delivering exactly this type of integrated experience for developers.
  85. Oops, I meant Gavin...not Gaving (nice Viking name, though) :-)
  86. Congratulations on this move, Gaving (and Red Hat).
    Don't congratulate me, I'm not the one who worked on this deal. If anyone at JBoss deserves thanks, it is Ram Venkataraman.
  87. True. But I am just excited to see someone have a dedicated vision to bring Ajax-enabled JSF (for UI) with Seam (for business logic) and JPA (for DB access) into one common development environment in a way that maximizes productivity.
  88. I wonder if this explains why BEA is now selling their $899 BEA Workshop Studio for $99 until March 23? I've been wanting to try BEA/Nitrox for some time but couldn't justify the $899 price. Ain't competition great! Here's the advertisement from the February 23, 2007 EclipseZone: Get the #1 Commercial Eclipse tool for $99 until March 23rd! We'd like to thank the community for voting BEA Workshop Studio the #1 Commercial Eclipse IDE in 2006 with a online-only promotional pricing of $99.00 USD, support not included. Find out how unique features like Spring artifact generation from EJB3-Hibernate, and AppXRay™ make this the #1 tool on the market. Buy it now using promotional code: TSSpecial99
  89. I wonder if this explains why BEA is now selling their $899 BEA Workshop Studio for $99 until March 23?

    I've been wanting to try BEA/Nitrox for some time but couldn't justify the $899 price.

    Ain't competition great!



    Here's the advertisement from the February 23, 2007 EclipseZone:

    Get the #1 Commercial Eclipse tool for $99 until March 23rd!

    We'd like to thank the community for voting BEA Workshop Studio the #1 Commercial Eclipse IDE in 2006 with a online-only promotional pricing of $99.00 USD, support not included. Find out how unique features like Spring artifact generation from EJB3-Hibernate, and AppXRay™ make this the #1 tool on the market.

    Buy it now using promotional code: Special$99.00
    How is Nitrox btw. 99$ is even a price I would consider (since I am working mostly privately in the JSF and JPA space I am on a budget here)
  90. I haven't had a chance to use BEA Workshop Studio/Nitrox yet. A year ago I looked for reviews comparing Nitrox to Exadel Studio Pro, but found nothing comparing the two. My current project uses Adobe Flex 2.0 so it will be a while before I get to use BEA/Nitrox on a real project, but for $99 I'll buy it now.
  91. can u CPL please?[ Go to top ]

    hi all,and congrates to JBOSS ok,i know that it,s ur assets and it's completely ur rights to do what u want with it ,but in order to use it (my company) it has to be an apache friendly licence (oh... lawyers) and as i know, the CPL has the same spirit as LGPL so can i ask u to consider a switch? actually if u ask the public , alot will have the same request thanx in advance joe
  92. Re: can u CPL please?[ Go to top ]

    Hi Joe, Sorry, but that will not happen for the new tooling. The GPL-based licenses is there to make sure it stays in the opensource space and won't be hijacked by companies that leaches on the good faiths in opensource. JBoss and hence Red Hat have had great sucess with keeping software available as opensource by using the LGPL license for projects like JBoss AS, Hibernate, Seam, etc. and it has great adoption. p.s. you do know that the next version of Java is being made available under GPL; will that also prevent your company from developing java based software ? /max
  93. Re: can u CPL please?[ Go to top ]

    p.s. you do know that the next version of Java is being made available under GPL; will that also prevent your company from developing java based software ?

    /max
    Correction, Java is being made available under a couple different licenses - one which is GPL.
  94. Re: can u CPL please?[ Go to top ]

    Yes, but none of them is Apache like as the poster initially implied as a requirement to use software ;)
  95. Re: can u CPL please?[ Go to top ]

    Yes, but none of them is Apache like as the poster initially implied as a requirement to use software ;)
    And that's still wrong. Obviously, his company would not be using Java if the requirement was Apache-like license.
  96. Re: can u CPL please?[ Go to top ]

    Yes, but none of them is Apache like as the poster initially implied as a requirement to use software ;)


    And that's still wrong. Obviously, his company would not be using Java if the requirement was Apache-like license.
    Original quote from the original poster was:
    in order to use it (my company) it has to be an apache friendly licence
    Of course, there is absolutely no reason to avoid the use of GPL tooling. The license of the toolset is in no way viral to your code.
  97. Re: can u CPL please?[ Go to top ]

    Yes, but none of them is Apache like as the poster initially implied as a requirement to use software ;)


    And that's still wrong. Obviously, his company would not be using Java if the requirement was Apache-like license.


    Original quote from the original poster was:

    in order to use it (my company) it has to be an apache friendly licence
    "It" does not refer to Java. Because if it did, then his company wouldn't be using Java.


    Of course, there is absolutely no reason to avoid the use of GPL tooling. The license of the toolset is in no way viral to your code.
    I find it pretty silly, but that doesn't change the fact that Java will be under a couple licenses and not just a GPL license.
  98. Re: can u CPL please?[ Go to top ]

    hi dear i didn't men the eclipse based studio, it is a tool and u may use it but will never distribute it (so no viral effect) if u like u can GPL it or make it any thing ,that does not affect me, i mean the ajax4jsf and richfaces which required to b bundled with the final product, considering java, its dual license and we use it under the binary license so no viral effect of the GPL is applied note: personally ,i am not against the GPL or any license,as i said in my first post ,the software is yours and u can do what u like with it,but the lawyers have another opinion considering the runtime libs we redistribute thanx joe
  99. Re: can u CPL please?[ Go to top ]

    LGPL does not restrict you from distributing your project closed source. Works for Hibernate, Seam and a lot of other major frameworks in Java. You should contact JBoss/Red Hat to get any issues you have resolved ;)
  100. exciting news[ Go to top ]

    I think that the combination of Seam, facelets and now the rich Ajax JSF components and Eclipse plugin are exciting. I hope this will work not only on jBoss server.
  101. Some confusion[ Go to top ]

    Really excited about this announcement, as I've been increasingly frustrated with MyEclipse, but have been turned off by the cost of other solutions. I'm going to start looking at Exadel immediately. However, I'm a little confused at the scope and ultimate licensing situation. Sacha states in his blog entry: "Once fully opensourced, binaries for all of the individual plugins will be made available for free while the "Red Hat Developer Studio" will only be made available as part of a Developer Subscription." What does this mean exactly? What will be the difference between Developer Studio and the individual features/plugins? Differences in functionality, or in support only? Also, is Gavin or Max able to clarify the relationship between the Exadel tools and JBoss IDE at this time? Will JBoss IDE be deprecated in favor of RHDS? Thanks - Eric
  102. Re: Some confusion[ Go to top ]

    Hi Eric, All the plugins that will take part of Red Hat Developer Studio will be available in opensource (we are a opensource company after all ;) The most interesting plugins we will packaged up as eclipse features and be made available at least from an update site. You can get that for free and you can ensemble your own favorite eclipse configuration (but it is then your "headache" to figure out which plugins you want and what work together etc.) The differentatior for RHDS is that it will be available in a integrated and test bundle which is certified against the already supported JBoss/Red Hat runtimes. Releaving you from the headache. So the difference is in support/certification. With respect to JBoss IDE then that project + Exadel Studio Pro is what will end up in RHDS. Thus JBoss IDE and Exadel Studio Pro is both being deprecated in favor of RHDS.
  103. From the desk of Genuitec (creators of MyEclipse) CEO, Maher Masri...
    It's been said that the key to happiness is to set your expectations so low that no matter what happens, it is never a surprise. And, we do our best to do exactly that with respect to the public behavior of many of our competitors. However, the latest astro-turfing in this thread by the JBoss clan failed to clear even the lowest-set bar. You may think that I'm writing this to retaliate, or perhaps defend, Genuitec against the ensuing "Pick on MyEclipse" banter by the JBoss clan in the above comments. No, not really. Being singled out as the IDE to beat in this industry sounded more like a compliment to me than criticism.

    Regarding the announcement itself; it was not a big surprise that RedHat needed a vendor lock-in solution for its application stack. IBM, BEA and Oracle all have their own flavor, so the news doesn't fall in the terribly shocking category. It's also no surprise that: “For its part, Exadel is basically looking for a way to get out of product development and software support and get back to its professional services business.” (The Linux Beacon).

    So why even address this announcement? Because I think the surrounding behavior exposes a much larger issue. I'm writing this because I truly believe many people who wear the open source badge completely miss the intent and spirit behind it. And, in the case of JBoss, even use it as a sharp stick to poke, bully and intimidate those that disagree with them.

    Don't get me wrong, I was one of Mark Fleury's biggest fans when he cashed out of JBoss. But Mark didn't build a company, a brand and a community based solely on intimidation tactics. Mark understood that he had a snow-ball's chance in hell of competing in the Application Server market through a proprietary technology or by protecting content. Mark had to create a pseudo-religious following through the simple notion of enlightened self-interest; we both give a little and win at the end. If enough people believe in the idea, it creates a virtuous cycle that benefits all participants and gives JBoss a large enough lever to move the world.

    Reflecting back on Genuitec's part in this equation, I could not help but highlight our role in feeding this virtuous cycle and helping Mark become a multi-millionaire. So here is a short list:

    • Genuitec was the first company to provide an Eclipse-based application server connector for JBoss, and have shipped more than 4 million downloads for this connector since 2002.
    • Through MyEclipse, Genuitec has shipped more than 3 million downloads for the JBoss Hibernate framework and provided extensive support and tooling for this fledgling technology.
    • Genuitec commissioned a number of training documents, supported a number of distance-learning portals and published a series of tutorials based on using MyEclipse with the JBoss application server.
    • MyEclipse support engineers have answered more than 10,000 questions on how to configure and use the JBoss application server. Many had little to do with how to use MyEclipse itself.

    I could go on, but that is not the intent of this response. And there's nothing altruistic here. Genuitec gladly supported JBoss technologies with our time, money and energy because enough people used them to warrant our attention. We adopted the various technologies such as XDoclet and Hibernate because we believed they had promise. Other IDEs and tooling companies did the same, and in doing so endorsed JBoss and created brand awareness that no marketing department or budget could have ever accomplished alone.

    So, you can imagine my surprise when the partnership announcement by RedHat quickly degenerated into finger-pointing and name calling all under the guise of the "purity" of open source. The conversation became even more surreal as the debate raged over what open source license would provide more protection from adopters that "leech" off the open-source code base. Talk about penny wise and pound foolish. Someone should really pick up the GNU manifesto one more time and realize that people who build tall Cathedrals made out of glass should not be throwing rocks at others.

    But, I'm not completely surprised. History has shown that children almost always squander their inherited fortunes because they did not live in the same conditions that gave rise to their legacy, and Mark Fleury's left-behinds are no different. Children (young or lacking experience) simply don't understand why it is in their best interest to share. They mistake popularity with power, and assume success is based entirely on their own actions. Possessiveness quickly gives rise to behavior that we expect from thugs and school yard bullies.

    In an admittedly sweeping generalization, that could explain the latest finger pointing and name calling. I expected more from people like Gavin King, who should clearly know better. I expected people that tout "Professional open source" should at minimum actually be professional. Apparently, I might have put Gavin on an undeserved pedestal.

    The more interesting conclusion in this discussion, and follow-on news coverage, is RedHat's decision to place all development tools under the GPL license. It worked for the Linux distribution, so why not apply the same approach to development tools? That makes about as much sense as using the same material to build both cars and space shuttles. As an enterprise developer, every line of code written that links to GPL software is now subject to the copy-left viral license and must be made public as the result of any modicum of distribution. So where do I sign up? ;-) I can almost hear the screaming from the legal department, and the mandate for audits and compliance. I can't possibly see how all of this will be attractive for enterprises looking for reliable solutions without a vendor or license lock-in. All done under the banner of protecting the "virtue" of open source.

    My final conclusion in this long reply is simply this: If your business is based on open source, don't bite the hands that feed your success. And, if you don't want others to use your code then don't put it out as open source to begin with. Doing anything else is either plainly disingenuous or naively following the siren's call down a road paved with promise, but only littered with broken dreams.
    - Maher Masri, CEO, Genuitec, LLC