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).
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 am currently starting my adventure with Maven, and I actually don't understand the idea behind using it to automate compilation of my source code. For the time being I am working on small projects with up to 15-20 classes, and 1 main method in the "app" class. Could someone please give me the explanation with examples, when it's necesarry (or recommended) to use build automatation tool to compile the source code and how could I benefit from using it regarding source code compilation?
Thank you very much in advance!
I was looking for different answers and I have a lot of work to do but since I've seen this question, as a Maven fanboy, I couldn't resist anymore and this below is my answer.
First of all, I agree with JF Meier which answered before me, but I think the answer can be improved.
IMO you have to consider Maven not just as a build tool, but as a multi-purpose tool which can help you to do very different things. The best 3, for me are:
Compiler. Obviously. Maven allows you to easily compile giant projects with a lot of submodules, even if some of these modules are interdependent one with each other.
Dependency and repository manager. Maven allows you to automatically download third party software and bind this downlaod to the build. This is immediately understandable if you think to framework or api dependencies from big corps (Apache found., Spark, Spring, Hibernate and so on ...) but it's really powerful in every enterprise context.
Example: you have a Maven project (let's say project A) which manages requests coming from a webservice and provides responses. This Maven project relys on another Maven project (let's say project B) which actually generates webservice jar and uploads it to a company repository. Well, when you have to add a field or a method to the webservice you just have to implements new software in project B, upload it the repo and change the version in Maven poms in both project A and B. Voilà: now EVERY developer of the company just have to "mvn clean install" project A to have the new version.
Sources and code automatic generator. Since Maven 2.x are available a lot of plugins (from Apache found. and others) which allow you to generate code and sources (tipically xml files) starting from little to none implementations.
Example 1: CXF plugin is commonly used to generate java classes from xml or xsd files.
Example 2: JAXWS plugin is commonly used to generate wsdl from SOAP webservice implementations or implementation starting from wsdl file.
Do you feel the power now?
-Andrea
The question is not very specific, but I will try to answer.
Usually, you want your source code to end up in a jar or war, so that you can use it as a library or run it somewhere (e.g. on an application server).
Maven not only compiles the classes you have and creates the final artifact (jar, war), but also handles your dependencies, e.g. the libraries your project depends upon.
I have the following Java projects structure:
Util
|
-- Core
|
-- Services
|
-- Tools
The projects: Tools and Services references to Core and Util projects, the thing is that I ended up writing the same dependency over each project, there must be a better way to inherit the dependencies of the referenced projects and add new ones if needed.
I know about multi projects in Gradle, but this is not like a multi project, since I can basically take the Core library, compile it (which will then contain Core + Util libs) and use it in another project.
I wonder what would be the best way to approach this?
Repeating the same dependencies in every project is usually reasonable because in a bigger project you'll never know when they become different, and you don't want to deal with compilation/runtime problems when someone changes common dependencies list.
I believe that it is more pragmatic to add dependency analyser plugin to your build. It will help you to remove unnecessary dependencies and explicitly add transitive dependencies. And if you add this plugin to your build chain, it will help you to keep your dependencies healthy in the future. Pick this plugin here gradle-dependency-analyze, or maybe there is a better fork or equivalent somewhere.
You are actually out of options in your case because there are only two kinds of dependencies: (1) external (some other jar artefact) or (2) internal (another module in a multimodule build).
2.1 When you use an external maven-like dependency it will come to you with own dependencies (they are named "transitive dependencies"). It means that if you do compile 'yourgroup:Core:1.0' then you will get Util as a transitive dependency. But as I mentioned above, it is better to list transitive dependencies explicitly if they are used during compilation or to prevent them from being accidentally removed and crash your application in runtime.
2.2. If your projects live in the same version control repository and usually change and build together, then the multimodule layout is your best choice. In this case, you will refer to Core dependency like compile project(':Util:Core') and it will grab Util as a transitive dependency as well. And you will be able to do what you asked for and define dependencies for Services and Tools once - inside subprojects {} closure in the Core/build.gradle.
Having multimodule built doesn't limit you from using Core library elsewhere. No matter if it is a multimodule build or not, you can always add maven-publish plugin to Core/build.gradle, execute publishToMavenLocal task and reference to Core.jar from another project the same way you do for external dependencies.
You can always put your common code (like the one which will add common dependencies) in the external gradle file or custom plugin and apply it in Services and Tools.
I am in the processing of integrating Maven into my my projects. While maven has plenty of pros i'm finding it difficult to figure out how to maintain my current development process, which is as follows:
For creating SDKs I will create a sample app, which will depend on and directly reference the SDK source code, all from within the same code project. This means that I can make easily change/debug the SDK code with one click run/debugging.
I fear this won't really be possible with Maven. Can I create some type of Hybrid approach, where I continue my normal development approach and then push builds to Maven when it is appropriate.
Update - For Clarity
My problem is that when everything is done through maven, the dependencies are built and published to Maven. Then, the dependent project pulls down compiled references and uses them. My issues is that I don't want to go through this whole process every time I make a small change to a dependency.Thanks.
You should try creating parent level pom.xml with two modules - your library and simple app to test it. In simple app's pom.xml provide a dependency on library module.
Then open in your IDE parent pom as maven project. This should be sufficient for normal debug.
Other possible approach - install you library artifact into maven repo with sources. In this case you will be able to debug it, but test app still have to load use jars from repo.
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).