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.
Related
I have a habit/policy of creating many smaller maven projects rather than bigger monolithic ones. By doing this I have ended up with several projects, and several things to do. For example, I maintain each of these projects in their own GitHub repository, which becomes an additional task. Then the worse part of this is, pushing to the maven central. It seems pretty complex, and I have multiple accounts to deal with. It becomes more difficult, as the POM becomes more and more complex with features like GraalVM, JavaFX, JSweet, Maven shade plugin etc.
I was wondering how others are dealing with this problem.
I take two examples
JavaFX / GluonVM, for example, has a web tool - https://start.gluon.io which allows us to select what all we need and creates a maven project for us with those settings. This is over and above having archetypes.
Similarly, Quarkus website also has something, and they also have a CLI tool to create new projects https://quarkus.io/guides/cli-tooling#project-creation
I think maven archetypes are not going to work because requirements evolve over time. For example, when I start I might not be interested in GraalVM or publishing the code to Maven central (or even if I am interested I might not be ready yet).
Other avenues are Gradle, SBT, Mill, and all other kinds of build tools.
However, I find the support is best for maven, as in, all plugins are most up to date in maven only - for example, the JavaFX GraalVM plugin for maven seems to be more stable than their Gradle plugin. I am more used to Maven.
I even considered building a DSL for maven, in Java and running it with JBang. Someone already walked on that route and ended up being one of the developers of the mill build toolkit.
What are other known effective, efficient, worth exploring ways of making maven projects, fast and efficiently? I say efficiently because I can't memorize so many settings and configurations, there must be an easier way around this, which I can teach to the new people joining the team also.
I have seen many interesting (and duplicated) questions here about "sharing or using classes between projects".
I see this as quite practical but the proposed solutions I have read about definitely assume certain prerequisites such as:
shared eclipse workspaces
projects that can be made as dependencies of oneanother
common servers such that classpaths can be added with local urls
While likely acceptable solutions, I am looking for an alternative with perhaps greater flexibility and portability.
I am thinking of learning how to use gradle (or maybe maven, I haven't fully committed to one or the other yet). And from what I understand it may be possible to manage shared classes with one of these dedicated dependency management programs.
Theoretically is this possible? Can I setup a gradle or maven enabled java project to handle and keep uptodate personal classes on a local server or folder on a portable drive or cloud mirror?
The way I understand dependency management at the moment (on a superficial level, I know the devil is in the details) is that for a configured dependency management enabled project, gradle/maven will handle classpath additions and the actual version specific comparison, retrieval and storage (and maybe even compilation is possible but I don't know about this) of JARS from external sources.
Rather than go through the steps to setup classpaths to jars I have to keep current and compiled myself as proposed in many other answers, I am considering creating a dummy project on a server that I can put generic classes which I could then point numerous individual gradle/maven enabled java projects to use. (I think most people would be able to keep them as stand alone classes, but I think I might need to keep them in a dummy project to be developed and debugged in context from a main class. I am somewhat new to java architecture so if the only thing that would make this solution impossible is pointing to a "project" instead of a "library" I can definitely adjust from there. (Assuming I am even applying the concept of the "library appropriately).)
Other info:
I would like this to simplify personal dependency using both Netbeans and eclipse IDE's and work cross platform (but Linux and Windows is what I plan to test it on)
So you're looking for portability, and you don't want to compile your java class that you want to share between projects. And you don't mind a local deployment.
The first thing that comes to mind for me is Git - I'm not sure if Gradle/Maven deal in the gritty underworld of the uncompiled. Composer will pull in git repos for php, so that got me thinking.
If you're happy with one-way sharing of code among projects, Git has submodules that let you do that.
But searching around, apparently there's a git script that goes one step further - Git Subtrees. I also found an intriguing tutorial that will allow you to make changes to common code that you change while working on any particular project that shares it - so obviously be careful - but check it out and see if the Subtrees script might suit your needs.
Actually, I don't see too much sense for dependency management on a "class level". Typically you would bundle your classes in a jar file, which in turn can be considered as a unit with a particular functional range. Such a jar is suitable to be put in a dependency management.
If you are new to such tools, I'd recommend Maven. It is widely used in the Java world and well-integrated in common IDEs. If you stick to its conventions, it will take care of your whole build process from compiling, testing to packaging. There are a lot of plugins available that let you customize practically everything in a simple XML based configuration. You'll have your first project running in 30min and your current project migrated in another 30min.
To share your code with others, you still need a repository where you can upload your Maven-built artifacts to. Depending on your preference there are many possibilities. Shove it to Amazon S3, Maven Central or install your own Sonatype Nexus in your private network.
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.
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.
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.