I have three maven projects one parent two children, the parent project has only the Super pom, while one child has the launcher class, and other is a web service that requires that launcher class to get started.
I need all these connected in my local system. What should be the structure that I should follow?
If one project needs classes from a different jar, just declare a Maven <dependency>.
Related
I have a project with a parent aggregator module and 3 children modules.
I don't know if this is a bug for me or just how Maven works, but I am currently unable to deploy one of my children modules without also deploying the respective parent. When I try to import the child module on another project of mine, Maven throws an error saying it can't resolve the parent. If I deploy both to my Nexus, it works perfectly. Do I always have to deploy both?
Yes.
You always need the parent POM as well.
When Maven need to "use" a module, it needs to resolve it.
If this module has ancestors it needs to access to every ones to resolve it.
OR you will face somethings like :
Could not resolve dependencies for project org.projectB:childA-Consumer:jar:0.1.0:
Failed to collect dependencies at org.projectA:childA:jar:0.1.0:
Failed to read artifact descriptor for org.projectA:childA:jar:0.1.0:
Could not find artifact org.projectA:parent:pom:0.1.0
Solution 1 : Deploy the parent
The common way is to deploy the parent, so this way when you consume your module maven will be able to find ancestors and so resolve your module's pom.
But lot of users seems to consider this as not so satisfying. (There are many question about that on stackoverflow ...)
Solution 2 : Parent != Aggregator
Most of the time in multi-module project, the aggregator pom is also the parent pom but this is 2 different concepts.
parent : is about sharing configuration with inheritance.
aggregator : is about building several modules at same time.
(more details about aggregator vs parent differences)
So, you can have an aggregator with several children and each child has no parent.
This way you don't have to deploy your aggregator.
Drawback you can not use inheritance to share config between modules.
Note that this is not a drawback for everyones, some consider that using inheritance and so parent is not good idea. 😅
Solution 3 : Use Maven Flatten Plugin
Currently poms contains 2 kind of information :
how to build the artifact,
how to consume it (e.g. dependencies).
Maven 5 will maybe clarify this and so you could have a different pom in your released artifacts and in your source code.
Using Maven 3, there is a plugin which aims to do that : flatten-maven-plugin
It aims to generate a pom.xml consumers oriented.
Among others, parent relationship is resolved, flattened and removed.
This way, you can use parents to share configuration between modules (with inheritance) and not deploy your aggregator and/or parents .
Drawback, you could maybe face issues with some other maven plug-in interaction ? 🤷
Some tips you need to know if you wan to use flatten-maven-plugin :
flatten cleangoal is no more useful.
how to fix url, scm url, scm connection and scm developerConnection resolution.
New to maven here...coming from the ant world
I need to create a client jar with a few files that will give my client the ability to write to my Db and make rest calls to my services.
These are mainly classes that wrap a Rest connection and db client.
Is it possible to produce this artifact as a side effect of my main maven project ?
Eg: main project produces a bundle when I run mvn package, but I'd like to produce the client jar by providing some other parameters....
What you need here is a multi-module maven project.
The structure goes like this:
-- Parent Module
----- Child 1 Module
----- Child 2 module
Here you can have all your code/files of your main app in child 1 module and put all the code/files for the client in the child 2 module.
The parent module is just an aggregator which produces an artifact of type pom. Whereas each of your child modules will produce individual jars.
You can then you the second jar in your client.
For a detailed understanding how multi-module project works, check this link.
The standard Maven way is "one project, one jar". This means that the cleanest way to achieve your goal is to set up a multi-module project where you have one module for your "normal" jar and one for your "client" jar. But there are other possibilities:
If you are talking about an ejb, you can use the maven-ejb-plugin and create a client artifact. Unfortunately, both artifacts then share the same pom (and, therefore, the same dependencies).
You can use the maven-assembly-plugin to assemble a set of files and deploy them as side artifact (same problem as in (1)).
You can use the maven-install-plugin and maven-deploy-plugin to install/deploy entirely different artifacts along with your main artifact. These artifacts need to be created before, e.g. by a custom maven plugin.
I have a project which was designed using a custom archetype to build modules under parent project as follows -
Details - The archetype implements a <configuration> in the <build> phase with a <mainClass> let's say Generator that builds the classes under the pojos and service packages into a single target folder and hence enabling to create the final JAR for the user module as user-1.0.0.jar
There's some requirement in terms of separately exposing the pojos without the intervention of service code that has left me brainstorming -
Is there a way to modify the existing archetype or module structure to get two separate JARs for the packages pojos and service as user-pojos-1.0.0.jar and user-service-1.0.0.jar?
One way I possibly know is to move the code in two different module and building their jars but then for multiple existing modules under the parent and a thought over the same name modules under the parent, wouldn't be preferable.
Is there a way to modify the currently obtained user-1.0.0.jar created and separate out it into the two JARs required same as above?
I Implemented two maven project each using spring MVC, Hibernate, Jax-RS service. they have separate configuration, database, controllers, models, services.
I need to combine both the project in such a way that one is work as parent and other should be its child and can access parent services.
If you want to share configuration among projects, you can use a parent pom.
If you want to combine two projects as subprojects of one larger one, you can use modules. Both concepts are described in
https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Project_Inheritance_vs_Project_Aggregation
If you want to access classes from project in another project, add a dependency in the dependencies section of your pom.
I have created a multi module maven project as below
- root module(parent module. Building this will build the below children modules)
dao
service
web
dao and service modules creates the jar file. web module creates the final war file to be deployed. service module has the dependency of dao module. web module has the dependency of service module.
Whenever I implement new functionality, I have to modify all the modules from dao to web. I have a maven jetty plugin configured in web module. To test any new implemented functionality in UI I end up building dao and service modules always. Are there anyway to avoid this process and reflect the changes from dao and service modules whenever I run mvn jetty:run in web module?
No, there is no way to da that, and this is the intended behavior.
If you have these 3 projects, this means the have their own lifecycle. If not, the best is to have only one project.
However, you could avoid mentioning a version number in the project, and rely on a parent version number (your root module could also be the parent).
So, you could rebuild everything from the multi-module project.
However, I don't really see the point.
Why do you have 3 projects ?