I had been persistently trying spring roo since its milestone release until three months ago.
With the new STS release, I am about to try mucking around with it again. But, hold on, I am not about to waste my time again.
Preamble:
The last time I tried Spring Roo, it was a totally dysfunctional, especially the GWT and GAE integration part. Spring Roo was on an advertising path effectively saying "Finally a spring and gwt integration". I feel that that advertisement is misrepresented.
Questions:
Has anyone actually succeeded in creating a working GWT integrated project using spring roo?
It has been six months, and Spring Roo still cannot do GWT beyond a simple example and, therefore, still does not fulfill that advertisement. Is there a road-map towards achieving a GWT deployable spring roo? In agile management, we have road maps we try to think will get us where we want to be in a time frame we hope to conform to. I would like to see a road-map for deployable GAE and GWT integration, because I would like to put in place technology plan for my projects.
Should I abandon considering spring roo due to absence of a publicly available road map and wait for another two years before reviewing roo again?
Should I tell my cooperatives and associates (and anyone interested in my opinions) not to consider using roo as a deployable gwt and gae integration technology until another two years'?
It sounds to me like you should be considering an alternative.
I'm not sure how you came up with "another two years". No one of us, Spring included, knows the precise answer.
Related
I've been using Spring for about a year, and I'm comfortable enough using it, but I've avoided jumping under the hood for the most part.
I'm tasked with upgrading a large, mission critical enterprise application, from Spring 3.0.x to Spring 4.1.x.
What are the best practices for making a large, inevitably finicky and complex change like this? (Anything above and beyond 'throw in the jar files and see what happens' and 'read the documentation here: http://spring.io/' would be very helpful)
The system:
Java 6 - jax-b/-p/-ws/, Apache Commons,
Spring 3.0.5 - the usuals (core, context, beans etc), MVC, AOP, ORM, JDBC, Acegi
Hibernate 3.5
Tomcat 6
0 unit tests or automated testing of any kind.
Maven dependency management and build automation.
Half controllers using annotations for request response mapping, half using simpleFormController pattern, half autowired, half hooked up with xml.
Hundreds of views, scores of controllers.
Steps I've taken so far:
Prepared a (mostly automated) regression testing script (so that I can ensure I haven't broken anything)
I've started reading through the 'upgrade guides' one at a time, "upgrading to 3.1", "upgrading to 3.2" and making notes on things that sound familiar, but I think I'd need to have a much deeper grasp of our system, and spring in general, before I could be confident of this as an exhaustive approach. This just generally feels like a haphazard approach, which is not what I want for such a complex change.
My questions:
What steps/procedures are considered 'best practice' in these for a job like this?
Does anything jump out at you as a 'gotcha' for a job like this?
Obviously, there won't be "standard" set of recommended practices because every migration/upgrade is different. Here're my thoughts:
Requirements, requirements, requirements
Regression testing script is great start. If there is a complete documentation of the features/functionality, then your "success criteria" for migration is straightforward.
If the documentation is incomplete/non-existent, then double and triple check to make sure that all 'requirements' are captured with your tests. Might be a good idea to create documentation too. And have the product manager/supervisor sign off on it. You'll be surprised at how many 'hidden' requirements exist even in simple systems. There is a big risk of underestimating the effort needed for migration without comprehensive requirement.
It is extremely critical to set the right expectations in terms of timelines. Perhaps an agile approach with biweekly demos of how much progress you've made will help keep everyone on the same page.
Spring projects have evolved a lot. Budget for learning time.
This could be a big gotcha. Spring projects and Java development have evolved a lot since Spring 3.x. Big changes include:
Java 8 features
JavaConfig (as opposed to xml configuration)
Acegi is now Spring Security
Spring projects typically use Spring Boot
Switch from Maven to Gradle for building projects
Full CI using Jenkins (or other CI tools)
Unit and integration testing have moved on to using annotations (and mock frameworks)
Well, it is not easy to answer you question since there are many things to be taken into account.
First of all I can suggest you to use the Migrating from earlier versions of the Spring Framework guide that's coming directly from the 'source'.
I would especially draw you attention to the 'Enforced minimum dependency versions' section that recommends you the minimum version level of some wide used libraries.
Obviously in the moment you insert these new versions they're bringing with them some transitive dependencies that might generate conflicts.
Take also a look to the dependency updates section.
Also remember to correctly define the scope of the dependencies in your pom files, since many of them could be provided by the infrastructure you're using (i.e. Tomcat).
I think you will be required to move to Java 7 or 8 and also Tomcat should be updated to version 7 or better 8.
Moreover try to automate as much as you can your building and testing environment with maven along with adopting a CI environment like Jenkins (or Hudson if you prefer the product).
It is also very important to perform unit testing of every single little method/piece of code, since it will make integration tests easier.
You should also become familiar with Spring 4.x new features and try to exploit them especially those regarding testing improvements.
A little resume of new features is the following:
Removed Deprecated Packages and Methods
Java 8 Support
Java EE 6 and 7 become the baseline
Groovy Bean Definition DSL
Core Container Improvements
General Web Improvements
WebSocket, SockJS, and STOMP Messaging
Testing Improvements with extreme use of annotations
Take also a look to Spring MVC Test Tutorial by Petri Kainulainen that can give you a lot of informations about testing.
You have to have answer to the following before you proceed.
Is the need to upgrade is only the libraries and runtime for some sort of dependencies ?
OR
You really want to get the most out of Spring 4.x ?
Once you decide this you can take proper course. Those regression scripts you have created will help in both the scenarios. If you can think of some crude throwaway utility that will hit every public api with some valid input and capture the output and be able t compare this in the both worlds that may help but it may not be applicable in your situation.
So if you want to get the benefit of the Spring 4.x I would suggest you focus on productivity aspects and create an inventory of these things.
You may redesign the whole app in Spring 4 as if it is a new application.
Once you can envision the future state. The next problem reduces to going from Point A to Point B i.e. a matter of best migration path.
From Migrating from Spring 3 to Spring 4, you would probably get some help from the Spring project's
Spring Integration 3.0 to 4.0 Migration Guide on Github.
Hope it helped!
I am looking to learn Web Development with Spring 3.x and also looking at integrating hibernate into it. What is the best resource for learning Web Development with Spring MVC and Hibernate? I am new to this, so would like some resource that takes me from the ground up. Also recommend the best IDE for this.
Kind Regards
Spring in Action is a good book to get started: http://www.amazon.com/Spring-Action-Craig-Walls/dp/1935182358
It covers MVC and Hibernate in short and concise chapters to give you a quick start. For IDEs, I would recommend Eclipse with the Spring IDE plugin installed.
Hope that helps!
It depends a little bit on what you mean by " I am new to this". New to web development in general? ... new to java in general or just new to Spring and Hibernate? Spring Roo might be a great tool in general, but in terms of learning you're better off rolling as much as possible by hand. At least in the beginning. That's because it will take you to places where you WILL learn. Things will break, produce weird results, etc., all in all you'll get to know how everything jells. Hibernate in and of by itself can be an adventure. So for starters I'd forego the convenience of Roo and get your hands really really dirty.
I'd vote for starting a project and come back for more when you get stuck.
Start a project with spring ROO, it will setup all the best practices for you.
Also, use spring STS IDE, it comes with a few eclipse plugins already installed.
I' writing a web application with Wicket 1.4.X, Hibernate 3.6, and Spring 2.5.6.
I have some objects
For Example:
Person
name
SSN
positon
etc....
now some fields are not editable. say SSN, however other fields like position, are only editable for managers. If a supervisor makes the change, it gets forwarded on to a manager for approval. I have a homegrown system currently in place for part of this. However, it seems to me that an actual workflow system would allow me to collect all of the rules into one nice convenient location rather than having them scattered around my code.
I'm looking for a system that is:
Simple
Integrates well with the technologies I'm already using
Doesn't require a separate server
(the app is internal I don't need "on-the-fly" rules changes)
I keep coming across references to jBPM having no "real" experience with workflows it looks like the easiest/most efficient route to install it is by installing Drools. The Drools and jBPM integration Guide even talks about Spring integration.
However, the documentation felt sparse and I didn't completely understand what I was looking at. Before I start down the (what I assume to be long) road of Drools/jBPM I wanted to get a community consensus from people smarter then me on the subject of workflows.
UPDATE:
I talked with my boss about this issue. We currently have another "in-house" application. (currently maintained by external contractors) that's using Stellent, now known as
Oracle Universal Content Management with Oracle BPM. While I should probably learn these technologies since I will more then likely wind up maintaining that other app, it just feels counter productive to integrate a whole UCM/BPM solution into the guts of my application if I've already setup the Front-End and the DB back end.
(Caveat: My only experience with a CMS was Plone, about 2 years ago and I am not a Python programmer.)
I guess you could just use wicket auth roles. http://wicket.apache.org/learn/projects/authroles.html
I last installed Spring a few years ago and back then it was just some jars I had to add. Now after I googled for Spring, it brought me to SpringSource, a division of VMWare.
It took me through a whole installation process for the SpringSource Tool Suite and it looks cool, but is also bulky.
What are people doing for a robust and lightweight Java MVC framework these days?
Well, Spring MVC is a robust and lightweight Java MVC framework these days ;-)
One "problem", though: it uses Spring itself (of course), which has gotten much bigger over the years. What was once just a dependency injection framework, today is almost a complete Java EE replacement. Meaning: if you want Java EE without a true application server, then use Spring. And that boils down to using Tomcat with Spring in most cases.
So, the true answer is: you can still use Spring without much hassle, but use only what you need, if you really need it. Spring originates from 2003, when Java EE was a real pain in the neck, but nowadays Java EE has gotten more and more simple, almost to the point that it's preferred over Spring, especially EE 6.
Springsource Tools isn't needed for using Spring, but it is recommended for efficient Spring usage. If you stick with XML configuration, lack of tools assistance will hamper you in the long run.
My little rant is over, so I hope I helped you at least a bit.
Springsource Tool Suite is their customized distribution of Eclipse, and no you don't technically need it. You still only need the jar files, which can be found here.
You don't need SpringSource Tool Suite.
Spring is still the most popular lightweight Java MVC framework.
Spring is splitted into different modules (projects) to avoid big dependencies if you don't need them.
List of projects from springsource
spring-framework-3.1.0.M1.zip is 25.6 MB and can be found here
Have fun!
I am looking for feedback from experienced users on spring roo and appfuse. Which do you think does a better job reverse engineering database tables and generating a service layer, dao layer, and jpa entities?
If I am not mistaken, spring roo currently cannot reverse engineer a database.
Just a quick update to inform all users that stumble upon this thread now (or at least after today :)); With the new 1.1.0 release, Spring Roo now does support incremental database reverse engineering out of the box. See this release annoucement.
As a comment on the actual question: I don't think either of the two is way better than the other in the actual entity generation, but there is a big difference of course between AppFuse and Spring Roo aside from the entity generation. If you actually need DAO's, this is something that comes out-of-the-box in AppFuse and put partly in Spring Roo, but there is also a great addon for Spring Roo (Hades addon) that does a great job at this, maybe even better than AppFuse. Main reason to go for AppFuse, in my humble opinion, is if you require another Web Framework (ie Wicket. Tapestry or JSF) as front end then Spring MVC or GWT, as these are currently the only well supported Web Frameworks within Spring Roo (more coming though, like Flex etc.). Other reason you might go for AppFuse is if you want to use an IDE with full intellisense and code-completion support, but don't want to use Eclipse (you can use other IDE's, and build works perfectly well with Spring Roo, but due to the AspectJ files, which aren't recognized by Netbeans, other IDE's then Eclipse currently don't do code completion well for the Spring Roo generated/managed files).
But if you don't mind Eclipse (or better even the Spring Tools Suite) and do want to use GWT and/or Spring MVC, I'd recommend Spring Roo. Main reasons to go for Spring Roo is the, in my humble opinion, higher productivity, far better support, far higher momentum and activity, lower learning curve (for quick CRUD app generation) and of course the Rails like command shell from which you can quickly setup and configure your application.
Ps. Note that I haven't used AppFuse actively for over a year, so my knowledge of AppFuse is a bit rusty.
Roo is good to quickly put up stuff up (round-tripping is amazing)..but the lack of out-of-the-box provide for a services layer puts my needs in a bind. I know I can do #Services annotation and place code appropriately as mentioned in the documentation(too much work at startup). I wished Roo gave me a choice to have a services+dao layer...out-of-the-box.
That would (have made)/make Roo a killer app, imho
You are correct that you can't reverse engineer a database in Roo. There's an open JIRA item for this which you can vote up.
However, you could try using the Eclipse Hibernate tools to reverse engineer your database, then modify those objects to make them Roo Entities. That probably would involve a lot of manual work though.
For AppFuse, there's the AppFuse Maven plugin which can create the entire AppFuse project for you from an existing database. I'm not sure if it's currently working though, because the last person I mentioned it to said they couldn't get it working.
Depending on your requirements, you may also want to give the Grails framework a try. There's a tool called GRAG that can reverse engineer a Grails application from a database.
The ROO-435 issue is actually our most requested feature, so I'll be implementing that in Spring Roo within the next few weeks. In the meantime, Jason's suggestion of using the Eclipse Hibernate tools to create JPA annotated entities is an immediate solution that is fully Roo compatible.