How to force modules recompilation in multimodule SpringBoot maven project? - spring-boot

There is a Maven project with two modules with this structure.
project
moduleA
pom.xml // library
moduleB
pom.xml // SpringBoot application
pom.xml // parent aggregator
Module B depends on A.
When executing command mvn spring-boot:run -pl moduleB (from project folder) Maven takes compiled package moduleA.jar from local repository and fails if it is absent there.
Please, help me to find a way of forcing usage of the latest compiled moduleA version every time the moduleB application starts.
In perfect case I would like to avoid mvn install step, just inducing mvn compile (if code changed) or reusing a compiled moduleA; but it also works if somehow application could be started with the latest compiled version of all code in the multimodular project.

Related

run a unit test in intellij idea without compiling dependency module

I have a project of intellij idea of two module:
project
moduleA
moduleB
and the moduleB is depending on the moduleA.
So right now I have developed some features on moduleA which is used in moduleB. And I have made a release version of moduleA to the nexus maven repo.
Now I am testing on module B.
I do a mvn dependency:resolve -U to update the dependency of module B and reload the project.
I want to only run one unit test in moduleB, which in my opinion, doesn't need to recompile the moduleA since it is already downloaded from the nexus to my local maven repo. But in intellij, it's still compiling the moduleA which takes much time.
How can I avoid compiling a module in project which is already present in maven repo pls?
thank you

Gradle Local Dependency Testing

I have 3 gradle projects, projectA, projectB, projectC. All of which build a jar file named projectX-0.0.0.jar. On my jenkins server, all of these projects deploy these jars to my companies artifactory.
In projectA, I have multiple compile dependencies used throughout my entire project. Then in project B, I include project A by stating: compile group: 'com.company.projectName', name: 'projectA, version '0.0.0' So I can use these dependencies (i.e. slf4j) I do the same for projectC to include projectB dependencies, which in result includes projectA's dependencies.
This works great for our jenkins servers on deployment, after I have pushed the code to the server, however when trying to test locally I can not get the dependencies to update for testing my code.
I have tried:
Updating the gradle cache that downloads project A from artifactory with locally built project A jar. Located in C:/users/username/.gradle/caches/path-to-jar.
Removed the compile group: 'com.company.projectName', name: 'projectA, version '0.0.0' and replaced it with compile files('libs/projectA-0.0.0.jar'), placing projectA's jar within a lib folder in projectB
Using gradle offline mode in IntelliJ and repeating #1
Going offline completely on my pc and repeating #1
With all 4 attempts above I still have not been able to resolve dependencies declared in project A for project B.
My goal is to be able to update a compile,testCompile,runtime,etc. dependency in my projectA.gradle file, and then run my projects down my pipeline to ensure this update effects the dependencies in my project as I intended.
You need to update the .jar and .pom file within your gradle cache. The .jar file contains the source code while the pom contains the dependencies you brought in the previous project. Using a gradlew clean build install you can create the jar and the pom.
So to solve your problem, do a gradle build clean install on project-a. Grab the jar and pom from the build file generated and replace the project-a.jar and project-a.pom within the cache. Then do the same for project-b and you will see the changes in project-c after a gradle refresh.

IntelliJ - How to link modules for maven goal

I have successfully imported a parent pom with child modules into IntelliJ. The child modules have dependencies between themselves and IntelliJ has correctly set up the classpaths so that changes to module A are reflected in module B. However these dependencies are not maintained when I execute a maven goal in IntelliJ (compile, jetty:run etc). Here is my structure:
client_libs
-- servlet-filter
-- filter-example
filter-example depends on servlet-filter. However when I run maven compile on filter-example I get:
The POM for com.cloudseal.client:servlet-filter:jar:1.0-SNAPSHOT is missing, no dependency information available
I can work around this by manually installing servlet-filter into my local repo before I execute a maven goal but obviously this is not ideal. How can I get IntelliJ to maintain the relationships between the modules when I execute a maven goal?
You shall be able to just run mvn package but from place/path where your parent pom is.
If this's not working for you, please post your pom.xml files.

Maven-ear plugin: could not resolve dependencies to ejbModule

I am probably missing something but how is the maven ear plugin (I'm using version 2.5) resolving ejbModule dependencies? I have the following structure:
my-parent (multimodule)
-- pom.xml
-- myEar
-----pom.xml
---myEjb
-----pom.xml
In the ear I have the dependency to myEjb.
2 things that are unexpected when i execute mvn package under myEar
It does not build (package) myEjb.
It does try to resolve the depedency to myEjb via repository, which is in our case our custom sonar repository that we configured in settings.xml. I would like not to have to install myEjb to our custom sonar respository in a separate step.
What I expected from the plugin would be: check the ejbModules dependencies, build and package them if not done or something changed, copy the jar to the target directory of the ear project and package the whole thing correctly.
Obviously I am missing something though, anybody can enlighten me?
Based on your structure you have to build from the root of your project which means you have to change to my-parent directory
my-parent (multimodule)
-- pom.xml
-- myEar
-----pom.xml
---myEjb
-----pom.xml
and do
mvn clean package
The behaviour you described that maven tries to solve the dependencies against your local repository is the usual process. You can do partialy building a single module within a multi-module build but in your case this won't work cause you depend on your myEjb which neeeds to be rebuilded. Otherwise you can do a
mvn install
first and after that you can do from the root:
mvn -pl myEjb clean test
which will only build the myEjb module and uses the dependencies from the repository (localy in this case).

Maven dependency resolution in a project with modules

my maven project is stuctured as:
project
moduleA
moduleB
moduleC
The moduleB and moduleC are dependend on moduleA. if I execute the 'mvn install' command maven installs moduleA and moduleB in my local repository after that maven tries to install the modeleC but without success, first it tries to find the artifact moduleA in all known maven remote repositories and after that, I'm getting a message that the moduleA artefact is missing. Its so weard because sometimes it works fine and sometimes not. Because of this issue I wasted a lot of time.
The artifact moduleA and moduleB are in my local repository.
I'm using maven 2.2.1 on a 64Bit machine under windows 7 pro.
Does anyone know what the problem is?
Thanks,
Kevin
If you use mvn install, that command will put the artifact in your local repository. Usually in your home directory under .m2/repository unless you have specified differently. If moduleC is trying build (with mvn install) and depends on moduleA, moduleA should be pulling from your local repository when moduleC. If moduleC is looking remotely for moduleA then moduleA never got installed into your local repository.
Check the pom file for moduleC. Make sure the dependency information in moduleC's pom.xml for moduleA matches the groupId, artifactId, and version specified in moduleA's pom.xml. If that matches, make sure moduleA is really producing an artifact. It should be in the target directory under moduleA. If moduleA is not a jar make sure you have the type attribute listed in the pom.xml for moduleA and that moduleC's pom.xml has that type listed for the dependency.
If the above doesn't lead to a consistent resolution, you're may want to edit your question adding some of the pom.xml details.

Resources