The Angular Mini-Book is a
guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and
deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.
Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.
For book updates, follow @angular_book on Twitter.
The JHipster Mini-Book is a
guide to getting started with hip technologies today: Angular, Bootstrap, and Spring
Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.
This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.
For book updates, follow @jhipster-book on Twitter.
Any idea what the JBoss Announcement will be next Tuesday? Since he's laughing at Oracle, I'm guessing they hired a prominent MyFaces developer - or they've "acquired" a prominent database developer (i.e. PostgreSQL). What's your guess? Will it really be that impressive, or just impressive for JBoss employees?
I finally got around to finishing the Hibernate Relationships tutorial for AppFuse today. This initial version includes a howto for creating the UI with Struts. In the future, I'll add sections for creating the UI with Spring MVC, WebWork, Tapestry and JSF. Those should be easy now that the hard part is done. This is a first cut at this tutorial, so it's likely there's issues, bugs and things I did wrong.
Now it's your turn. If you have a chance, please try it out and let us know how we can improve it.
I have to admit, there's something about Seam that intrigues me. Maybe it's because they put up a really nice-looking demo (I'm a sucker for eye-candy), or maybe it's because it seems to be well documentated, or maybe it's the fact that it's based on J2EE standard technologies (EJB3 and JSF). It could also be that I greatly respect the work of Gavin King (who's always been respectful to me when I asked Hibernate questions back in the day).
It could be the lack of configuration, but I think it's the simplicity that gets me. A POJO (Entity Bean), a Session Bean for your business logic, and a view page (w/ Facelets no less, which is very cool). Other new frameworks this year include Wicket and Stripes. While these frameworks look cool, I really like the idea of a full-stack framework much better (I do use AppFuse after all). Well done Gavin - Seam looks very cool IMO.
On a related note, I upgraded AppFuse to MyFaces 1.1.0 yesterday w/ minimal effort. You can grab the latest from CVS if you'd like to get started with MyFaces quickly.
I've been using Subversion on quite a few projects lately and I have a hard time switching back to CVS. I currently use CVS for most open source projects, particularly AppFuse and Equinox - which I work on the most. A discussion started this morning on the AppFuse Mailing List about moving to Subversion. While I'd love to do this, I'd prefer to do it at java.net - so I don't have to completely abandon our hosted environment there. However, I don't think java.net is planning to offer Subversion anytime soon.
If we move source control to somewhere else, we're pretty much just using it for the mailing list. Then again, the mailing list archive kinda sucks and you can't get it archived by mail-archive.com.
That being said, it might be nice to host everything ourselves. This might allow us to get something like Jive Forums setup. WebWork uses it and it has a pretty cool feature that the mailing list and forums are integrated (messages go to both). While the idea of self-hosting sounds appealing, it also sounds like it might be a lot of work. For hosted SVN options, it seems that there's JavaForge, Codehaus (which I believe is invite-only) and CVSDude. Any other options you know of?
Despite the lack of support and code contributions, it's good to know the Display Tag project is not dead. Fabrizio has been doing a lot of refactoring lately, including Maven 2 integration and support for long lists. Nice work Fabrizio! In addition, it's good to see all the activity on the mailing lists. Thanks to all of you that've been answering questions.
From Ajaxian.com:
AjaxAnywhere is designed to turn any set of existing JSP components into AJAX-aware components without complex JavaScript coding. In contrast to other solutions, AjaxAnywhere is not component-oriented. You will not find here yet another AutoComplete component. Simply separate your web page into multiple zones, and use AjaxAnywhere to refresh only those zones that needs to be updated.
This is one of the few Ajax projects I've seen that looks to provide a lot of value w/o a whole lot of work. Notice how much it enhances JSF with this cool demo.
This morning, I did some comparisons between Jetty 5.1.5rc1, Tomcat 5.5.9 and Resin 3.0.14 (OS version). I ran AppFuse's "test-canoo" target, which tests all the JSPs using Canoo WebTest. I did this as a Servlet 2.4 application, and had to tweak some stuff in my web.xml to make it work on Jetty and Resin. Nothing big, just stuff that Tomcat let pass through and these servers didn't. One interesting thing to note that Resin requires you to use "http://java.sun.com/jstl/fmt" for JSTL's "fmt" tag URI, while Jetty and Tomcat require "http://java.sun.com/jstl/fmt_rt". This is with Resin's "fast-jstl" turned off - b/c everything blows up if it's turned on (I don't feel like coding my JSTL to Resin's standards, that's why I turn it off).
Below is a list of the average time it took to run "test-canoo" after I ran it once to compile all the JSPs.
In addition, I tested how long it took for each server to startup - including the initialization of AppFuse.
So what does all this mean? A number of things:
Currently, the default web framework in AppFuse is Struts. It's nothing fancy like Shale or Struts Ti, but rather Struts Classic. Even though Struts is not dead it's a pain in the ass to work with compared to other MVC frameworks like Spring MVC and WebWork. Yesterday, on the AppFuse Mailing List, I kicked off an informal poll about switching to a different default web framework. I think most of the people that choose Struts w/ AppFuse are choosing it b/c it's the default. Making another framework the default would likely same quite a few users a lot of headaches.
So which one should I make the default? Here's my thoughts from the mailing list thread:
I like Spring MVC and WebWork better than Struts, but I believe that
WebWork is much easier to understand and develop with. Unfortunately,
it's not well documented or marketed, so it's a bit difficult when you
run into snags. Of course, if you contact the user community via
forums or e-mail, answers flow quickly.
...
I'd like to use the framework that's simplest to
understand. Right now, in my eyes, that's WebWork. I think JSF and
Tapestry are excellent too (as component-based frameworks), but
Tapestry's learning curve is difficult and JSF has a lot of issues
(like everything is a post). Hopefully things will get better with
JSF 1.2, but it's probably another 6 months before MyFaces supports
1.2 - let alone the app servers.
...
Maybe we should just drop Struts altogether - or replace it with
Struts Ti? Unfortunately, it'll probably be a while before it's ready
for production (I doubt it's that useable now).
Of course, if a WebWork Book was out - this move would be a lot easier. I did talk to Patrick Lightbody on IM yesterday and he said "it's done" and supposedly he has copies, but I haven't seen anything on the WebWork Blog to prove this.
A related question: how much would it hurt AppFuse if I dropped Struts altogether and went with something like Wicket instead? I'd like to keep that cap at 5 web frameworks. If I dropped Struts and added Wicket, I might lose potential users, which might not be a bad thing. 
Looks like I've been biled again. Unlike the last time, this time Hani doesn't offer any specifics, he merely says that my OSS efforts don't do anything other than the "very very basics".
Java, specifically, goes a long way towards ramming down a set of design principles. Said principles are followed fairly blindly by most practitioners. The OSS world is awash with examples of people who have read the right books, but have absolutely no skill or talent at conceptualising or grokking the underlying principles behind the books. To them, the design pattern is an end goal, not a tool. To pick one example (out of thousands), look at Matt Raible's OSS efforts. It has inheritance! It uses PATTERNS! It is LIGHTWEIGHT! Yet, I'd argue that it's very badly designed (if you don't believe me, just try getting it to do anything other than the very very basics.)
I'm assuming that Hani is speaking about AppFuse and Equinox, because my other efforts in OSS are minimal (Roller, Display Tag, XDoclet and Struts Menu). The reason I'm writing this post is because I'm curious to know what Hani tried to do that didn't work? Was it AppFuse/Equinox that failed? Or was it the underlying framework? Did he try to do indexed properties with WebWork or modify build.xml to deploy to Orion? Is the feature he's looking for something we can fix?
As a defense of my use of patterns, lightweight containers, etc. - it's not so much my doing that these happen to exist - they're more of a reflection on what user's want. It's a problem with Java developers in general - if you're not using patterns - users want to know why. Furthermore, most of the J2EE patterns in AppFuse are from the underlying frameworks, not from anything that I did.
As far as the design of AppFuse, I agree it could use some work. There's a lot of stuff in AppFuse that I don't use - so when I start a project with it - I usually rip out about 20-30% percent of it's features b/c I won't use them. Unfortunately, it's not that easy for others to do this b/c they don't know what they'll break if they remove a bunch of stuff. I'd like to move to a more modular, plug-in type architecture - but I have a feeling that that's the path to over-engineering. Even so, it would be pretty cool if it was possible to turn on/off features (even the use of a particular web framework) by changing a properties file.
What is it about WebWork that makes it so hard to write books about? I remember talking to Kris Thompson (a.k.a. the guy that quit blogging) last summer about WebWork in Action. At that time, it was "almost done". Over a year later and it's still "due out next month" (or is it done?). Almost as bad is Matthew Porter's WebWork Live, which was started late last year. I remember Matthew saying he expected to finish the initial version in March - and there's still not an ERP almost 10 months later.
Here's my guess: the Manning book has been done for months, but the publishing process takes months. As for Porter, my guess is he's too busy providing outstanding support at Contegix to work on the book. Any good conspiracy theories out there? Maybe WebWork has too many patterns that need to be documented?
