Develop Reference

Trying to understand what gradle and maven actually do

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.

Can Intellij IDEA exist in a Netbeans Shop?

All my other colleagues use Netbeans, but I have an opportunity to use IDEA. Will we be able to work on the same Java EE projects together, or will we have issues with projects, checking in and out of SVN, etc?
We primarily develop EE and Spring MVC applications using Glassfish on our desktops, and commit to an SVN, although it is possible that I may have to load a coworker's entire projec.

As long as you are using some standard, IDE-agnostic build tool like maven, I see no problems. I work on IntelliJ IDEA while my colleagues use Eclipse - no issues except different formatting rules or import order - all of this can be customized.
Subversion (or any other VCS) is the least of your problems. Even if the rest of your team pushes Netbeans project metadata files, IntelliJ will simply ignore them.

If you use Maven as your build tool, then yes (and Eclipse too).
All three have tooling allowing them to work well with Maven projects.
If you are using "plain" Netbeans projects I do not think that IDEA can work with them. If so, I suggest you lobby for the change. Maven is one of the investments that pay well of.

Why would you want to fly in the face of convention and be the only one on a different IDE? You'll waste time on issues that nobody else has, have formatting hiccups, struggle with pair programming etc.
As much as I like freedom of choice, the development environment within teams should be consistent.

I thought build tools like ant, maven or gradle are de-facto standart of java ee industry. Purpose your teammates to use it.

You will have issues with sharing projects, because the project folder and structure for Netbeans and IDEA is different.
However, you can attempt to share your src folders with one another and update your codes with one another through SVN, though I wouldn't advise it for compatibility reasons because you won't be able to properly share libraries and use other team functionality available in NetBeans.
So it won't be a good idea to use a different IDE so you don't waste time debugging compatibility.
Also, its useful to note that IDEA uses its own custom libraries for certain functionalities, and also build projects in a different way from NetBeans, so projects that appear to work on IDEA may not work on NetBeans and vice versa.
Bottom line, don't waste your time using a different IDE from the rest.

Starting to think that Maven is overkill for my current project

I am working on a Spring Web Project that we are using Subversion, Eclipse and JBoss to build it.
The way we have it now is that we check everything into Subversion, the source code, jars that the project needs (Spring, Log4J, etc), so at any time someone can go to Subversion and rebuild the project.
Most of the projects at this firm only have one programmer on each project and the firm only has 3 programmers anyway. We are thinking about using Maven, but I am starting to think that it is overkill... Can I please get some feed back about your views on this?

If you have a system that works for you, then don't change it.
On the other hand Maven helps a lot in keeping up with dependencies changes.
In most cases with Maven you have to update a dependency version in one place and a new version of that dependency is there ready to be tested and used.
If you decided to switch to Maven, you must have some kind of local repository management system like Nexus. Think of it like a source control for your binary dependencies. Another must would be Maven support in your choice of IDE. I think at this point all major Java IDEs have it.
At one point I was exactly in the same predicament and decided that it was worth it to switch (and it was).
However, mastering the whole setup may be daunting. If nobody at your company did it before, I think it may take somebody on your team 4-6 weeks to do a conversion project (learing Maven concepts, setting up POMs, integrating with IDE, etc.). Hence weigh carefully future benefits against current deadlines.

Java EE: Need better deployment system

We are currently using JDeveloper to build our production EARs. One problem with this is that if the developer doesn't add new files to a VCS, then that developer is the only one capable of making EARS, and therefore he can use unversioned files as well.
What would be a good system that seperates this, so that EAR files can be correctly produced without depending on the local developers workspace (this would also ensure that they add their files to a VCS before allowing to make a deployment/check-in).

One problem with this is that if the developer doesn't add new files to a VCS, then that developer is the only one capable of making EARS,
If the developer doesn't use the VCS, this is not your only problem:
You cannot reproduce things in another environment, you're tied to the developer machine (but you're aware of that). What if he is sick?
Not versioning files means you don't have any history of modifications and that you don't know what you put into production ("Hmm, what is in this version? Wait, let's open the EAR to check that.").
And last but not least, in case of hardware failure (e.g. a hard drive crash), you can say good bye to everything that is not in the VCS.
So, the first thing to fix is to ALWAYS version files, even if there is only one developer as working alone doesn't save you from the mentioned problems. These points should be reminded (the developer needs to be aware of them to understand their importance).
To make sure this happens, you should actually not rely on the developer machine to build the EAR but rather rely on an "external" process that would be the reference. You want to avoid this syndrome:
alt text http://img716.imageshack.us/img716/9901/worksonmymachinestarbur.png
To put such a process in place, you need to automate the build (i.e. your whole build can be run in one command) and to break the dependency with your IDE. In other words, do not use the IDE to build your EAR but rather use a tool like Maven or Ant (which are IDE agnostic). That would be the second thing to fix.
Once you'll have automated your build process, you could go one step further and run it continuously: this is called Continuous Integration (CI) and allows to get frequent, ideally immediate, feedback about changes (to avoid big bang integration problems). That would be the third thing to fix.
Given your actual toolset (which is far from ideal, there is not much community support for the tools you are using), my recommendation would be to use Ant (or Maven if you have some knowledge of it) for the build and Hudson for the continuous integration (because it's extremely easy to install and to use, and it has a Dimensions plugin).

Here's my recommendation:
Get a better IDE - IntelliJ, Eclipse, or NetBeans. Nobody uses JDeveloper
Have developers check into a central version control system like Subversion or Git.
Set up a continuous integration facility using Ant and either Cruise Control or Hudson to automate your builds.

What we do is use cruisecontrol. It does two things, it lets us do continuous integration builds, so that we have nightly builds as well as lightweight builds that get built every time a change is checked it.
We also use it to more specifically address your issue. When we want to ship, we use cruisecontrol to kick off a build, that is tagged with the proper production build version. It will grab the code from our version control system (we use SVN) and will build on that, so it is not dependent on developers local environments.
One thing you might also want to consider is creating a production branch to build out of. So, production ears for a particular release are always built from that branch. This way you have even have a bit more control over what goes into the build.

Instead of doing builds from developer workspaces, setup Maven, and have something like Hudson run your Maven build. The artificats of this build (your ear) gets deployed.

Eclipse Web Tools Platform (WTP) vs NetBeans - IDE for Java Web Development

When going to Java Web Development such as JSP, JSPX & others.
What IDE do you consider Eclipse or NetBeans?
What are its advantages and disadvantages?
Which is better preferred in-terms of developing Web Applications such as Websites, Web Services and more. I am considering NetBeans because it has already bundled some features that will allow you to create and test web applications. But is there a good reason why choose Eclipse WTP?

From a micro perspective, Netbeans is a more consistent product with certain parts more polished such as the update manager. I am sure you will find all everything you need in there.
Eclipse is sometimes a little less stable simply because there is still alot of work going on and the plugin system is usable at best. Eclipse will be faster because it uses SWT which creates the UI using native code (so, it will look prettier as well).
At a macro perspective thought, I'm sure you've heard on the news of the recent acquisition of Sun by Oracle. Well, let's just say I'm pretty sure Netbeans is pretty low on Oracle's priorities. On the other hand, Eclipse has big blue (IBM) backing it. So, in the long run, if you don't want to end up in a dead end, go for Eclipse.

I used both Eclipse and NetBeans. I like NetBeans more than Eclipse. From Java editor point of view, both have excellent context sensitive help and the usual goodies.
Eclipse sucks when it comes to setting up projects that other team members can open and use. We have a big project (around 600K lines of code) organized in many folders. Eclipse won't let you include source code that is outside the project root folder. Everything has to be below the project root folder. Usually you want to have individual projects and be able to establish dependencies among them. Once it builds, you would check them into your source control. The problem with Eclipse is that a project (i.e .classpath file) dependencies are saved in user's workspace folder. If you care to see this folder, you will find many files that read like org.eclipse.* etc. What it means is that you can't put those files in your source control. We have 20 step instruction sheet for someone to go through each time they start a fresh checkout from source control. We ended up not using its default project management stuff (i.e. classpath file etc). Rather we came up with an Ant build file and launch it from inside Eclipse. That is kludgy way. If you had to jump through these many hoops, the IDE basically failed.
I bet Eclipse project management was designed by guys who never used an IDE. Many IDES let you have different configurations to run your code (Release, Debug, Release with JDK 1.5 etc). And they let you save those things as part of your project file. Everyone in the team can use them without a big learning curve. You can create configurations in Eclipse, but you can't save them as part of your project file (i.e it won't go into your source control). I work on half dozen fresh checkouts in a span of 6 months. I get tired to recreate them with each fresh checkout.
On the other hand, NetBeans works as expected. It doesn't have this project management nightmare.
I heard good things about IntelliJ. If you are starting fresh, go with NetBeans.
My 2cents.

I use Netbeans mostly for development, and can say it's pretty good in providing most of the features I need. Code completion, one click compiling and deployment, even version control. If you need a feature not found in the core, you can also choose from a good variety of plugins. As far as I am concerned, Eclipse have a very similar feature set, though I did not work with it in detail.
However, netbeans have serious memory problems, and is very demanding on available memory, and I have seen it eat up 400-500MB of ram after repeatly deploying my app for debugging. Other than that, I say Netbeans is quite fast (if memory is adequate).

Aptana for Eclipse was I using some months ago but changed to NetBeans. It has less feature but the out-of-the-box things were nearly the same as Aptana after 2 hours customization.
Each software has some slowdowns and memory leaks, some annoying code validating bugs.
But NetBeans is better in code completing, rarely slows down, can manage 1 mb javascript files. That's why I changed from Aptana for Eclipse to NetBeans.
Other Eclipse tools I used before was lacking the things which are in Aptana and NetBeans by default. And although I am using some plugins, I don't like hacking on the IDE for days to achive a usable program.
For me:
NetBeans +
Eclipse -

From my own experience, while Eclipse provides you with tons of plugins, that is not always guaranteed to meet your expectation. I had so many problem with Eclipse plugins, ranging from different versions of Eclipse itself to the multiple plugins prerequisite for a plugin.
Plugins in NetBeans is so easy to install, but yea, it is not as many as Eclipse's.
Feeling clunky while using Eclipse also led me to move to NetBeans. While SWT is nice GUI, its load time takes considerably a long period of time compared to NetBeans Swing. But, be warned, NetBeans feels good if and only if you are using Windows platform. Apparently Swing in Linux (at least on Ubuntu 10.10) blows. Each time I click on a file in Project Manager, it tries to rename it. But this happens only if you use NetBeans in Linux.
Another point of me moving to NetBeans is the project management window. In Eclipse it sucks and does not work as what I expected. If you had ever use Visual Studios IDE project/solution view, NetBeans is the closest one resembling it.
Both consumes a lot of memory. Even worse, the Swing GUI takes a long time to load after you wake up your machine from Hibernate/Sleep. No joke. Happens to me all time.
Anyway, this is purely my opinion. Hope this helps.

Go for eclipse for unlimited plugins(free).

I was a fan of Eclipse for long time. Specially when I developed plugin and Android program.
Now I have to work with some project with maven build system and tomcat (web app), and found Eclipse too much complicated to load and debug and changes to take effece from any jsp file. And Netbeans is so smart in this regard. Even debugging with Tomcat webapp is so easy with Netbeans. So I moved to Netbeans.
At least for now, for web app development, Netbeans is the best, I guess.
Also auto completion in Eclipse for Mac, is a nightmare to me. I could not make it work with Ctrl+Space, since its a shortcut for Sptolight/Keyboard change by default. I did not use netbeans with mac yet, but I shall try.
For GUI, the WindowBuilder or Jigloo, always crush in Mac. Netbeans GUI designer was better in that sense.