I've been looking for a code coverage viewer aimed at inspecting live Java applications, mostly webapps running inside an application container like Tomcat. Sure, there are a number of decent tools for getting automatic reports of unit test coverage, but my aim is more like learning in real time what an unfamiliar Java app does e.g. on a specific user interaction.
The Eclipse Java debugger (with JPDA for remote debugging) is really useful, but only if you are already familiar with the application's architecture. And in theory, I could take some coverage tool and set it up to auto-refresh static HTML coverage reports every two seconds, but this is far from optimal.
For Adobe Flex, FlexCover does just what I want by providing a coverage viewer tool that visualizes the coverage in nearly real time, and it's relatively simple to set up at least for somebody who knows the stuff. So is there a similar easy-to-set-up GUI tool, free or non-free, for Java?
You can view Clover's coverage data generated by a web application, in Eclipse, without the need to start the web server from Eclipse.
The trick is to configure the initString in the Eclipse Clover Config screen to point to the same clover.db that your webapp is using:
And - you need to ensure you are using a threaded flushpolicy. The clover-maven2-plugin uses one by default. If you are using Ant, you will need to set it explicitly on <clover-setup/>.
You must also ensure you are using the same version of Clover in both Eclipse and your build tool.
I have tested this locally - and it works quite well!
Please let me know how you go.
Have a look at clover. It may be what you are looking for. Not free, but nice.
Related
For past 4 years, I have been programming with Eclipse (for Java), and Visual Studio Express (for C#). The IDEs mentioned always seemed to provide every facility a programmer might ask for (related to programming, of course).
Lately I have been hearing about something called "build tools". I heard they're used almost in all kind of real world development. What are they exactly? What problems are they designed to solve? How come I never needed them in past four years? Are they kind of command-line stripped down IDEs?
What are build tools?
Build tools are programs that automate the creation of executable
applications from source code (e.g., .apk for an Android app). Building
incorporates compiling,linking and packaging the code into a usable or
executable form.
Basically build automation is the act of scripting or automating a
wide variety of tasks that software developers do in their day-to-day
activities like:
Downloading dependencies.
Compiling source code into binary code.
Packaging that binary code.
Running tests.
Deployment to production systems.
Why do we use build tools or build automation?
In small projects, developers will often manually invoke the build
process. This is not practical for larger projects, where it is very
hard to keep track of what needs to be built, in what sequence and
what dependencies there are in the building process. Using an
automation tool allows the build process to be more consistent.
Various build tools available(Naming only few):
For java - Ant,Maven,Gradle.
For .NET framework - NAnt
c# - MsBuild.
For further reading you can refer following links:
1.Build automation
2.List of build automation software
Thanks.
Build tools are tools to manage and organize your builds, and are very important in environments where there are many projects, especially if they are inter-connected. They serve to make sure that where various people are working on various projects, they don't break anything. And to make sure that when you make your changes, they don't break anything either.
The reason you have not heard of them before is that you have not been working in a commercial environment before. There is a whole lot of stuff that you have probably not encountered that you will within a commercial environments, especially if you work in software houses.
As others have said, you have been using them, however, you have not had to consider them, because you have probably been working in a different way to the usual commercial way of working.
Build tools are usually run on the command line, either inside an IDE or completely separate from it.
The idea is to separate the work of compiling and packaging your code from creation, debugging, etc.
A build tool can be run on the command or inside an IDE, both triggered by you. They can also be used by continuous integration tools after checking your code out of a repository and onto a clean build machine.
make was an early command tool used in *nix environments for building C/C++.
As a Java developer, the most popular build tools are Ant and Maven. Both can be run in IDEs like IntelliJ or Eclipse or NetBeans. They can also be used by continuous integration tools like Cruise Control or Hudson.
Build tools are generally to transform source code into binaries - it organize source code, set compile flags, manage dependencies... some of them also integrate with running unit test, doing static analysis, a generating documentation.
Eclipse or Visual Studio are also build systems (but more of an IDE), and for visual studio it is the underlying msbuild to parse visual studio project files under the hood.
The origin of all build systems seems like the famous 'make'.
There are build systems for different languages:
C++: make, cmake, premake
Java: ant+ivy, maven, gradle
C#: msbuild
Usually, build systems either using a propriety domain specific language (make, cmake), or xml (ant, maven, msbuild) to specify a build. The current trend is using a real scripting language to write build script, like lua for premake, and groovy for gradle, the advantage of using a scripting is it is much more flexible, and also allows you the to come up with a set of standard APIs(as build DSL).
These are different types of processes by which you can get your builds done.
1. Continuous Integration build: In this mainly developers check-in their code and right after their check-in a build initiates for building of the recent changes so we should know whether the changes done by the developer has worked or not right after the check-in is done. This is preferred for smaller projects or components of the projects. In case where multiple teams are associated with the project or there are a large no. of developers working on the same project this scenario becomes difficult to handle as if there are 'n' no. of check-in’s and the build fails at certain points it becomes highly difficult to trace whether all the breakage has occurred because of one issue or with multiple issues so if the older issues are not addressed properly than it becomes very difficult to trace down the later defects that occurred after that change. The main benefit of these builds is that we get to know whether a particular check-in is successful or not.
2. Gated check-in builds: In this type of check in a build is initiated right after the check in is done keeping the changes in a shelve sets. In this case if the build succeeds than the shelve-set check-in gets committed otherwise it will not be committed to the Team Foundation Server. This gives a slightly better picture from the continuous integration build as only the successful check-in's are allowed to get committed.
3. Nightly builds: This is also referred as Scheduled builds. In this case we schedule the builds to run for a specific time in order to build the changes. All the previous uncommitted changes from the last build are built during this build process. This is practiced when we want to check in multiple times but do not want a build every time we check in our code so we can have a fixed time or period in which we can initiate the build for building of the checked-in code.
The more details about these builds can be found at the below location.
Gated-check in Builds
Continuous Integration Builds
Nightly Builds
Build Process is a Process of compiling your source code for any errors using some build tools and creating builds(which are executable versions of the project). We(mainly developers) do some modifications in the source code and check-in that code for the build process to happen. After the build process it gives two results :
1. Either build PASSES and you get an executable version of your project(Build is ready).
2. It fails and you get certain errors and build is not created.
There are different types of build process like :
1. Nightly Build
2. gated Build
3. Continuous integration build etc.
Build tools help and automates the process of creating builds.
*So in Short Build is a Version of Software in pre-release format used by the Developer or Development team to gain confidence for the final result of their Product by continuously monitoring their Product and solving any issues early during the development process.*
You have been using them - IDE is a build tool. For the command line you can use things like make.
People use command line tools for things like a nightly build - so in the morning with a hangover the programmer has realised that the code that he has been fiddling with with the latest builds of the libraries does not work!
"...it is very hard to keep track of what needs to be built" - Build tools does not help with that all. You need to know what you want to build. (Quoted from Ritesh Gun's answer)
"I heard they're used almost in all kind of real-world development" - For some reason, software developers like to work in large companies. They seem to have more unclear work directives for every individual working there.
"How come I never needed them in past four years". Probably because you are a skilled programmer.
Pseudo, meta. I think build tools do not provide any really real benefit at all. It is just there to add a sense of security arising from bad company practices, lack of direction - bad software architectural leadership leading to bad actual knowledge of the project. You should never have to use build tools(for testing) in your project. To do random testing with a lack of knowledge of the software project does not give any sort of help at all.
You should never ever add something to a project without knowing it's purpose, and how it will work with the other components. Components can be functional separate, but not work together. (This is the responsibility of the software architect I assume).
What if 4-5 components are added into the project. You add a 6th component. Together with the first added component, it might screw up everything. No automatic would help to detect that.
There is no shortcut other than to think think think.
Then there is the auto download from repositories. Why would you ever want to do that? You need to know what you download, what you add to the project. How do you detect changes in versions of the repositories? You need to know. You can't "auto" anything.
What if we were to test bicycles and baby transports blindfolded with a stick and just randomly hit around with it. That seems to be the idea of build tool testing.
I'm sorry there are no shortcut
https://en.wikipedia.org/wiki/Scientific_method
and
https://en.wikipedia.org/wiki/Analysis
I've been asked a question by one of our developers here. They are asking whether it is possible for a selenium test suite to be tied in with a TFS build in visual studio to the test server? So that way, as soon as a build is done it can kick off a run of the regression test suite, directly after that.
Bear in mind that my scripts have been written in Eclipse, NOT Visual Studio, so I'm not sure if this will cause restrictions.
You can call UI scripts as you describe and I would additionaly recommend that you use Release Management to do this rather than build. It makes much more sense to use a deployment engine rather than a compilation engine to maintain this. One does not usually have an instance of ones application running on the build server.
http://nakedalm.com/execute-tests-release-management-visual-studio-2013/
You need to get a few things lined up, but it worked pretty good..
I used playframework previously. Development with play! is so fast. It has an internal java compiler and all the actlon methods are static. So the result is awesome.
Nowadays i use spring on netbeans. Netbeans has a deploy on save feature. But redeployment time is greater than 10 seconds. I used jrebel. But jrebel does not give the same effect. I used eclipse. Eclipse is worst than netbeans. Why java development should be so difficult? Is there any method for fast redeployment?
You have already mentioned JRebel. There are other options, but they are not faster. For example, WTP plugin for Eclipse. You can use jetty-maven plugin, you can use emended jetty-server for development. You can use file-sync plugin for Eclipse. This is 3 most popular and fastest way to deploy project. But all of them require redeploy of server.
You will never get this speed like Play framework or some dynamic compiler language. But probably it's not necessary ?
If you change static resources, like jsp, js, css, you don't need deploy. If you change Java code, just test your code with JUnit or something else. Or write a bunch of code and make deploy
IMHO the more experience you gain, rarely you make deploy =) You don't need to check, what's going on, because you know exactly, what you are doing =)
The reason why Play deployment is so fast, is that it isn't an actual deployment in the original sense of the word. Play checks for the modifications in your Java code, then takes just that file and compiles it and changes the state of the JVM to incorporate the new class.
A real deployment to an application server or event to "just" a servlet container is more than that. The package (war, ear) has to be expanded. Internal structures of the app server has to be updated and the app has to be started. This all takes time because much more components are working together.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Anyone out there have experience with both Hudson and Bamboo? Any thoughts on the relative strengths and weaknesses of these products?
Okay, since folks keep mentioning other CI products I'll open this up further. Here are my general problem. I want to setup a CI system for a new project. This project will likely have Java components (WARs and JARs), some python modules, and possibly even a .NET component. So I want a CI server that can:
Handle multiple languages,
Deploy artifacts to servers (i.e. deploy the war if all the unit tests pass.)
I would also like something that integrated with a decent code coverage tool.
Good looking reports are nice, but not essential.
Multiple notification mechanisms when things go wrong.
I'm not worried about hosting. I'll either run it on a local server or on an Amazon instance.
Also, this maybe pie in the sky, but is there something that can also build iPhone apps?
Disclaimer: I work on Bamboo and therefore I am not going to comment on features of other CI products since my experience with them is limited.
To answer your specific requirements:
Handle multiple languages
Bamboo has out of the box support for multiple languages. Customers use it with Java, .Net, PHP, JavaScript etc. That being said, most build servers are generic enough to at least execute a script that can kick off your build process.
Deploy artifacts to servers (i.e. deploy the war if all the unit tests pass.)
Bamboo 2.7 supports Build Stages, which allow you to break up your build into a Unit Test Stage and a Deploy Stage. Only if the Unit Test Stage succeeds, the build will move on to the Deploy Stage. In Bamboo 3.0 we will support Artifact sharing between stages, allowing you to create an Artifact (e.g. your war) in the first Stage and use this Artifact in the following Stages for testing and deployment.
I would also like something that integrated with a decent code coverage tool.
Bamboo comes with support for Clover and also has a plugin available for Cobertura.
Good looking reports are nice, but not essential.
Bamboo has a whole bunch of reports which are nice, but not essential :)
Multiple notification mechanisms when things go wrong.
Bamboo can notify you via email, RSS, IM, an IDE plugin or a nice wallboard that is visible to the whole team.
I'm not worried about hosting. I'll either run it on a local server or on an Amazon instance.
From experience, it is generally cheaper to host your own CI server. But if you need to scale, Bamboo makes it easy to distribute your builds to additional local agents or scale out to Amazon via Elastic agents.
Also, this maybe pie in the sky, but is there something that can also build IPhone apps?
Similar to the answer to your first question, most CI servers will be able to build iPhone apps in some ways. It's possible that there is a little more scripting required though.
Price: Bamboo is not free(apart from our free starter license)/libre/open-source, but you will get Bamboo's source-code if you purchase a commercial license and full support. Compared to the cost of computing power and potential maintenance required for a CI server, the cost of a Bamboo license is rather small.
Hope this helps.
I have not used Bamboo but I have used Hudson, Cruise and TFS and out of all of them Hudson was hands down the best. It is ridiculously easy to set up and has a really nice web GUI for project configuration. What is great about Hudson is that it supports pretty much any language and feature you could want assuming someone has written a plug-in for it, which they probably have.
http://wiki.hudson-ci.org/display/HUDSON/Plugins
We used it to run .NET, Java and C++ builds on timed intervals as well as SVN checkins with automated test harnesses and it was great. The place before last I worked at started some iPhone development just before I left and I believe they were using Hudson for that too.
Plus it's free!
Bamboo vs Hudson, at a very superficial level, seems to come down to:
Bamboo: Easy to use and good looking
Jenkins: Rough around the edges, but is far more flexible than Bamboo
Both Bamboo and Jenkins have numerous bugs (you will run into problems) but at least with Jenkins you are much more likely to have a workaround until it's fixed. With Bamboo, you're stuck waiting for an update.
Disclaimer: I'm working with Jenkins.
In our organization (quite big, more than 100 developers), we found also these two features very useful:
CAS plugin with matrix project security strategy
Build Pipeline Plugin
LTS release schedule.
About your questions:
OK
SCP PLUGIN or SSH PLUGIN
We use FINDBUGS, Static Analysis Collector Plug-in, Static Code Analysis Plug-ins, Task Scanner Plugin
Previous at point 3 + Jenkins DocLinks plugin
We use email Jenkins Email Extension Plugin, but it supports also other systems, like rss, twitter publish, sms...
We are running in a Tomcat Hosting, Locally.
Yes.
Well, I haven't used Bamboo so far, but one difference is that Hudson is free/libre/open-source software.
If you're willing to pay for it, Anthill does all of these you're looking at. We use it at my firm for our web team, and it's pretty powerful.
Handle multiple languages
Out of the box, it automates your existing scripts and manages the artifacts they produce no matter what language.
Deploy artifacts to servers (i.e. deploy the war if all the unit tests pass.)
Deployment can be added as a step in your build process. I'm not sure you'd want to deploy directly to production, but you certainly could if management says you have to.
I would also like something that integrated with a decent code coverage tool.
They integrate out of the box with Clover, Cobertura, Emma, Checkstyle, CodeSonar, Coverity, FindBugs, Fortify, Klocwork, PMD and Sonar.
Good looking reports are nice, but not essential.
I'm not sure what reports are available but there is a reports tab (I don't go in there :-) )
Multiple notification mechanisms when things go wrong.
I know it can do email (and therefore sms), integrates with a few IM services.
I'm not worried about hosting. I'll either run it on a local server or on an Amazon instance.
I saw a demo of them firing up a cloud session from an image, complete with an agent for deployment. We run it on a typical Linux box, but I know some folks run it on a VMWare server.
Also, this maybe pie in the sky, but is there something that can also build IPhone apps?
This would fall under the first one, probably.
What Java web development environment is the best for absolutely minimizing the build-deploy-test cycle time?
Web development environment: JBOSS, Tomcat, Jetty? Deploy WAR exploded? Copy WAR or use symbolic links? There are factors here I don't know about.
Build-deploy-test cycle? The amount of time it takes to test a change in the browser after making a change to the source code or other resources (including Java source, HTML, JSP, JS, images, etc.).
I am looking to speed up my development by reducing the amount of time I spend watching Ant builds and J2EE containers start. I want the Ruby on Rails experience --- or as close as I can get.
I'd prefer a solution that is web framework agnostic, however if a particular framework is particularly advantageous, then I'd like to hear about it.
Assume all the standard tools are in use: Hibernate, Spring, JMS, etc. If stubbing/mocking support infrastructure is required to make this work, I'm OK with that. In fact, I'm OK with having a development environment that is very different from our production environment if it saves me enough time.
You should probably take a look at Javarebel:
http://www.zeroturnaround.com/javarebel/
and this thread here:
How to improve productivity when developing Java EE based web applications
JBOSS uses Tomcat for its servlet/JSP engine, so that's a wash.
Tomcat does support hot deploy.
Jetty's pretty small and starts quickly, but it doesn't support hot deploy.
Eclipse is merely an IDE. It needs a servlet/JSP engine of some kind. If it's like IntelliJ, you can use any Java EE app server or servlet/JSP engine you'd like.
IntelliJ is pretty darned fast, and you don't have to stop and start the server every time you rebuild. It works off the exploded WAR, so things happen fast.
Building (used to be compiling) is a a sign of our times. We need quick validation of our thoughts and our actions. Whenever I find myself building to many times it is usually a sign that I'm not focused. That I don't have a plan. For me this is the time to stop and think. Do a list of things that need to be done (this is web framework agnostic) do them all and test them all after one build.
Jboss Seam together with the Jboss Developer Studio is good for hot deploying everything aside from EJBs (SLSB, SFSB and Entities need redeploy).
Have you considered Grails?
Deployment is as fast as it can get with Google App-Engine + GWT (optional) + Eclipse Plugin.
Never seen anything faster.
Maven 2 and eclipse. mvn eclipse:eclipse <- pure awesomeness. Also, WTP within eclipse works great (and maven generates working WTP projects).
Small web containers will load faster than overloaded webcontainers with the kitchen sink built in (.. cough .. jboss ).
Some design decisions slow build times (e.g. aspect-weaving based toolkits add an aspect-weaving phase to compile times).
Avoid building components that can only be tested after long elaborate load cycles. Caches are a prime culprit here. If your system has deep dependencies on a global cache scattered everywhere you'll need to load the cache every time you need to test something.
Unit-testable components, so you can run pieces instead of the whole thing.
I find that projects built reasonably compile, deploy, and startup in a few to 10 seconds, which is usually fine.
GWT in eclipse is probably the fastest I can think of. Using the hosted mode browser for your tests you can debug and change your code without restarting anything. Just need to click the refresh button in the browser and the changes are there (java, css, etc). One other thing is that GWT is adding this same support to normal browsers (Firefox, IE, Safari) so you can debug from within them the same way. These changes are coming in 2.0. See http://code.google.com/events/io/sessions/GwtPreviewGoogleWebToolkit2.html
Have you tried using Eclipse Java EE and then tell it to deploy to a server managed by Eclipse? Tomcat and JBOss works pretty well in this way. Also allow you to change code in a method, use Ctrl-S and have the class updated inside the server.
MyEclipse also works pretty well like this.
JRuby on Rails. Develop on whatever platform you want, deploy to standard Java servers.
I think the best way to avoid the long build deploy tests cycles is writing unit tests for your code. This way you can find bugs without waiting for the build/deploy phases.
For JSP you can edit the JSP files directly in the JBOSS work folder:
> cd $JBOSS_HOME/server/default/tmp
> find -name myJspFile.jsp
./tmp/vfs/automountd798af2a1b44fc64/Jee6Demo.war-bafecc49fc594b00/myJspFile.jsp
If you edit the file in the tmp folder you can test your changes just hitting the browser refresh button.