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.
Related
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.
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.
I recently joined a new team. This team has been using Subversion for their source control. They asked me to investigate the possibility of moving the source code to Git.
This seemed like a trivial exercise until I realized they have a large number of svn:externals. The project is a large Java EE project that consists of several web projects. The team uses svn:externals to share some fixed resources (like css, javascript, etc.) amongst the various projects.
My question is twofold:
Is there a better strategy for sharing resources within a set of Java projects that we could consider, allowing us to remove the necessity for svn:externals and making the switch to git simpler?
If no such better strategy exists, then what are my alternatives?
This is quite a large codebase (lots of revisions and files) so I'd like to take advantage of the performance of git.
Here is the relevant software stack they are using:
Subversion
Eclipse
Maven (2.2.1 IIRC)
Windows (for development), AIX (for production)
Thanks
Sounds like a good case for Git submodules. They should be pretty similar to svn:externals.
Excerpt from the Git Book:
It often happens that while working on one project, you need to use another project from within it. Perhaps it’s a library that a third party developed or that you’re developing separately and using in multiple parent projects. A common issue arises in these scenarios: you want to be able to treat the two projects as separate yet still be able to use one from within the other.
Read more on Git submodules on the Git book: http://book.git-scm.com/5_submodules.html
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.
According to What is Maven the objectives are:
Making the build process easy
Providing a uniform build system
Providing quality project information
Providing guidelines for best practices development
Allowing transparent migration to new features
Can I just make a build script in bash instead?
What is the motivation of using a maven project? Is there any example?
Maven also does dependency management pretty well. This is one of the bigger selling points, but there are a lot more.
It also helps to enforce a standardized project structure. The beauty in that is that I can pick up any mavenized project and pretty much immediately know where all the various files are.
Maven also has a pretty extensive library of plugins that allow for quite a bit... from automating static code analysis (via pmd/findbugs/checkstyle, etc), calculating test coverage, generating javadocs, generating source jars, running a web app in Jetty, etc, etc.
I will tell you that it's not exactly an easy tool to learn, but if you do master it, you learn to appreciate all it can do. If you want me to go into specifics about anything in particular, let me know.
Maven is a tool that handles a lot of the boilerplate project setup and configuration for you. For example, if you wanted a Java project to properly integrate with a build server, provide code coverage information, and produce a jar file that can easily used in other projects around your organization - you could spend weeks setting this up manually using ANT, or you could just 'embrace' the Maven way of doing things.
In addition, you can setup archetypes (and many already exist) that are pre-configured projects for your desired setup. This can be a great way to enforce standards and increase productivity within an organization.
Maven does provide rules that are a bit rigid, but in the end it greatly cuts down on the time required to do many different tasks. I would recommend Maven: The Definitive Guide from O'Reilly as a resource to review.