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.
I would like to thank my wonderful family and my great friends for making my life a blast to live! I'm also thankful for good health and the micro-breweries of Colorado, Montana and Oregon.
I'd also like to thank the blogging community (particlarly you java.blogs gents) for making the web fun again. Now go get some good eats and tell your family I said Hi! 
Just in case you downloaded struts-xdoclet-0.2, there was a classpath issue in the build script that I just fixed.
Are you a developer using Struts? If so, you might want to checkout the Struts Roadmap. You'll notice that in 1.2.x, they plan to Encourage the use of XDoclet and other code generation technologies to streamline development. Cool - but being that's it's been over a year between 1.0 and 1.1 (still not released), I wouln't hold your breath for this. I think Struts would really shine if it could be easily integrated with a persistence mechanism (or framework, whatever you want to call it). Of course, this goes for any UI Framework - the easier it is to develop with, the more fans you'll get. Then again, if you're lucky enough to not have to worry about the persistence layer - who cares!
Kurt emerges from his sabbatical (12 days is a long time in blogsphere) and mentions a little tidbit I'd like to comment on:
Last week I attending a TC JUG meeting where the topic was Struts 1.1: The Good, the Bad and the Ugly.
...
Interestingly the speaker didn't like XDoclet because he felt that on large development teams the config files should be managed outside of the source code during the design phase. Since I have never worked on a large team (not that I won't want to) I don't know if his concern is valid. Interesting comment though.
(I added the bold.) First of all, I have only recently (last 6 months) found XDoclet, and all the projects I've been on (in my entire life) have always had less than 5 coders. I've been on teams as large as 20, but the module I was working on never involved everyone. In my experience, the design phase never really consists of writing very much code or configuration, but rather a bunch of UML diagrams and static HTML prototypes.
I have found (in my brief work on struts-xdoclet) that I need to change values in my web.xml to test different settings (i.e. a servlet's init-param). However, since I'm coding some of these values in my classes, in order to change and test, I have to re-compile and deploy. Of course, I could just change the values in web.xml after I've deployed, but that's just a workaround.
A better solution, which I hope to implement, is to put certain values in my classes as tokens (i.e. @encrypt-password@) and then I can use Ant's replace task to specify this value from the command line. That way, I can set the default in my build.xml file and change it by either 1) specifying the property in build.properties, or 2) specifying it from the command line (i.e. ant -Dencrypt-password=true).
I'd be very interested in hearing anyone's war stories on this topic (managing config files in a large team).
The Struts Committers are thinking of removing the Struts Consultants listing. I've been listed on this page since last year, but it really hasn't done anything for me. I get a few hits per day from it, but I've never got any clients or work from it. My gigs always seem to come the old fashion way - through connections. The reason I'm writing this post is because of a message this morning, from Ted Husted (a Struts Committer):
We originally setup the page because people kept asking. So if we take it down, we need to keep something up saying that we don't do that. Rather than waste a page, we might just add a section to the Powered By page. Then what about the Powered By page? I think we need one, but we might want to restrict it to sites that are willing to write up some sort of case-study to go with the listing, so it would be more than just a URI. I'm thinking of a site preface page with a screen shot or two that talks about how the site came to be written, and then finally a link to the site itself. Realistically, people are looking for war stores and testimonials here, rather than just a link list. So this would become a "Struts Showcase" section, rather than just a Powered By directory. Of course, there would still be a list, but it could include an introductory paragraph (from the site preface page), and link to a page about the site, and then to the site itself. (Or not, if it is an internal site with a really good write-up :) I can work something up a couple as examples. We might also try twisting dIon's arm for something regarding the Pizza Hut site. I also remember a good post WRT the http://www.ipayment.co.za/ site. Application Servers, The Malamute Registry, BaseBeans (www.proj.com), Bug Track, FixaFest, Julianne Griffith, Raible, IPIP, Roller, and WindSurfing look like other likely suspects =:0) How about if we start by reducing the PB list to these twelve I can then try to get a case study page up for one of my things to get that ball rolling. * http://www.application-servers.com/ * http://amalregistry.webhop.org/ * http://www.proj.com/ * http://www.bug-track.com/ * http://www.fixafest.nu/ * http://www.ipipi.com/ * http://www.juliannegiffin.com/ * http://www.pizzahut.com.au/ * http://www.raibledesigns.com/ * http://www.rollerweblogger.org/ * http://www.ipayment.co.za/ * http://www.windsurfpassion.com/ -Ted.
Cool - I feel the love! You can follow this thread here. Hopefully, by creating struts-xdoclet, this site will serve as a war story the development and evolution of a struts webapp. I encourage any of you to jump in and help, or at least send features/ideas that you'd like to see implemented.
I woke up around 10 this morning (after being up until 2 last night), fired up NetNewsWire and started reading. The first one of interest was Dave's entry All I can say is WOW! and where can I get the source?. I signed up and was amazed my the smoothness and speed of this webapp. As I told Mike - this is one of the coolest things I've woken up to in a long time. The question is, will I stop using NetNewsWire on OS X, or Phoenix (with a 31 tabbed bookmark) to read the blogs? Probably not, I like the look of a web page, and people are changing their styles so much, that it's nice to see good looks along with great content.
I guess if I really had my shit together, I'd put something like this together for www.javawebapps.com. A place where you can signup and upload your .war files for public consumption. I'm willing to let the java.blogs webapp be the first entry! I'd love to hear more about this webapp - I'm guessing it's written using webwork and it's running on Resin.
