On Fri, Nov 27, 2009 at 1:00 AM, Alessandro Bottoni <alexbott...@gmail.com>wrote:
> Matt Raible ha scritto: > > AppFuse 3 will consist of services and UI, as separate modules. Services > > will be RESTful and will likely consist of Rails, Grails and Java (CXF > > or Jersey). The UI options will be GWT and Flex. It's quite a departure > > from previous versions, but I think SOFEA is here to stay and I'd like > > AppFuse to be the kickstart for it. > > I read your "letter to the appfuse users" as well > (http://raibledesigns.com/rd/entry/a_letter_to_the_appfuse) and I was > quite impressed by a couple of your statements. > > In your letter, you say: > > "I realize there's many full-stack frameworks that do the same thing as > AppFuse with less code. Examples include Ruby on Rails, Grails, Seam, > Spring Roo and the Play framework. However, there seems to be quite a > few folks that continue to use AppFuse and it stills serves the > community as a nice example of how to integrate frameworks. Furthermore, > it helps me keep up with the latest framework releases, their quirks and > issues that happen when you try to integrate them." > > And now, in this interview, you confirm that the next generation of > AppFuse will be completely different from the existing one, based of > SOA/SOFEA concepts and tools. > > It looks like you consider the current design of AppFuse as obsolete and > deemed to give way to others, more modern, SOFEA-based, solutions. > The current design is not obsolete, it just doesn't fit with the types of applications I'm developing these days. In order for me to stay motivated about working on AppFuse, it helps if I'm using the technologies it uses. > > That sound as bad news for us: if even you, who are the creator of > AppFuse, are convinced that RoR or Grails are the "right tools for the > task", why anybody else should ever use AppFuse (or Tapestry or any > other old-fashioned tool, for that matter) in a real-world project? > Good question. When I created AppFuse, these types of tools didn't exist and all we did was integrate frameworks together and show developers how to develop functionality with it. CRUD generation didn't exist until I was inspired to create it from one of the first Rails videos. If someone else handles CRUD generation for certain parts of things, that's one less thing we have to do. > > Would not be much more sensible to use those best-of-the-breed tools > (RoR or Grails) and forget about AppFuse since now? > Yes, that is certainly an option. AppFuse has always been designed to eliminate the first week of any project. So instead of having to setup your database, configure authentication and user management, it's already done for you. Neither Grails nor Rails ship with this type of functionality. Sure, you can add it with some plugins and probably have it at the end of 1-2 days, but its not out-of-the-box. > > Even worse: what will happen to the guys that are using the current > generation of AppFuse for real-world applications? Will they lose any > support in the near future? > If we're changing directions in a future version, there's a always a chance we'll stop supporting the old version. Look at AppFuse 1.x. I said for years I'd release 1.9.5, but after a while I decided not to because I didn't want to work with Ant anymore. If I'm working with Flex and GWT in AppFuse 3.0, there's a chance I won't want to work with JSF or Spring anymore and won't be as motivated to stay up-to-date on those technologies and provide support. However, you should still be able to get support from the projects themselves. AppFuse only configures things for you, it doesn't provide much functionality or magic way of doing things on top of that. > > All of these dubts sums up to a simple question: can we (end-users and > programmers) be confident in the fact that the current generation of > AppFuse will be developed and supported in the next two-four years? > Yes, you can be assured that I will answer questions on this mailing list in the future. However, if I get hit by a bus, there's a good chance this project dies. The only way that changes is if more developers get involved in developing and maintaining the project. > > Should you get full-time busy on AppFuse 3.0, will someone else work on > AppFuse 2.X? > Probably not - it didn't work that way with 1.x. Also, there's a good chance that things won't happen as fast as I'd like them to. With a full-time job, being a single parent and ski season coming up, I'll be lucky if I complete AppFuse 2.1 by Spring 2010. That means that AppFuse 3 probably won't have any sort of milestone release until late next year. > > I apologize for raising such a sensitive questions but I'm starting a > new project based on AppFuse 2.1 and I have to know how far is my > technological horizon. > As mentioned earlier, we only integrate the libraries - so you should still be able to get support on all AppFuse's underlying frameworks from the projects themselves. Also, there's a chance we won't eliminate the libraries/setup that currently exist, we'll just add to them. Cheers, Matt > > CU > > PS: That said, let me say also that I completely agree with you on the > fact that SOFEA is here to stay. The best thing that can happen to > AppFuse is to adopt/integrate/support a few SOFEA concepts and tools, in > a way or another. > > -- > > Alessandro Bottoni > Website: http://www.alessandrobottoni.it/ > > "Things should be as simple as possible, but not simpler." > -- Albert Einstein > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@appfuse.dev.java.net > For additional commands, e-mail: users-h...@appfuse.dev.java.net >
