We Keep Coding

Why do we need Gradle in Java? [duplicate]

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

How to check Eclipse plugin performance

I am new to Eclipse plugin development.
I have been modifying a plugin that was used in our team, and i don't want to add new bottle-necks.
Also the eclipse to which i am integrating to is taking too much time to install the plugin. any suggestion on how to identify the reason for that?
So i would like to know some tips on
How to check performance of a plugin - any tools that are available. (like jprofiler in java or any other performance analyser tool)
How to check for bottleneck in my plugin code using some tools.
And is there a doc that tell the do's and don't of the plugin development.

Examining performance of a plugin isnt that much different from any ordinary java program. It works in similar ways. Look at this question for example.
It takes long to install; It seem like that would be an issue of the underlaying program, P2, rather than your plugin. At installation of a plugin your manifest is read, some information about your extensions are saved in Eclipse. The actual plugin is copied. Dependencies checked. It seems like these things shouldn't take that long, unless you have a very large plugin?
Perhaps you are installing the plugin into an environment that already have alot of plugin? Try downloading a clean Eclipse, do you have the same issue there?
Make sure you don't set your plugin to start automatically when the user starts Eclipse. That is bad behaviour that causes clutter and general slowdown for the users. The plugin should be started when the user actually wants to use it, not a second before.
Also my answer to this question might help with the general design of the plugin.

First of all, measure everything, as you should never try to optimize just by guessing performance bottlenecks. I recommend Yourkit for all Java code (Eclipse plugins as well as plain Java code).
The second important thing: If you have functionality that takes more time than the twinkling of an eye, make it a job in Eclipse, so it can run in the background. It is fine for something to run some seconds, if it does not stop the user from working.

Java Application Deployment/Installer Options?

I'm looking for advice on good options to deploy Java applications on end user systems.
Our end users are not tech savvy experts but casual computer users who can't be expected to figure out directories and version conflicts.
Runnable jar is not practical because we need to provide VM parameters. Batch files are not practical because for whatever reason, java.exe is not on the $PATH in a huge amount of Windows system.
Webstart is an option, but our users commonly complain that no shortcuts are created (a feature that's apparently broken), every click on the website prompts a new download, and a plethora of other issues make this option seem incredibly unprofessional to the end user.
Many of the things one finds when googleing for Java deployments are themselves built with Java, which means they won't run either on a system with a missing or broken Java installation.

If you do not want to spend any money, a popular solution is izpack.
If you're looking for a commercially supported solution, there is install4j (Disclaimer: My company develops install4j). The installer is a Java application here as well. However, it is started by a native launcher that can download a JRE bundle from your server on the fly. You can also statically bundle a private JRE. See here for more information on JRE bundles.

Webstart is an option, but our users commonly complain that no shortcuts are created (a feature that's apparently broken), every click on the website prompts a new download, and a plethora of other issues make this option seem incredibly unprofessional to the end user.
Many webstart deployments are quite unprofessional. Make sure any deployment that is showing problems is validated using JaNeLA. For the shortcuts specifically, look into the IntegrationService of the JNLP API for establishing them after launch, with feed-back.
Ultimately though, APIs will have bugs. If you find one in web start, please report it on the bug database (v. broken at the moment, but you have to try).
Many of the things one finds when googleing for Java deployments are themselves built with Java, which means they won't run either on a system with a missing or broken Java installation.
As to missing or too low version Java, use deployJava.js to ensure a suitable JRE is present. No ideas on the broken installs.
I doubt you will swing back to JWS for this immediate deployment, but please investigate it according to the ideas outlined above, for future use.

What's with all the Java Build tools?

what's the point of using ant, maven, and buildr? won't the using build in eclipse or netbeans work fine? i'm just curious what the purpose and benefit of extended build tools are.

Dependency Management: The build tools follow a component model that provides hints on where to look for dependencies. In Eclipse / Netbeans, you have to depend on a JAR and you don't really know if this JAR has been updated or not. With these build tools, they 'know' updates in dependencies (generally because of a good integration with your source control repository), recalculate transitive dependencies and ensure that everything is always built with the latest versions.
Access Control: Java, apart from class level access control, has no higher abstraction. With these build tools you can specify exactly which projects you want to depend on you and control visibility and access at a higher level of granularity.
Custom Control: The Eclipse / Netbeans build always builds JAR files. With custom build mechanisms, you could build your own custom (company-internal) archive with extra metadata information, if you so wish.
Plugins: There are a variety of plugins that come with build tools which can do various things during build. From something basic like generating Javadocs to something more non-trivial like running tests and getting code coverage, static analysis, generation of reports, etc.
Transport: Some build systems also manage transport of archives - from a development system to a deployment or production system. So, you can configure transport routes, schedules and such.
Take a look at some continuous integration servers like CruiseControl or Hudson. Also, the features page of Maven provides some insight into what you want to know.

On top of all the other answers. The primary reason I keep my projects buildable without being forced to use NetBeans or Eclipse is that it makes it so much easier to setup automated (and continuous) builds.
It would be rather complicated (in comparison) to set up a server that somehow starts eclipse, updates the source from the repository, build it all, sends a mail with the result and copies the output to somewhere on a disk where the last 50 builds are stored.

If you are a single developer or a very small group, it can seem that a build system is just an overhead. As the number of developers increases though it quickly becomes difficult to track all changes and ensure developers are keeping in sync. A build system reduces the rate of increase of those overheads as your team grows. Consider the issues of building all the code in Eclipse once you have 100+ developers working on the project.
One compelling reason to have a separate build system is to ensure that what has been delivered to your customers is compiled from a specific version of the code checked into your SCM. This eliminates a whole class of "works on my box" issues and in my opinion this benefit is worth the effort on its own in reduced support time. Isolated builds (say on a CI server) also highlight issues in development, e.g. where partial or breaking changes have been committed, so you have a chance to catch issues early.
A build in an IDE builds whatever happens to be on the box, whereas a standalone build system will produce a reproducible build directly from the SCM. Of course this could be done within an IDE, but AFAIK only by invoking something like Ant or Maven to handle all the build steps.
Then of course there are also the direct benefits of build systems. A modular build system reduces copy-paste issues and handles dependency resolution and other build related issues. This should allow developers to focus on delivering code. Of course every new tool introduces its own issues and the learning curve involved can make it seem that a build system is a needless overhead (just Google I hate Maven to get some idea).

The problem with building from the IDE, is that there are tons of settings affecting the build. When you use a build tool all the settings a condensed in a more or less readable form into a small set of scripts or configuration files. This allows in the ideal case anybody to execute a build with hardly any manual setup.
Without the build tool it might become next to impossible to even compile your code in let's say a year, because you'll have to reverse engineer all the settings

Different features. For example Maven can scan your dependencies and go download them, and their dependencies so you don't have to. For even a medium sized project there may be a very large number of dependencies. I don't think Eclipse can do that.

#anonymous,
Why do you I assume that me, a member
of your team, is using an IDE all the
time? I might want to build the code
on a headless build server, is that
ok?
Would you also deny me the right of
using a continuous integration
engine?
May I fetch dependencies from a central repository please? How can I do that?
Would you tie me to a specific IDE? I can't run Eclipse easily on my very old laptop, but I'll buy a new one.
Maybe I should also uninstall subversion and use patches or just zip folders on a sftp/ftp/Samba share.

The build tools allow you to do a build automatically, without human invention, which is essential if you have a code base being able to build many applications (like we do).
We want to be certain that each and everyone of our applications can build correctly after any code base changes. The best way to check that is to let a computer do it automatically using a Continouos integration tool. We just check in code, and the CI server picks up there is a change and rebuilds all modules influenced by that change. If anything breaks the responsible person is mailed directly.
It is extremely handy being able to automate things.

To expand on Jens Schauder's answer, a lot of those build options end up in some sort of .project file. One of the evils of Eclipse is that they store absolute path names in all of it's project files, so you can't copy a project file from one machine to another, which might have its workspace in a different directory.
The strongest reason for me, is automated builds.

IDEs just work on a higher abstraction layer.
NetBeans nativly uses Ant as its underlying build tool and recently can directly open maven projects in NetBeans. Hence, your typical NetBeans project can be compiled with ant and your maven project already is a NetBeans project.
As with every GUI vs CLI discussion, IDEs seem easier for beginners but once you get the idea it becomes cumbersome to do complex things.
Changing the configuration with an IDE means clicking somewhere which is easy for basic things but for complex stuff you need to find the right place to click. Furthermore IDEs seem to hide the importent information. Clicking a button to add a library is easy but you may still not know where the library is, etc.
In contrast, using a CLI isn't easy to start with but becomes quickly easy. It allows to do complex things more easily.
Using Ant or Maven means that every one can choose his/her own IDE to work one the code. Telling someone to install IDE X to compile it is much more overhead than telling "run <build command> in your shell". And of course your can't explain the former to an external tool.
To sum up, the IDE uses a build tool itself. In case of NetBeans Ant (or Maven) is used so you can get all the advantages and disadvantages of those. Eclipse uses its own thing (as far as I know) but also can integrate ant scripts.
As for the build tools themselves Maven is significantly different from Ant. It can download specified dependencies up to the point of downloading a web server to run your project.

In all projects, developers will often manually invoke the Build process.but it is not Suitable for large Projects, Where it is very difficult to keep track of what needs to be built, in what sequence and what dependencies there are in the building process.Hence we Use Build Tools for Our Projects.
Build Tools Done varieties of the task in the Application which will do by the Developer in their daily life.
They are
1.Downloading dependencies.
2.Compiling source code into binary code.
3.Packaging that binary code.
4.Running tests.
5.Deployment to production systems.

Java web development environment to minimize build-deploy-test cycle time?

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.