How are people writing builds for their Play applications?
I understand that you can run play auto-test on the command-line, however, I would like to do a bit more than just execute the tests.
So for example, if I wanted to add checkstyle and clover to my build, I could easily write an Ant script that would check those two things and fail if there are any checkstyle errors or the clover coverage is not 90%.
I was just wondering whether there already was a "Play" way of doing what I have just described.
not, not as far as I know, although there are addons to use ant/maven in Play, you could try to integrate them. But users may skip then and use the normal play.
An idea would be to modify the Play python script to run these validations before any action, but that would require all developers to use that modified script.
There isn't a "Play" way that I know of, either. I've used Gradle in the past with some Play apps to do that kind of stuff.
Related
I'm exploring the use of Groovy as the default scripting language for my next project. Some basic requirements are:
load and run Groovy scripts, sending params in and getting results out, I know this can be done using GroovyShell or GroovyScriptEngine.
be able to run in debug mode stepping into the statements of the scripts (no need of managing breakpoints but execute statements in the code and take a look and the values of the variables in the current scope).
Yes, this is like a small IDE, but should be integrated into the app that manages running many scripts in parallel, and sending outputs of some scripts to inputs of other scripts (is a pipes and filters architecture http://www.enterpriseintegrationpatterns.com/patterns/messaging/PipesAndFilters.html).
I'm not sure if Groovy alone provides debugging and stepping into groovy code, or Java Platform Debugger Architecture should be used, or if this should be done by embedding an IDE into this system (it might be possible to embed Eclipse components).
These are my main concerns/doubts about the possibilities of using Groovy. any pointers are welcome.
Short answer is "No easy way to embed debugging functionality in an application that I am aware of". Please provide workaround instructions to use companion IDE or start deep research for any open source projects that have embedded script debugger functionality... and become great friends to the related contributing developers :-).
MORE INFORMATION:
Anything is possible when working with open source software. Yes, you can build a debugger that hooks execution of script (assuming you can keep process/threads separate) to step, create/halt at breakpoints, read variables currently in memory, etc.
Example: SmartBear ReadyAPI SoapUI NG PRO v4.6+(?) includes some base debugging embedded in their "Groovy Script" Test Step editor pane. (Disclaimer: SmartBear might have used other language or libraries to build their debugger features. I also am unsure if/when this feature will go to the SoapUI Open Source project - debugging is clearly noted as a PRO (paid) feature.)
Caveats:
Implementing debugger functionality is a MAJOR feature. You need debugger development experience (and/or even more time) to build functionality unrelated to your actual application. Make sure you truly need this embedded debugging before proceeding.
You should start with existing open-source groovy debugger to embed in your application... if one exists. SmartBear SoapUI NG PRO would be a start... but PRO feature is not open source.
What I am trying to do:
Build the (AWS Lambda function) Java Maven module, with the mvn command and goals, as usual.
Depending on given custom goals, Maven will call Serverless CLI commands to deploy the Java based Lambda function, using the serverless.yml file in the root dir of the module.
Maven continues with end to end test, using URLs returned by Serverless CLI command call (deploy). Or by sending messages to a queue, if that's the event triggering the function.
So, I've been searching for a Maven plugin for Serverless Framework CLI, but I can't find anyone. I really want Maven to execute the Serverless CLI when certain goals are given.
This is what I think my options might be, right now:
Write the Maven plugin myself.
Use shell scripts, I consider it ugly, but thats subjective.
Get a tip of a Maven plugin I've missed.
Another slick way to accomplish what I want, that I'm unaware of.
I appreciate all ideas, but really I'm focusing to solve this within the Maven lifecycle.
Another slick way to accomplish what I want, that I'm unaware of
I think a way the achieve this is to add the scripts to a step in your build server. Maven's primary function is to act as a build manager which is slightly different from the deployment use case you are outlining above.
If anyone is still intrigued by this I've started an inspired effort at https://github.com/olensmar/serverless4j/tree/master/maven-plugin - still working on how this would optimally fit in the maven lifecycle - ideas/suggestions as always welcome!
I have an eclipse (java) project that I would like to perform some testing on. It Looks like TestComplete may be able to do it, however it's unclear based on what I can find, how exactly to run this testing on an ECLIPSE project.
Do you just open the jar file using TestComplete and so thus using the Eclipse IDE is irrelevant?
Do you have to import the project into TestComplete somehow?
I found this: How Test eclipse product using TestComplete..?
Which I would have expected would answer that question, but really doesn't appear to answer the same question I read.
I'm trying assess if I can use this tool to test my software, but I'm a little unclear on how it works with eclipse in this case.
You need to run your application in a way whatever you want. After this, TestComplete will be able to work with the application: just record some actions and TestComplete will be able to play them back.
If you need to run the application from TestComplete, you can do this using the Tested Applications feature. It allows running a usual Java application using JAR file as well as running Eclipse as a common exe.
What exactly do Gradle and Maven "do" that eclipse or sts doesn't? From what I've read it builds, runs, etc which can all be done in eclipse easily.
If I have an existing project I've created, built, and currently runs in eclipse via tomcat, what would I use gradle for?
There's not a lot of benefit to using Maven or Gradle on a small project that you never share with anyone; an IDE can do the build just as well. But as the number of developers increases and the complexity of the build increases, it becomes very useful to separate the build instructions from the IDE. Let's drill into these a little bit.
With the increase in developers, you don't want everyone to have to come by and use your IDE to get a build done. That would be really annoying! So they're on their own machines, but then they tend to have different setups (how dare they have different user account names!) and probably have their IDE installations set up a little differently too. So we need some kind of build instructions that people can use to get things going, and it helps if everyone can use the same build instructions repeatably so that you don't get too many instances of “but it works on my machine!”. It's also very helpful if those instructions are simple enough to use that a new programmer to the team can get up to speed rapidly.
But the other thing that often happens as projects grow in scope is that their builds become more complicated. They very often gain additional dependencies (they didn't start out needing a high-performance date parser and MIME-type identifier, buit they've become required since and you don't want to have to write all those from scratch) and that means you've got to make sure that when the build is done, the right version of those dependencies is used. But that's not the only way that complexity increases. It's also very often the case that you find you're using more automatically-generated code. You might find yourself working with XML schemas or WSDL a lot, or maybe your using Hibernate, or Spring, or … well, there's lots of ways in which things can get complicated, OK? Getting the various steps to do all the build right, reliably, in these sorts of scenarios can be a bit tricky, but encoding them as instructions to something like Maven makes life a lot easier once you've taken the jump in the first place. (It gets even more important when you start trying to deal with projects which need many different sub-programs that work in concert; some of those are plain hard to build even with Maven or Gradle or any other tool.)
And then there's the possibility of offloading work to a build server, running tests automatically, managing dependencies cleanly, etc. IDEs don't handle these all that well by themselves; where they do a reasonable job of it, it's usually because they're using a tool like Maven under the covers to do the heavy lifting.
tl;dr
You don't have to make your code work with a build system, but it helps if you do and in many ways.
Maven and Gradle can do many things that Eclipse doesn't. However, the most important thing they do, is to decouple the bulding and testing processes from the IDE you choose (i.e. Eclipse). When you work on a large environment, with many programmers, usually you can not control the IDE they use. So, it's better to use a tool like Maven and Gradle to standardize these tasks. The same happens with the code examples of a book: instead of the authors having to provide the instructions for configuring any IDE to execute them, they provide the Maven or Gradle files, so the reader can build and test them on any IDE he's using.
Another very important feature that Maven and Gradle give you, is the fact that dependencies are managed without the need of having the executable code under source version control. Instead of having the executable code you depend on as part of the project, you declare the dependencies on a text file (which is under source version control), and then get them from a repository.
However, you may only see the real advantages of using tools like Maven or Gradle (and even Jenkins or Hudson), when you think in large scale projects, developed along many months by teams composed of many developers).
Gradle and Maven are build tools. Maven was first and is a bit older, Gradle is newer and has redefined a way of how projects are built and maintained. In my opinion it's also much easier to use, more readable and easier to maintain. I prefer Gradle ;)
You use eclipse or STS (any other IDE) for development. And while You finish this process You need to provide a configured artifact (war, ear, whatever...) to production and deploy it there. These artifacts have well defined format and the application won't be run from eclipse or STS at the production environment. It's tiresome and error prone to prepare such artifacts by hand.
Gradle or Maven can take responsbility of building and preparing these artifacts (in fact such tools can do much more) off Your shoulders, they make this process automated.
I'm trying to figure out the best way to automate the execution of and result recording of load tests. We currently use Maven; ideally the solution would be executed as part of the Maven project life-cycle, so that people do not need so spend time on effort setting up the tests.
It should save the output of the tests (e.g. as some files that could be committed into version control), and should have the sense to not compare tests run on a dusty x486 with a 8 core Sparc.
JMeter is another Apache project which is very well adapted for automation (you can control most things from the command line); there are also several plugins that you can use to integrate it into Maven. Personally, I think this is by far the best tool for this sort of requirement.
You still need to create the actual tests to run and decide which environment to use - but this will always be the case no matter which tool you choose.
Have a look here, here and here.