We have Java and Flex projects. We currently have 1 base pom that contains the configurations we want to use for both projects. Problem with this is: Flex projects inherit configuration, for example, for javadoc and pmd plugins, which is not desirable.
I want to clean it up and have a real base pom, and then a java-base-pom and a flex-base-pom. But how does this work in a multi-module that has both a Flex part and a Java part?
We have plugins to our own application where we use the following structure:
my-plugin
my-plugin-client (flex)
my-plugin-server (java)
my-plugin just contains a pom.xml with <modules/> section. I would use my-plugin pom.xml as a parent for both, but then I cannot also use the java base-pom or the flex base-pom as parent. What would be the best approach for this?
Even though maven projects have single parent, they can import any number of other pom's like this:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.example</groupId>
<artifactId>my-shared-dependencies</artifactId>
<version>0.0.1-SNAPSHOT</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
This has two important differences compared to a parent:
Plugins defined in the imported pom won't be imported
Dependencies defined in the imported pom won't be added to the current pom, it will only import dependencies into the dependency management section
However, if your parent pom has a <dependencies> section and you want to include those into your dependencies, then you can add the parent to your <dependencies> section just like a regular dependency:
<dependency>
<groupId>org.example</groupId>
<artifactId>my-shared-dependencies</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
Even though the same dependency is already imported, the version tag has to be specified again. To reduce duplication, it can be stored in a property
A project can have only one parent (unlike multiple inheritance in C++) but this parent can be part of a bigger parent hierarchy. As pointed out by others, you could thus have something like this:
base-pom/
|-- flex-base-pom
| |-- my-plugin-client
| | `-- pom.xml
| `-- pom.xml
|-- java-base-pom
| |-- my-plugin-server
| | `-- pom.xml
| `-- pom.xml
`-- pom.xml
That said, I noticed you wrote that your actual problem is that:
flex projects inherit configuration for javadoc and pmd for example, which they do not want.
You should use the pluginManagement element to avoid this situation:
pluginManagement is an element that is seen along side plugins. Plugin Management contains plugin elements in much the same way, except that rather than configuring plugin information for this particular project build, it is intended to configure project builds that inherit from this one. However, this only configures plugins that are actually referenced within the plugins element in the children. The children have every right to override pluginManagement definitions.
So, in the parent pom, configure your plugins in pluginManagement (javadoc and pmd for example), and reference them within the plugins element in the desired children (only in my-plugin-server here). This would solve your current issue.
The only way is to have base-pom as parent of java-base-pom and flex-base-pom.
I have similar structure for my spring projects:
base-pom (basic configuration - eclipse, reports, repositories, etc)
|
+ spring-base-pom (spring definitions)
|
+ spring-jar-base-pom (jar specific definitions)
|
+ spring-war-base-pom (spring web and servlet dependencies)
|
+ spring-webapp-base_pom (spring web mvc dependencies)
I've cross this exact proble also, and the best solution I found was to use Inheritance and Aggregation as suggest in this question : does maven support multiple parents (multiple inheritance) ?
You can have an aggregator pom that is not the parent of the projects it
aggregates.
and explain in the Maven Documentation
Inheritance and aggregation create a nice dynamic to control builds through a single, high-level POM (...) Conversely, a POM project may aggregate projects that do not inherit from it.
From this I had my POMs inheritance (pom-master contains communes configurations, and each children the specifics ones) :
pom-master
|-- pom-java
|-- pom-flex
and so my project can get the specifics for each modules configurations as wished :
project (aggregate project-flex & project-java)
|-- project-java
| `-- pom.xml => parent = pom-java
|-- project-flex
| `-- pom.xml ==> parent = pom-flex
`-- pom.xml => parent = pom-master
Hope it will help others as well :)
Just image that pom.xml are in fact Java classes: you can have only one parent (or extends a class), but this parent can also have another parent, and so on.
As I explained here, you must distinguish the parent and aggregation principles in Maven, which means that my-plugin would be considered as an aggregation project, not necessarily a parent project for both my-plugin-client and my-plugin-parent.
So to summarize:
my-plugin will define the base pom for all your projects. Then, you create two new pom projects: java-base-pom and flex-base-pom. They have both my-plugin as parent. Now, my-plugin-client will have java-base-pom as parent, while my-plugin-server will use flex-base-pom for his parent.
This way, my-plugin-client will inherit all properties defined in the my-plugin pom.xml, and also from java-base-pom project.
You can achieve multiple inheritance with profiles:
You create (multiple) profiles in the root pom, and auto activate any variation of these profiles achieves multiple inheritance of maven configuration.
Related
Can I include only the required dependencies from parent pom(like we have exclude)?
I need this to achieve one scenario
Project A with hibernate and spring as my dependencies(there are
many other)
Project B with only hibernate and spring
Project C with A and B as dependencies
Problem statement : when I run maven install in project C, hibernate and spring are again downloaded separately. This I observed because of the increase in final jar size.
As a work around I included project A as dependency in project C so that I don't need to mention hibernate and spring explicitly.
To avoid this is there a way to include only spring and hibernate from project A?
It sounds like you are guessing what's in the project C jar just based on size. Unzip the final jar (rename to .zip) and look inside to see what jars are actually being packaged to figure that out.
Jars, wars, ears are just zip files with a manifest (more or less).
So, your all dependencies should be defined in parent pom and all your projects here in case A, B and C should be child projects of the parent pom.
In all child poms, you can define all dependencies needed without versions, so that they will be resolved from parent pom.
Interdependency of child projects should be defined only in case of needed. This, to get just dependencies from project A, C should not depends on A.
| - - A
| - - | - - pom.xml
| - - B
| - - | - - pom.xml
| - - C
| - - | - - pom.xml
| - - pom.xml (parent pom)
If you could get this structure as github project, then I can create a pull request with the changes.
To Get Spring Hibernate from you need to make Child Parent relationship A(Parent) and B, C as Child.
Jar file increment mustn't be the case. POM.xml does provide reference of dependencies downloaded in .m2 repo.
For further investigation we need POM.xml
How can I, with a boot application, let classes located in an external jar-file override classes in my boot application?
Use case: A boot application largeApp is released infrequently. As a user of largeApp I want to correct bugs by overriding specific classes without rebuilding largeApp.
.
|-- dist
| |-- largeApp.jar
| |-- lib
| | `-- bugfixes.jar
EDIT: Bean overriding is too narrow of a scope.
Before switching to boot, I solved this by building myApp to include largeApp
Using war projects, myApp.war and largeApp.war
<project>
<groupId>x.y.z</groupId>
<artifactId>myApp</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>war</packaging>
<dependencies>
<dependency>
<groupId>x.y.z</groupId>
<artifactId>largeApp</artifactId>
<version>${fw.commons.jetty.version}</version>
<type>war</type>
</dependency>
</dependencies>
</project>
Both project would contain src/main/java/SomeClass.java and the class from myApp was automatically loaded first (since war classloader first loads project class files, then jar-files)
EDIT 2:
Service classes are spring managed and could possibly be overriden as beans
Some classes are created by constructor new Foo()
Some classes are created by reflection Class.forName("a.b.Foo")
Also, configuration management is not an issue.
I have several maven-projects:
commons-lib (simple Java project)
user-service (Spring-Boot-driven project)
composite-service (Spring-Boot-driven project)
frontend-service (Spring-Boot- / Angular2-driven project)
all-services-parent (parent project building everything else)
While commons-lib is unlikely to ever be released separately, all other projects (except for the parent) might be released separately.
If the first four in the list are sub-modules of the fifth, do they have to have their parent set to parent (e.g. all-services-parent) in return?
Since I want to include commons-lib in the user- and composite-services I understand that I have to have it built first. However: each of the services above may be released separately - so which building structure is most proper for what I need?
Would it be:
-- all-services-parent
|-- (maven sub-module) commons-lib
|-- (maven sub-module) user-service
|-- (maven sub-module) composite-service
|-- (maven sub-module) frontend-service
or:
-- all-services-parent
|-- user-service-parent
|-- (maven sub-module) commons-lib
|-- (maven sub-module) user-service
|-- composite-service-parent
|-- (maven sub-module) commons-lib
|-- (maven sub-module) composite-service
|-- frontend-service
The second building structure would allow me to build all the JARs by calling "mvn clean install" on all-services-parent while still being able to build separate projects properly by calling "mvn clean install" on the corresponding parent, but is it really how it's done?
In my current setup I am trying to use the first building structure, but since e.g. composite-service has "spring-boot-starter-parent" set as its parent, I cannot access the properties or anything from the "all-services-parent"-module.
I read into Maven parent pom vs modules pom (a question that looked promising at first), but it did not apply to my case as much as I would like it to.
Try to import the spring boot parent and not inherit from it like this:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.5.9.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
Parent module properties file can access by sub modules but sub modules properties file cannot access to other sub modules. or
You need to do separate properties file for each sub modules.
Add your sub modules like this in your pom.xml file and give its absolute path.
This should be work
<modules>
<module>../TestWeb</module>
<module>../TestBusiness</module>
<module>../MsgScheduler</module>
<module>../Connector</module>
</modules>
I have the below project structure
Main Project
--Sub Project 1
- child 1
* pom-child1
- child 2
* pom-child2
* pom-sub-project1
--Sub Project 2
* pom-sub-project2
* main project pom
I had defined few project dependencies in main project pom and referred it in child and sub project poms. But I am finding issues if the pom is not a direct child of the main project pom. Is there a way to resolve it?
Example,
Main Project pom
<packaging>pom</packaging>
<version>dev</version>
<name>parent-project</name>
..
<properties><spring-version>3.1.0.RELEASE</spring-version></properties>
child POM
<parent>
<groupId>com.test.pkg</groupId>
<artifactId>test-proj</artifactId>
<version>${project.version}</version>
</parent>
The ${project.version} isn't resolved if it is not a direct child of a parent pom due to which none of the project dependencies are resolved.
Also, I read about properties-maven-plugin which is used to read properties from external properties file. Can this be used for reading dependency version or is there any other plugin/approach that could be used in this case?
You cannot use
${project.version}
to define your parents version, because the child by default inherits the parents version.
Set the parents version with the valid value and not with a property.
If you do so, it should work and you do not have to specify the childs version, as it will be inherited from the parent.
I want my ModuleTypeA war to include ModuleBase as a dependency with 'src/main/java/typeA' package Excluded and similarly ModuleTypeB war to include ModuleBase as a dependency with 'src/main/java/typeB' package Excluded.
Here is my project structure:
ModuleBase
|
|----> src/main/java/base
|----> src/main/java/typeA
|----> src/main/java/typeB
|----> pom.xml
ModuleTypeA
|
|----> src/main/java/..
|----> pom.xml
ModuleTypeB
|
|----> src/main/java/..
|----> pom.xml
I am new to Maven and not sure how to achieve that. ModuleBase cannot be a parent project as I need to build a jar for that (can't have packaging type pom) so I can create a top level parent project.
Any suggestions are welcome.
Thanks
Normally it should look something like this:
proj
+ proj-base
+ src/main/java/ // containing base code
+ pom.xml
+ proj-mod-type-a
+ src/main/java/ // containing module a code
+ pom.xml // dependency to proj-base
+ proj-mod-type-b
+ src/main/java/ // containing module b code
+ pom.xml // dependency to proj-base
+ proj-a-web
+ src/main/java // war A source
+ pom.xml // dependency to proj-base and proj-mod-type-b
+ proj-b-web
+ src/main/java // war B source
+ pom.xml // dependency to proj-base and proj-mod-type-a
In brief, split your project into meaningful modules, each being a unit for dependency. Construct your WAR base on the dependency you need.
If proj-base is in fact a WAR that you want to reuse its content in other WAR, then you may look closer to behavior of WAR overlay in Maven. However, I believe the basic idea is still the same: better modularize your project and have appropriate dependencies when constructing your WAR/EAR
First, read this article about dependency exclusions:
Optional Dependencies and Dependency Exclusions
If you are building a .war file from ModuleBase, you can make not a dependency but an overlay for ModuleTypeA from ModuleBase and similarly ModuleTypeB war as overlay of ModuleBase. For this, you can use Maven War Plugin:
Maven War Plugin
This way, for exclusion of a package use this in you pom.xml:
<excludes>
<exclude>src/main/java/typeA</exclude>
</excludes>
UPDATE:
I haven't try this yet, but there are two ways possible to exclude a package from .jar.
1) Use Maven Assembly Plugin. Here is an example you can refer to:
Exclude files with maven assembly does not work
2) Use Maven Jar Plugin, check this answer as an example:
maven-jar-plugin Exclusions Failing
You could create different assemblies in the ModuleBase and refer to those as system dependecies in ModuleTypeA/B.
You can set the path to a dependency with <systemPath>../module-base/target/rt.jar</systemPath>
Maybe Multiple assemblies from one maven project will help you with the assembly topic.