On Thu, 5 Jun 2003, Vic Cekvenich wrote:
> Date: Thu, 05 Jun 2003 17:20:26 -0400 > From: Vic Cekvenich <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces > > (hope this does not detract from more important issues) > > http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces > > To the extent that this implies Struts _should_ integrate to Sun JSF, I > do not like it. > > This is quite different than JSTL, which was an Apache License. > Maybe there should be integrations posted in cvs apache to Expresso, > ScioWorks (they integrate more to Struts), lots of Vendor IDE and J2EE > servers have integration to Struts; maybe their integration jar?s should > be posted on non Apache domain, lots of software on sf.net has Apache > license. > Vic, the tenor of your question implies that you don't understand a few things about Java software and licensing. From watching a wide variety of conversations floating arount the 'net, it seems you are not alone. Here's a few thoughts that should help illuniate the situation. This is a pretty short summary -- more detailed information can be gathered from the Java Community Process web site: http://jcp.org The most important thing to understand is the difference between the licenses for Java *specifications* (i.e. the functionality that any product claiming to be complaint must provide) and *implementations* of those specifications. Java Specifications are created under the auspices of the Java Community Process (JCP), and you can keep track of progress at at <http://jcp.org>. JavaServer Faces, in particular, is being developed under JSR-127. When a JSR is originally proposed, the proposer (Sun, in the case of JSR-127) must also provide the proposed business terms that they anticipate the specification will be licensed under, once it is complete. It is, and has always been Sun's intention, that the terms for JSR-127 would be substantially similar to the terms that resulted from the discussions with Apache last year -- indeed, you will probably remember substantial discussions last year between Apache (and others) and Sun to address the licensing issues for Java technology, particular with respect to open source implementations. Jakarta Web Site Info About The Agreement: http://jakarta.apache.org/news/jspa-agreement.html Sun's Letter Of Intent: http://jcp.org/aboutJava/communityprocess/announce/LetterofIntent.html The upshot of this is that, over a *year* ago, Sun agreed to modify the license terms for many JSRs, and included funding scholarships for non profit open source organizations that wish to prove their implementations are compatible with the specification. JavaServer Faces (JSR-127) is specifically listed as one of the Sun-led JSRs which would have business terms that support the ability for open source organizations to create an implementation that is compatible. Now, remember -- a specification is *not* software -- it is a bunch of *requirements* that any software wanting to say that it "implements JavaServer Faces" must adhere to. So, how does anyone know that a Java specification can actually, in fact, be implemented in a way that meets all the specification requirements? And, how can you tell if any specific implementation does, in fact, meet the requirements? The JCP process requires that the specification lead (again, Sun, in this particular case) must also supply a Reference Implementation (RI), to prove that one can actually create a compliant implementation, and a Technology Compatibility Kit (TCK) that can be used to test the compliance of *any* implementation. Currently, the RI that Sun offers for JavaServer Faces is available under an "early access" license (since the spec isn't final, no redistribution is allowed -- did you notice that the struts-faces distribution doesn't include the jsf-api.jar and jsf-ri.jar classes? this is why -- I don't get to break the rules even though I'm co-spec lead, and am heavily involved in the RI implementation and testing :-). How the RI is licensed is pretty much up to the spec lead and the expert group. Note, however, that the RI is very unlikely to be the only implementation of JavaServer Faces that ever exists. In fact, because of the Apache agreement, it's perfectly feasible for any open source group to decide that they want to create an open source implementation of JavaServer Faces, and pass the TCKs so that you can prove it. Sun will even offer assistance to qualified non-profit organizations that wish to attempt this. I know of at least one open source implementation effort that was started over at SourceForge; there's no restriction on how many implementations there are in the world. This is exactly analogous to the way that the world is with servlet and JSP. For example, the Servlet 2.3 (and JSP 1.2) specifications were created under JSR-53 in the JCP process. (For the next round, Servlet 2.4 is being developed in JSR-154, and JSP 2.0 is being developed in JSR-152). Sun was and is the spec lead of these specs, and provides a reference implementation -- the J2EE RI -- which (for the servlet and JSP specs) happens to incorporate code that comes from Tomcat. But, is Tomcat the only implementation of the Servlet and JSP specs in the world? Not by any stretch of the imagination. There are multiple open source and closed source ipmlementations -- in fact, every J2EE app server needs to provide an implementation of these APIs in order to meet the overall J2EE requirements. Some incorporate pieces of Tomcat; some write their own; some incorporate third party code from other suppliers). But *all* of those implementations need to pass the TCKs in order to claim that they are actually implementations of the corresponding specs. In short, there is no such thing as "open sourcing" the JavaServer Faces specification itself, because it's not software. There is absolutely an ability for multiple implementations to be created (open source or not doesn't matter -- compliance matters). Or, if you don't believe that JavaServer Faces is the right answer to the "web application user interface components" technology problem, then you can go implement your own APIs and your own framework -- that's fine, and in that case nothing about JavaServer Faces need concern you (except for the fact that more than a few software producers *do* see to care about it, so your cool widget library is going to have some serious competition :-). A couple of points about the Struts-Faces interface library in particular might also be of interest. * If you take a glance at the build.xml file (contrib/struts-faces/build.xml), you will note that the RI classes are *not* in the compile time classpath. Only the API classes are included. That means this library will work portably on any implementation of the JavaServer Faces APIs, in the same way that it compiles against a servlet.jar from anywhere and has no dependence on Tomcat or any other container. As soon as there are other implementations of JavaServer Faces around, this library will work just fine (as long as they implement JavaServer Faces correctly :-). * You will also note that the jsf-api.jar and jsf-ri.jar classes are not included in the distribution. As I mentioned above, the EA license prohibits redistribution (because it's not final yet), and that rule applies to me just like it does to everybody else. * One of the reasons that Struts has become popular is that people seem pretty confident that their investment in learning and using the technology will be protected for long enough to earn back the investment cost. For Struts, one of the things I felt strongly about doing was ensuring that Struts could interoperate with the latest emerging technologies like JSTL and JavaServer Faces. Indeed, I proved (by doing it) that you could migrate an existing Struts app, one page at a time, to use JavaServer Faces and JSTL tags (instead of the corresponding Struts tags), with nearly *zero* changes to the back end business logic. MVC really works -- what a concept :-). * The lesson I learned from this, and that everyone else should to, is that your investment in existing applications based on Struts is in very good hands -- you are not going to be forced to migrate away from it any time soon in order to take advantage of the latest and greatest Java technologies. * An additional lesson, though, is for the Struts developers ourselves. We were one of the pioneers in the webapp framework space, and have arguably been the most successful. But we were not alone. Indeed, my spreadsheet of various implementations of UI component and web app framework architectures (just the ones in Java) has roughtly fifty entries in it. That's way too many for tools to support; it's way too many for potential users to evaluate; it's way too confusing to the market; and it's way too weak for Java as a whole in the face of a determined competitor who feels threatened by the success of Java technologies at every turn. * Every technology goes through a lifecycle of innovation, followed by popularization, followed (often, but quite often in the Java world) by standardization, followed by commoditization. We're rapidly approaching the standardization point in the webapp UI component space -- and it's become abundantly clear to me how many serious players in the world have been waiting for this, so that they can build products and packages and libraries and tools on top of a standard (instead of each trying to pitch their own APIs). * Once there are robust, mature, implementations of a final 1.0 version of JavaServer Faces (and I know for a fact that there will be more than one), it's decision time for application developers who are currently using what will then become "non-standard" approaches to that API. For Struts users, I have the following recommendations: - For your existing apps, and projects currently in development, continuing to use the Struts HTML tag library is a sensible decision. However, I'd still recommend using JSTL tags instead of their Struts counterparts (Struts offers an integration library for JSTL tag usage too :-). - If your app deployment plans are further off, and/or you haven't started picking your base technologies yet, I would suggest that using the current Struts HTML tags is not a very good idea. You will be much better off investigating using JavaServer Faces component libraries instead -- not only are they much more powerful than the Struts tags, you'll be able to use component libraries from *anyone*, just as you can integrate JSP custom tag libraries from anyone today. As for whether JavaServer Faces is good or bad technology ... I'm willing to let the market answer that question. :-). But I can guarantee you that there are already millions and millions of client devices that can already utilize JavaServer Faces based applications, versus hundreds? thousands? that can use cool things like XForms or XUL today. Of course, even that comment oversimplifies things a little too much, because it leaves the impression that JavaServer Faces is just for HTML based browsers. That's not the case at all -- if you're at JavaOne, you'll enjoy seeing an SVG based rendering of the same application (with zero changes to the back end logic). Creating renderkits for wireless devices (or even rendering XUL and XForms if you like -- there's a small sample XUL renderkit in the "demos" directory). I can tell you one thing, though ... working on JavaServer Faces has already had very positive impacts on *my* professional career. :-) > Craig as original author of Struts, deservers lots of latitude in what > he does. > > I still don?t like it. If there is a president I am unaware of, I > withdraw my objection. Does Struts run on more than one servlet/JSP container? Yes. Does it run only on servlet/JSP containers that are open source? No. Why would you believe that things should be different for a different Java specification? > > .V > > ps: I have personal belief that JSF hype will be followed by search for > the guilty, punishment of the innocent and praise for non participant. > My preference is Apache Struts takes no part of Sun JSF. > It's my personal belief that Vic doesn't speak for Apache, or for the Struts developer community, on this topic :-). Vic is not, in fact, a part of either community that he makes this recommendation to. I wish he would stick to speaking for himself. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
