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.
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.
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.
To this day I always use Eclipse for my Java developing stuff but in reason of some strange window handling improvements ;-) I think about a switch to Netbeans.
Based on the fact that other office mates still use Eclise I ask myself is it simply possible to use both IDEs side by side in the same project? What are side effects?
The related projects are all Maven based.
If your project is Maven based, then there should be no need to store IDE-specific files in your version control system (VCS). Consequently, there should be no impact if you choose to develop in one IDE over another, provided they understand POM files.
Each IDE will read the POM and generate it's own local files to cache state about the project. These will be different for each IDE, but since you don't commit those to VCS it doesn't matter. I suspect even if you did commit them, the paths and filenames are likely to differ anyway.
It's plausible some of your Eclipse friends will edit the POM to satisfy the stupid, stupid, stupid m2e connector system, but that should be ignored by other IDEs.
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 have a standard Java application that handles both REST and UI calls. What is the best way for me to create and manage an application version (major.minor.release.build)? I'm using Subversion, Maven, Bamboo (continuous build) and Spring in the stack. I would like the version to be tied together with SVN, Bamboo and Maven. And, would like to be able to log version on start-up -- likely using some Spring bean.
There must be a framework/pattern out there to help with this. I'd rather not roll my own.
Thank you!
Why not use Semantic Versioning? It is what most people expect nowadays, it is pretty well defined and it is out there. Good enough for me.
Maven has a release plugin. This is a bear to setup first but once it is working it works well. It does all the nitty gritty of making sure everything is cleanly checked in, tagged properly, and does the magic with the version numbers. It is not a ask to look forward to, but at least now it is properly done. It pays to setup some maven repository. We use Nexus and can recommend that, but I heard good things of artifactory too.
During testing we do not rely on the maven version too much but on the build number, which we put in a discrete place on the web pages and similar artifacts so we can quickly determine which exact build we're talking about. We use hudson which provides the build number in an environment variable, but Bamboo must provide that too. The filter copy functionality makes that pretty straightforward.
Hudson tags the VCS (we use git, but that does not matter) with the build number and the maven release plugin tags the releases.
You can include the SCM revision number in your artifact using the maven build-number plugin (http://mojo.codehaus.org/buildnumber-maven-plugin/), e.g. in a filtered resource, such as a properties file.
If you are using Artifactory as your binary repo then it can also tag your binary artifacts with a build number and have full traceability from your artifact to the CI server build that created it. Currently this is supported with Hudson, TeamCity and Bamboo.