Develop Reference

Is it Possible to Convert Existing Java Projects into Spring-Batch Jobs

My question without the fluff
Is Spring-Batch the right tool for converting a handful of one-off (one and done type) java projects that tend to interact with a database at some point, into their own separate "Jobs" that are part of a Spring-Batch project?
With Fluff/Background
The company I work for has several "one off" java projects that really only do one thing (either at some arbitrary time, or just whenever we tell it) and then they are done. They tend to interact with the database at some point in their lifecycle, but not necessarily at the same time.
There are a couple more projects/scripts that I'm tasked with creating, but instead of having nearly 10 different perl scripts and a few handful of jars out on our box, we would like to maybe stuff all these projects in one place and just be ran when we need to run them (ideally on a remote box via command line args). From the research I've done on Spring-Batch, it kind of sounds like exactly what we are looking for, especially the functionality described here.
I'm moderately familiar with Spring-Boot and the Spring Framework, but for some reason reading up on Jobs and the setup, the domain language seems a little foreign to me, and I just want to make sure I'm not wasting my time trying to figure this out if it's not realistic. We would like this to just be one cozy place for any current or future projects that are ran independently so that we minimize clutter on our box. Just to clarify, I keep saying projects, but from what I understand, these projects need to be converted to Jobs if they are to be part of a Spring-Batch project. Is this realistic?

(converting comments to an answer)
If things like task scheduling, transaction management, consuming data in chunks, flexibility on start/stop operations, retrying mechanisms are things you find yourself spending time into coding yourself then yes definitely take a look at Spring Batch it has robust already-implemented facilities of all of the above.
On the grander scheme of things if your application has many moving parts, consuming a lot of external resources you might as well dive into the EIP (Enterprise Integration Pattern) waters with Apache Camel and Spring Integration very solid implementations.
By your description your one-off project(s) are reasonable single-focused so the learning curve of new frameworks might not worth the while. In that case it might suffice to focus on the re-usable components of your projects and externalize them on a core/helper lib for re-usabilitly purposes if that makes sense.

Why use Yeoman's generators instead of Maven's archetypes?

I noticed that Yeoman's generators are more focused on client-side code generation, whereas Maven's archetypes are on server-side. But I still do not fully understand why it was necessary to create Yeoman, if Maven copes well with code generation task?
I suppose, it is possible to write a Maven's archetype, for example, for Angular JS, and use it instead of analogous popular Yeoman's generator. But there is no such archetype, or at least it is much less popular.
So, please tell me why?
My guess on this occasion turned out not true.
I thought that Maven is not able to generate components inside existing projects. But this is not true. I found that an optional <allowPartial>true</allowPartial> tag makes it possible to run the archetype:generate even on existing projects.
Thus without your help, I can not answer this question quickly.

Maven and Yeoman are both code generators using templates. It is up to template what code will be generated. Therefore both can be used to generate client-side and server-side projects.
Below points may explain why each tool is popular in one area, but not the other:
1. People are using tools that are popular inside their language ecosystem
One reason is that developers mostly use tools from ecosystem of language they are developing code in. Yeoman is code generator used mostly in client-side project, because that's where JavaScript is used most of the time. Maven is used mostly in server-side project, because that's where Java is used most of the time.
2. Tools from other environments needs that environment
Running Maven on purely JS project would demand installing Java to use it. Yeoman on the other hand can be run using Node.js. Java would be unnecessary dependency for developer. Vice versa is also true.

Java, using Groovy (Grails) during development just to be able to test code without recompiling?

I do Java web development work using Spring MVC and basically I'm forced to do an Agile type of development where I have to make a lot of small changes and I sometimes end up wasting a lot of time having to compile each time I make a change ( I work for a start-up company and I am not given enough time to make unit tests, etc, this isn't ideal and I don't necessarily plan to stay with the company long-term but am just looking for ways to be more adaptable for the moment).
The app I'm working on needs to be fast and it does a lot of high volume data processing (its sort of a search engine but not a web search engine) so it has to be regular compiled Java for the production app but I'm wondering if I used Groovy with Grails, or something similar, for development if I could just write it as regular Java but then test code in real-time without having to recompile. I'm wondering how much effort would be involved in doing this as far as making it work then as compiled Java. Sorry if this is a newbie question I just am not sure where to look for info on this as most things about Grails seem more geared towards emulating scripting languages not what I am trying to use it for.

Agility is a state of mind, it doesn't have anything to do with a programming language or framework. I never have enough time NOT to do unit tests.
If you are coding in Java, code in Java, not in Groovy. Groovy is an (almost) superset of Java, so you could theoretically write your classes in Groovy and then compile them as Java, but this approach has a number of problems:
1) It's very easy to slip something in your code which isn't correct Java, closures are just SO useful :-)
2) Grails isn't easily translatable to Spring MVC, so you'd have to rewrite that bit as well.
So, I personally would not use Groovy/Grails.
When you say compile, do you really mean build the war and redeploy? Most IDEs (Eclipse, Intellij, etc) recompile a class as you save the file, so there is no delay. Assuming you're using such an IDE, you can run your (Tomcat) server from within Eclipse, and stuff gets automatically redeployed, and if necessary Tomcat restarts automatically.
If this still isn't fast enough, I recommend JRebel, which was so good that i forked out real money for a license. Using JRebel means that you (usually) don't even have to redeploy. You change a Java file in the IDE, and the change happens in your server without having to redeploy. I would highly recommend it.
One other thing I would do is to write unit tests for your code. You don't need to check them in, but they are a tool which will help your productivity.

What I would do here would be to embed groovy scripts within the java code as described here:
http://groovy.codehaus.org/Embedding+Groovy
In this way you can change your groovy code without the need to recompile. We've used this technique in our last legacy app that took 10-15 mins to recompile and install.
Groovy runs within the JVM and is dynamically compiled to bytecode, so there's no need to worry about the "production-ness" of it.

any experience with "Play" java web development framework? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've just stumbled upon the following new java web framework: Play
http://www.playframework.org/
http://www.playframework.org/documentation/1.0/home
with such a stunning list of features, I'm pretty much surprised I haven't heard of it before...
Sounds like the java web development promised land...
has anybody tried it? any real experience with it? do you think it's worth studying it?

I agree with Jason that Play might just prove to be better than Grails. With four Grails projects under my belt (preceded by two Tapestry projects and one Wicket project), I'm seriously looking at Play next.
One of the things I thought was cool about Grails is that "everything's Groovy." That is, you use Groovy to write everything (except the HTML and the CSS) -- domains, controllers, services, page templates (GSP), tag libraries, Hibernate API (GORM), unit tests (GUnit), and build scripts (GANT). You can even write shell scripts in Groovy. So, being able to code all aspects of an app using a single language again seemed like a simplification that was long overdue -- hearkening back to the days of writing desktop apps in a single language like C++ or Delphi. However, I've learned that one size does not fit all here.
For one, the IDE support for Groovy isn't great. IntelliJ does the best job, but with Groovy being dynamic, it can only go so far. The refactoring tools do not (cannot) catch everything, so you can't trust them 100%. This means you have to be especially vigilant with unit testing. Here again, because Grails relies so much on dynamic "magic" that happens at runtime, the unit testing in Grails must rely on an extensive mocking layer to emulate it, and that mocking layer is quirky. A third issue is that much of the so-called Groovy code that you're writing is actually domain-specific-language (DSL) code. (To make a long story short, DSLs are short-hand Groovy, taking advantage of the fact that in Groovy and lot of the syntax is optional.) Grails uses different DSLs for various configurations, URL mapping, etc. and it is inconsistent. How you specify log4j settings, for example, looks nothing like how you specify the data sources, and neither looks like the pure Java upon which Groovy is based. So, the promise of "everything's Groovy" falls apart anyway.
That being the case, I see where the Play team is coming from.
Going back to regular Java for the domains, controllers, services, and JUnits makes sense. Strong typing means the IDE can reliably help with inteli-sense, code navigation, refactoring, etc. (And thus you don't need to pay for IntelliJ if you're happy with Eclipse.) Having to write more verbose code in order to gain back strong tool support seems like a good deal to me right now. We'll see.
I like that I still get to use Groovy in the page templates. I'm afraid I may end up putting more code in the templates than I should, though.
I have no experience with JPA, but it seems like it's pretty close to what GORM does for me, so that's cool.
The Spring IOC support in Grails is completely transparent whereas Play's support seems minimal; however, I think that IOC is way overused and I'm perfectly willing to hand code a Spring XML mapping on the rare occasion that I really need one. (One of my open questions is that I'm assuming that JPA has transaction support which is why Play doesn't need Spring for that like Grails does, no?)
I've never been a fan of Python, so I cringed when I read that Play uses Python for its build scripts. But I agree that Grails' GANT scripts run pretty slow. Plus I find that, while GANT is a huge improvement over XML ANT, it's still hard to wrap your head around the ANT concepts. The Grails GANT scripts are pretty convoluted. So, I'll go in to it with an open mind.
The Play "application module" model sounds to be just like Grails' "plugin" model, so that's cool.
I'm quite impressed with the Play documentation that I've read so far. I had a huge number of questions going in, but half of them were answered right off the bat.
I'll report back again later as I dive deeper in.

I've tried Play and I'm impressed: it does a great job of delivering a useful development model that is far simpler than most frameworks'. More than anything else, the runtime's ability in 'development mode' to parse .java files directly is worth a lot: just reloading the web page in the browser without running a build script or waiting for a redeployment is worth a lot of development speed. The error messages shown in the browser are really good too.
Another thing that impressed me was the overall aesthetic: it is perhaps a small thing that the tutorial application actually looks good (both the code and the web page design), but this extends to the whole framework, the API as well as the documentation.

After prodding from a colleague I looked at it, followed the tutorial, and got hooked. Getting immediate feedback right in your browser means you don't have to use an IDE. I love Eclipse, but let's face it: after you've added some extras, it's not as stable as a simple text editor. On a Mac with TextMate you can even click on the error message in your browser and TextMate pops up with the cursor on that line.
Testing in Play is also nicely done, with one button press you run unit tests, functional tests and Selenium-based tests.
Play is exciting because it's still small and uncomplicated. It uses just ant to build and does so in 25 seconds. Contributing to the beautiful documentation is a matter of editing the .textile files and reloading the docs in any play app.
That's how I wound up on a quest to translate the tutorial to use Scala, adding to the Scala support where needed to get it as nice as possible.

I like it, I'm using it for small projects and so far it looks perfect for the job.
However, there's one thing I miss very much that's been left out on purpose: Service/DAO/Model layers separation! Documentation says it clearly, one of the goals of Play is to avoid the "Anemic data model":
http://www.playframework.org/documentation/1.0.1/model
but in my experience the classical Service/DAO/Model layers separation saves tons of development time when the application needs to be refactored! With Play you're stuck with static methods that rely on Play-specific transaction management and peculiarities...
However, many thumbs up for: development speed, code cleanness, and in the end... fun!

I've used Grails, Tapestry 4/5 and straight Java/JSP/Spring/Hibernate.
I think this is going in the right direction for the first time in a long time. Grails was a really good first step but Play! looks like something that could really have legs. Scala support is coming in 1.1. If there is a chance I can write my controllers/domain in Clojure, I'm sold ;)

Since one year and no visible bug after 18 small releases, we use Play! 1.2.4 in a production "absences" intranet application for a school (actors: >100 teachers, > 700 students, administrativ team). Client side has been written with FLEX 4.6 from Adobe (very beautiful views). Data are send and receive in AMF3 format (Cinnamon module). We use a own simple dao layer based on JPA EclipseLink and MySql for the DB. Application is stored on a Linux virtual server. I'm a very fan developer of Play for its simplicity and its very productive approach.

I like the look of Play, but haven't tried it. From scanning through the docs one thing that stood out was the heavy use of static methods. From a unit testing point of view this always makes things much harder (I'm thinking mocks), and is a departure from the OO-everywhere approach in typical Java development. Maybe this is the point, but it's just something that made me a little less enthused...

I currently build web applications at work using play framework which does massive data processing. I must say that the speed that play offers alone is significant and more than what RoR can provide. Besides, play is a java based framework and hence Multi-Threading can be done easily. Next is the sheer performance you get when you use java-based modules like Japid and Netty along with play.It's like an endless amount of tweaking can be done for performance. A must try in my opinion.

I'm using Play in a small project, and seems to be exactly what they've said about. But one feature I think should to be present by default in the framework: ability to work with more than one datasource (e.g. use more than one database schema). This is the only missing feature I've found until now.
Regards,
Uilian.

integrating Grails and GWT

GWT seems like a really nice technology for Java developers who don't like (or don't know) HTML/JS/CSS to build rich web interfaces. On the server-side Grails also looks really nice, it's often described as "Rails for Java developers". I've read that Grails' "convention over configuration" approach, together with the benefits of dynamic languages (Groovy) can really reduce the amount of (boilerplate) code that needs to be written, while still leveraging best-of-breed Java technologies such as Spring and Hibernate.
Anyway, I haven't read much about how well these technologies play together. How easy is it to integrate GWT with Grails on the server-side? I'd be interested to learn about experiences of anyone that has build an application with these technologies? Recommendations on resources (books/websites) for building a GWT-Grails website would also be very welcome.
Cheers,
Don

Grails already has a gwt plugin: check it out.

You did mention on the server side - GWT and grails actually doesn't integrate well on the serverside (not as well as you might expect given how well grails domain objects work). For RPC, the plugin it works really well.
The problem is that domain objects cannot be serialized and tranfered across the wire - after all, they groovy objects. You will need to custom make a data transfer object (DTO), and do the marshalling manually. It is possible to automate it, but there isnt any opensource code out there that does it atm - so rolling your own is the only solution.
Or see if you can get Hibernate4gwt to work with grails - but i doubt it will out of the box either.

Another approach: use Grails with SmartGWT. Instead of GWT-RPC (too complex, and as others have noted, doesn't play well with Grails) use REST-based integration, since Grails has great support for serializing to XML or JSON and SmartGWT has built-in REST support. Take a look at this blog showing sample source - it's ridiculously easy to build a reusable master-detail screen for any Grails object.
http://josip-dev.blogspot.com/2010/06/grails-smart-gwt.html

with the benefits of dynamic languages
(Groovy) can really reduce the amount
of (boilerplate) code that needs to be
written
That's what folks from RoR camp was preaching all the time. After some initial boom RoR projects got into inevitable trouble with bigger projects. The bigger projects the more work one should delegate to compiler, i.e. the more valuable are static languages. Currently, RoR boom is all but gone.
The amount of (extra) code you need to write now with JPA/Hibernate, for instance, is almost zero. Annotations only. It even finds the mapped beans itself, in runtime, via classpath! SpringFramework makes many other "boilerplate" codepieces obsolete too.
In my GWT project (one so far, have to admit) I use JPA (Hibernate), DAO layer, business delegate pattern and it's easy and robust.