If you are using a module in multiple projects in IntelliJ IDEA is it common practice to make a new project for these modules or to make the modules in one of the projects they are included in?
It depends on how you're working, whether the common module is developed by you or another team, and other factors. Often, common code is put in a module which produces a jar that the other modules depend upon, and include them all in the same project. This is normal when you're developing the common-code module at the same time as the project and changes are typically committed together (although not necessarily to the same repository or branch). If multiple projects use the common-code module though, and it's developed as a separate library, then it should maybe have a project of its own.
Also, you should probably be using maven when things get this complicated.
Related
We have a EAR project which has a WAR project. Maven is used, so pom.xml. As typical of any project, this project also contains a big feature (say Job Scheduling "JBS") among many other features. As it is planned to retire this whole project in the near future, it is discouraged heavily to spend much on working on this project (whether bugs or enhancements).
Therefore, for the sake of running the (JBS) feature as a separate application, the whole EAR project was duplicated (also to save time/cost). As a result, all the Java packages and classes (necessary for JBS project) were duplicated. In this situation, if we update one or more classes in the main project, this (JBS) feature project/application gets outdated (and needs update).
The fact is that this JBS feature project ONLY requires many packages of Java classes (from the main EAR-WAR project), and do not require 99% of the web modules and others. I am removing all the unnecessary things from JBS project. Then I would like to create a JAR library with all the java classes, so JBS project can have a dependency on this JAR.
I do not know if it is a good idea to separate these classes out of the main project (to create another Java project). I would like to continue to have these classes as part of the main project. Then, it will be good, as and when one or more of these classes are changed, a new version of the JAR will be generated (right away). And the JBS project would then make use of this updated JAR.
How can we accomplish this? I understand, through maven, we can do a build/package jar/war/ear on a project of that nature. I am not an expert with maven (and did not learn it systematically).
But, is there a way to create one or more JARs additionally from inside WAR pom.xml? In other words: I mean pom.xml of WAR will create a WAR. In addition to creating a WAR, can maven help create additional JAR? Or can maven create two packages out of one pom.xml?
Or should I create a separate module in the main project with all these packages/classes, and have its own pom.xml to generate the necessary JAR? For this, most probably I need to modify the structure of the main project. I would like to avoid this unless there is no way out.
Can you advice?
It seems like the best thing for you would be to create a multi-module project that both contains the JAR and the other project. This way, you can easily change/build them together, but you create separate artifacts.
I need to create a Spring MVC web application where each of the services should be created as a separate JAR file. Some of the docs suggest that multiple Maven modules can be used for this. But what I understood is, that each module also needs to be created as a separate Eclipse project.
Can I have all the controllers, service and DAOs in the same Eclipse project, while still creating separate jars for each service (and a war file for the whole application) with Maven?
Short answer:
Yes, you could create multiple build targets (jar files) out of single project by using maven-jar-plugin (profiles, executions).
https://maven.apache.org/plugins/maven-jar-plugin/
Should you do it?
I believe most people will agree with me that you should not do it, you should stick to one of the most important core concepts of Maven: modularity.
Now, Have you asked yourself the question, Do I really need to create multiple modules (jar Files) for my application? Can I manage all pieces of code in one single project?
Maybe you just need some guidance about how to organize your java packages in one single project.
https://dzone.com/articles/layered-architecture-is-good - Using layered architecture
http://www.javapractices.com/topic/TopicAction.do?Id=205 - Packages by feature vs Layers
NOTE: If you think that your project will grow fast and the number of classes will be a large number, it is probably a good candidate to be a multi module application.
If you still have the feeling that you have to create multiple modules, there are several interesting posts about how to address modularity in the design of applications, in these posts they provide very interesting reasons/criteria why you should split your application into modules.
How to decompose a system into modules?
Spring Java Maven Project + Module Design
Good Luck!
What is the problem of separate modules and hence separate Eclipse projects? If you declare a Maven dependency between the modules, you'll be able to have compile dependencies between the classes in the corresponding Eclipse projects.
So I suppose that it is possible to force multiple Maven modules into one Eclipse project, but I don't know any good reason to do so.
I have a top-level maven project with submodules. The first submodule is a Java project which generates some JavaScript library code from the compiler's annotation processor. I want to include those generated JS files into the second submodule, a webpack NPM managed project, for the build and then publish the webpack BACK into the first submodule before packaging into a fat-jar. Does anyone know of a way to accomplish this?
What you describe is a circular dependency. You have to break this circular dependency. (You probably do similar things in your code all the time.)
I have solved the same problem by breaking up the Java project. Once you do that you will recognize that, in fact, your first project was serving two separate roles that then become separated:
From:
Java project with code and assembly
JavaScript project
To:
Java project with code
JavaScript project
JAR-packaged project with assembly
I've often seen this happen in multi-module projects that build into a WAR file, and I've adopted the rule of thumb that the WAR project should not have any Java (production) code, acknowledging its role as the aggregator/assembler.
Some folks will think this third project is frivolous, some always argue that you're easily getting too many Maven modules. I think that often stems from tooling or build pipeline limitations, once you break through those, you can just embrace a growing number of Maven modules, given that the boundaries are chosen well, and I see no problems here.
One hesitation, though: why is the JavaScript project separate to begin with? If it is not deployed separately (evidently it isn't since you're assembling the "fat-jar"), the JavaScript code is following the delivery lifecycle of the "fat-jar", which would benefit from being in the same source repository, so why even make it a separate Maven module? (If they were in separate source repositories, there's a cost in version management between the modules that I'm unsure you have reasons for.) There's no shame in having a monolith (if done well -- it happens, microservices make you believe otherwise, but in that world you'd probably deploy the JavaScript code separately anyway).
What are the best practices for software versioning and multimodules projects with Maven?
I mean, when I create a multimodules project with Maven, what is the best approach for the versioning? To use a single version for all the modules (defined in the top project)? To use a version for each module (defined in the POM of each module)? Is there another approach that I'm missing? What are the pros and cons of each approach?
In general, are the different modules released together (possibly sharing the same version number)?
Thanks
Honestly it depends on what you would like to do. Multimodule projects are created for multiple reasons, one of them being you only need to deploy what has changed instead of all modules.
Think about it this way: if you had a non-multi-module project and you only had to change one line in the services layer, you have to rebuild the entire project and deploy all of the code again...even though only your services layer will change.
With multi-module projects, you can regenerate your project and deploy only what changed...your services. This reduces risk and you're assured that only your services module changed.
You also have a multitude of benefits to using multi-module projects that I'm not listing here but there is certainly a huge benefit to NOT keeping your version numbers of your modules in sync.
When you build your project, consider deploying it to a repository that will hold all compatible jars together for builds (each build creates a new folder with the parent-most pom version number). That way, you don't need to keep documentation about which jars are compatible...they're all just deployed together with a build number.
I was looking for a solution for this exact problem myself and versions-maven-plugin was exactly what I needed. I don't like the release plugin communicating with the SCM system. The versions plugin does just what we need: it sets a new version number in all poms of the project:
mvn versions:set -DnewVersion=2.0.0
Then I can proceed with commits, tags and an official build server build...
EDIT:
The versions plugin depends on how a maven multi-module project has been organised: as a result, it often does not update all POM files in a complex multi-module project.
I've found that sed and find do the job much more reliably:
sed -i 's/1.0.0-SNAPSHOT/1.0.0-RC1/g' `find . -name 'pom.xml'`
Typically you create a multi-module project because you have deemed that the various modules are parts of a single whole. Maybe the client-piece, the controller-piece and the services-piece. Or maybe the UI with services.
In any case, it makes sense to have the version numbers for the various modules to move in lock-step. However Maven does not enforce that as a rule.
As to your question
are the different modules released together (possibly sharing the same
version number)
I would think so. That is one of the reasons for having it a multi-module project. Otherwise you could have the modules as independent projects.
Of course this is the kind of stuff that is rife with edge cases and exceptions ;-)
I had the same problem with a project I`m working on. I also decided to use separate versions and even the dependency to the parent pom only has to be updated if some of the managed dependencies change. (so mostly as #vinnybad describes it)
Two additions
exists-maven-plugin
With the usage of the "org.honton.chas.exists-maven-plugin" only the modules will be deployed to the repository that have actually changed, which is really great, because also the according docker-images will only be published if something has changed on one of the service. This avoids "polluting" the image repository with different but unchanged versions.
versioning
One main downside of the "separated versions" approach are the questions regarding versioning:
What's the current version of my project?
Which module versions work with each other? (even thought they don't directly depend on each other, one does rely on what another does, e.g. they share the database schema)
To solve that I put all module versions into the dependency management part of the parent pom, even if no other module depends on them. A "integration-test" module could solve that by depending on all of the modules - and of course testing them together.
This way I would be "forced" to update the parent pom with every change, since it's referring the released module versions. This way the parent pom would have the "leading" version and at the dependency-management block state the versions of all modules that are compatible with each other (which will be ensured by the integration test).
I have a project called 'talktome', with no runtime dependencies.
Also I have project 'talktome-tools', which depends on 'talktome'.
No problems, until I realize that the unit-tests in 'talktome' depends on 'talktome-tools'.
What solutions are there?
If talktome is a general project where other (e.g talktome-tools) depends on, it should not be depend on the more specific projects. Then, it would be wise to get rid of dependency from talktome to talktome-tools.
Otherwise, you would create a more higher level project (e.g parent) and put necessary interfaces, classes that can be used by both talktome and talktome-tools to the new project.
You may move the tests to another maven module like talktome-tests that will do the integration testing. It makes sense especially it seems that talktome shouldn't depend on specific project like talktome-tools.
And, test dependencies like talktome-tools should be included with test scope.