Discussions

News: Project Able: a complete Java web stack

  1. Project Able: a complete Java web stack (19 messages)

    Patrick Lightbody, one of the primary maintainers of Struts Action Framework (née WebWork 2), has announced Project Able, a "complete Java web stack." He says that Able is similar to AppFuse, Trails, and Grails, with the primary differences being reliance on different open source projects (WebWork, Spring, SiteMesh, and iBatis) and emphasis on common patterns.
    Able is not a library. It is not like RIFE or like WebWork or Hibernate. Able is, instead, a starting point for building webapps. The code inside of Able becomes the code in your application. It is meant to be adjusted and mutated as your project goes on. Of course, Able will evolve too, but for the most part your only need for Able will be when you start your work. Some, however, may wish to look at Able as a way to streamline their existing web development process. But most will checkout Able from SVN the day they start their project, and then never look back. Part of the reason I'm doing this is because the more and more I've been using (and developing) opensource, the more I've found it is easier to simply grab a copy of the latest release of Library X and either fork it or provide hooks in to little known APIs that allow me to control the inner guts. At the end of the day, I've found that if I had simply just had the entire project's code checked in to my project, I would have been more efficient. In many ways, this is like code generation. That isn't to say that there aren't libraries that Able depends on (there are), but rather the extensions done to those libraries aren't delivered as another library, but rather source code you are free to modify and improve over time.
    Able is currently only in the OpenSymphony SVN repository (accessible via https://svn.opensymphony.com/svn/sandbox/able). There are detailed instructions on getting started with Able on Pat's blog entry, and any users are encouraged to offer suggestions or code.

    Threaded Messages (19)

  2. What's the purpose?[ Go to top ]

    What's the purpose of this project? How is it different than Appfuse? I am not criticizing, just asking a question. How does it resolve all the dependencies? Do you depend on the Able releases once you start using? Why not use RIFE (just an example) which is a complete stack in itself instead of patching a bunch of different projects?
  3. The purpose[ Go to top ]

    Atif, I think some of the questions are addressed in my blog entry, but I'll try to elaborate a bit more here: The major difference with AppFuse is that it Able is a single, focussed stack whereas AppFuse is a collection of choices to build your own custom stack. AppFuse is fantastic and I actually hope at one point we can join parts or all of Able with AppFuse (we've already discussed it and hope to explore it in the future). In addition to that, Able focusses less on the stack components (AppFuse has a lot more optional choices, such as XFire integration), and more on practices/patterns that I've found to be very handy when developing web applications. For example, Able includes an upgrade framework and a concept of build profiles. None of it is "revolutionary" by any means. Rather, it is is simply an attempt to take a starting point I've used for a few projects recently and standardize it in to something I can share. As for RIFE - I'd say both RIFE and Trails are the most similar to Able. Although, to be a perfect comparison, RIFE/Jumpstart is really the closest to Able, since Able also encourages a build system and project structure. Overall, if you prefer the style used by RIFE, you're probably best using RIFE for your entire stack. While I am currently using RIFE in one project, I happen to prefer the style ingrained in to Able over the RIFE style. At the end of the day, the Java community is large enough for a few projects like this to exist. RIFE is a great monolithic stack. Grails is a good framework if you wish to use a more dynamic language. AppFuse is a good way to get started and mix-n-match different libraries. Trails is a good stack for component-based frameworks. But there hasn't been any real attempt to make a complete stack for an action-based framework, so I put together Able to fill that gap.
  4. Re: The purpose[ Go to top ]

    I should just follow up with myself re: my comment about RIFE being "monolithic". I don't mean that in a bad way - I mean it is most like Rails in that it is a single library that provides end-to-end solutions for webapps. However, it would be unfair to cast RIFE in a light that implies you _must_ use all parts of the layers. In fact, you can use just parts of it, or plug in alternatives (such as iBatis) as you see fit.
  5. Re: The purpose[ Go to top ]

    Makes sense. Thanks for responding. There is definitely scope in Java community for new projects as long as they have a well defined goal.
  6. Re: The purpose[ Go to top ]

    There hasn't been any real attempt to make a complete stack for an action-based framework, so I put together Able to fill that gap.
    In many ways, this is like code generation. That isn't to say that there aren't libraries that Able depends on (there are), but rather the extensions done to those libraries aren't delivered as another library, but rather source code you are free to modify and improve over time.
    What is the difference between a "full stack" and a proper blank.war?
  7. Able vs. blank.war?[ Go to top ]

    What is the difference between a "full stack" and a proper blank.war?
    Well, if we are talking about the basic struts 1.x blank.war, Able actually seems to be able to do something useful.
  8. Re: Able vs. blank.war?[ Go to top ]

    What is the difference between a "full stack" and a proper blank.war?

    Well, if we are talking about the basic struts 1.x blank.war, Able actually seems to be able to do something useful.
    No, I meant a proper blank.war.
  9. Re: What's the purpose?[ Go to top ]

    Why not use RIFE (just an example) which is a complete stack in itself instead of patching a bunch of different projects?
    To get a sense of the difference in approaches, you might want to read the interview that got published with me at artima.com today: http://www.artima.com/lejava/articles/rife.html I think it gives a good overview of what the goals are with RIFE, which should make it easier to compare against other solutions like Able.
  10. Nice try .... but no thanks[ Go to top ]

    I find this a desperate attempt, a marketing attempt trying to stimulate the use of Struts/Webwork. This is simular to having a good designed technology example (Spring based, RIA based or whatever... ). I don't see this as a result of a study / personal experience telling us / him that their aren't any qualitative example on using technologies. Struts/WebWork guys just need to realize that they indeed once had a glorious time, people adored them, but like said in one of my favorit books of Stephen King (Dark Tower) ... The world has moved on. Better things have emerged, yes they have been partialy based upon your foundation, but still ... its time to move on. Come with something new, dazle our minds, make us believe the future is bright and shiny ... but don't give us some marketing scam hidden in an old concept called "A complete Java web stack". Teach us how Struts/ WebWork can be used to create Rich Internet Applications, how it can help us bring Domain Driven Design to a higher level, teach us how we can boost web development, how we can make things more maintanable. And this reaches furher than bringing us 'yet another boring quickstart toolkit/guide/concept or whatever'. Another problem with these tookits/quickstarts is the fact that project are complex, I wish I could use simple quickstart toolkits, but projects are still hard and complex. Why ... because we don't live on an island when we develop.... there is always something out there that makes our life a little bit harder, not fiction, plain reality :-D Amaze us once again as you dit before... let us see that the World has moved ON!!! My 2 cents ;-)
  11. I find this a desperate attempt, a marketing attempt trying to stimulate the use of Struts/Webwork.
    A) There's nothing desparate about it. B) When was it a bad thing for Open Source projects to market themselves? C) I'll take stuff that is proven and that works over the buzzwords of the day. My $0.02
  12. Nice[ Go to top ]

    Nice work Patrick, this looks like a pretty tasty package to get started with. Kudos to you :)
  13. I just don't get it...[ Go to top ]

    Nice work Patrick, this looks like a pretty tasty package to get started with. Kudos to you :)
    I just do not get it, what is so nice, new or innovating about it? The concept has been done over and over and over again ... we already have like a zillion examples on how to use these technologies together. The only thing cool about it is the 'update framework', that in fact would be a nice topic, all the rest is just old school and has no added value on project startup or management. I think I'm just one of those guys who believes that one size does NOT fit all :-) Grtz ps. To Joseph Ottinger: This is no critic on your behalf, I like the fact that people find time to invest in open source project, I realy do. I wish I could! I just feels like something old wrapped in a new package. I believe that taking the update framework outside Able and heavily invest in that would pay off more and give you the respect you deserve!
  14. Oeps my mistake[ Go to top ]

    ps. To Joseph Ottinger: This is no critic on your behalf, I like the fact that people find time to invest in open source project, I realy do. I wish I could! I just feels like something old wrapped in a new package. I believe that taking the update framework outside Able and heavily invest in that would pay off more and give you the respect you deserve!
    Sorry, this should be Patrick Lightbody, stupid copy/paste :-)
  15. Re: I just don't get it...[ Go to top ]

    I think that even though I would prefer to think it's not true, not all projects have the strongest development lead possible available to help them get started. Normally someone(s) in a more lead role might go out and evaluate various projects, slowly creating an environment to host your new project in...At the end they should be able to say: -) Here's our layer, this is how you use it. -) This is how we're doing unit tests. -) This is how we're doing builds/etc.. For some this is easy and trivial, for others it's not as straightforward sounding. They just want to get going and don't care about being diligent. Though I hope this isn't the only group that would find it useful, it is a good example of a good use case where this sort of stack makes sense. With all the benefits RoR gives in this regard it makes sense to support people providing the same sort of stack for java. (of course I'd much rather see Tapestry being in the web stack, but that's not relevant to this discussion..)
    Nice work Patrick, this looks like a pretty tasty package to get started with. Kudos to you :)


    I just do not get it, what is so nice, new or innovating about it? The concept has been done over and over and over again ... we already have like a zillion examples on how to use these technologies together.

    The only thing cool about it is the 'update framework', that in fact would be a nice topic, all the rest is just old school and has no added value on project startup or management.

    I think I'm just one of those guys who believes that one size does NOT fit all :-)

    Grtz

    ps. To Joseph Ottinger: This is no critic on your behalf, I like the fact that people find time to invest in open source project, I realy do. I wish I could! I just feels like something old wrapped in a new package. I believe that taking the update framework outside Able and heavily invest in that would pay off more and give you the respect you deserve!
  16. How would you compare this to AndroMDA?
  17. How would you compare this to AndroMDA?
    Like apples and oranges :-)
  18. Aaron, Unfortunately, I'm not familiar with AndroMDA.
  19. AndroMDA includes a project builder (project setup, project start up) but this is *only one aspect* in AndroMDA. The main thing in AndroMDA is the Model Driven application development (= MDA = Model Driven Architecture). The whole idea is quite simple: -> We want to increase our abstraction level in building applications -> We build UML models which are completely implementation technologies *independent*. -> Thus we want to make our applications independent of the implementation technologies -> you can make your own choice: Struts-JSP, Enhydra-XMLC, EJB, Hibernate, Spring, Java, .NET, PHP, ... from *one and only one UML model* (not yet 100% automatically, but slowly and surely ;-) and of course you can help to support AndroMDA team to be able to offer more implementation technologies). -> If you follow TSS discussions very well, you'll see that we get some new web frameworks every week ;-) So, the reason is very clear why we want to have MDA and AndroMDA. We just don't want to put our domain knowledge in a technology dependent implementation which changes very fast. Just think about EJB 1.x, 2.x, ... it's just 5, 6 years ago! Do you want to *rewrite* the whole application just because there are another sexy implementation technologies? Nope. All projects mentioned in this thread are "only" a project start up - project builder - project setup - assistant/wizard - what so ever - which integrate other Open Source Java stacks. So, clearly to say, they are one step "behind" the idea of AndroMDA. To see the real power of AndroMDA check out my article: http://www.jaxmagazine.com/itr/news/psecom,id,21908,nodeid,146.html Hope this helps! Lofi.
  20. AndroMDA and AppFuse are doing great. Both are meant to simplify app dev (once you're familiar with the tools, of course). AndroMDA is +1 since it's "still usable after the code-gen/startup/preparation". Is there any known attempt to integrate the best of both worlds?