We have git repository with a set of sample applications. Each sample app has its own subdirectory and its own pom.xml, but no common parent pom. The root level has an aggregator pom that should list all the sample apps.
+- sample-apps
| +- sample-app-A
| +- sample-app-B
| +- etc...
Because each sample app has a dependency to our core product, and we want the sample apps to use our latest version, we run the maven-versions-plugin from the root level to keep all apps up-to-date. However, developers that add new sample apps (subfolders) forget to add them to the aggregator pom. Hence, those sample apps will become stale over time.
Is there a way for maven to enforce that all subdirectories are listed as modules in the aggregator pom? We could write a custom enforcer rule for the maven-enforcer-plugin, but want to check for better alternatives first.
We do not want the sample apps to have a parent pom from our side, as the customer should be able to modify the sample app and inherit from his own parent.
Related
I am still fairly new to Maven and am unsure of the correct roles of the various components.
I have been using the following Maven-project structure for developing microservices:
service-parent
+-- rest-service-module
+-- frontend-js-module
+-- ...
The service definition is done using Swagger and the yaml file is stored in the parent project.
I would now like to setup a site which should include documentation and reports. It seems logical to me to store the site in the parent and gather javadocs, surefire reports etc from the child modules. For example, I added swagger2markup-maven-plugin to the parent pom to generate documentation from the swagger yaml.
The first problem I have had is that the parent pom executes the swagger2markup-maven-plugin and generates HTML. However, it executes the same goal on the child modules and fails.
It seems that I am not understanding the roles of parent and child poms which leads to this problem. The Swagger documentation only needs to be generated once - not from each child module - so the parent seems the obvious choice.
So why is the plugin in the parent being executed for each child and how can I prevent that? I'm still in the early phase of the project so I can reorganise the module structure, if appropriate.
I have tried the solution suggested in https://stackoverflow.com/a/14653088/11249 but couldn't get it to work for me.
You can use -N switch to not to recurse into the subprojects when generating documentation. Execute the following command (or any other you like) on your service-parent pom.xml. (It will only be executed for this pom)
mvn -N swagger2markup:convertSwagger2markup
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.
Here is the context : one application, let's name it "clientdata" is bundle into an ear to be deploy on WebSphere. We need to generate several jar for this application :
api-contract (interfaces)
ejb
ejb-client
impl
The ear contains ejb, impl and api-contract jar + the application dependencies
Let's call "checkclient" another application which need to call "clientdata" by RMI.
It will need to use api-contract and ejb-client jar.
For now the application is divided into 3 sub-modules (API, IMPL and EJB).
API module generate api-contract jar
IMPL module generate impl jar and use api-contract jar
EJB module generate ejb and ejb-client and use impl and api-contract jar
So here is my question : one member of the team thinks that we should use maven classifier plugin to generate all those jar so that we need but to maintain only one pom (one maven project).
I'm not so familiar with maven classifier plugin so i wanted to know, is this a good idea ?
Some of my readings make me think it is not, mostly because it violate a "core convention" and "Tools that have been designed to work with Maven won’t help you"
Here is the source of the citations : http://blog.sonatype.com/2010/01/how-to-create-two-jars-from-one-project-and-why-you-shouldnt/#.U7UhNCgucvQ
I would greatly appreciate your expertise on the subject.
Regards, GBE.
First the member of your team is simply wrong, cause that's the wrong way to deal with such default scenario in Maven. I assume (hope) you have created an appropriate folder structure
+-- root (pom.xml)
+-- mod-api (pom.xml)
+-- mod-ejb (pom.xml)
+-- mod-impl (pom.xml)
+-- mod-ear (pom.xml)
Based on the above folder structure you can simply define dependencies between the modules and let maven do the rest. Apart from that you can create the ejb-client automatically by maven-ejb-plugin and use this for furthere enhancements.
Now you can create an ear from it (mod-ear just add the dependencies to it) and just deploy it to WebSphere. That the way it should go. Creating a single pom to create that number of artifacts is by definition against the desing of Maven cause the convention in Maven is to have a single pom for an artifact. So you will start to fight against Maven and you will loose that combat.
Better got with the idea of Maven and make your life easier. Apart from that it's a separation of concern which means an single pom for a single part of the project which makes it clear where you can find anything in your project. Here is a simple example of a Java EE application.
I am really new to Spring Roo (perhaps been using it for 2.5 months) and on the whole it has been a very good experience, and I have rapidly created a system for managing a property portfolio.
HOWEVER, this system was developed in three seperate roo projects:
Property Management - mongo backend
Accounts Management - mongo backend
Address Book - JPA
Now I am looking to combine them in one project, with one home page to access all three parts, I am aware of maven multi-module support which Is included in roo, but when I attempted to combine the three projects by creating a Spring Roo Multi Module Project, defining the three modules and then importing each of the three modules into their respective folders, on deployment only the first module to be reached in the compilation was setup and the path for localhost access was not the name of the multi-module project but the name of the project which was compiled..
Does anyone know any resources or have any tips for creating a multi module webapp from the combination of three existing webapps?
Thanks
Just start with a folder structure like this:
root (pom.xml) Aggregator
+-- mod-mongo-property
+-- mod-mongo-accounts
+-- mod-jpa
Move all comming things like dependencies and plugins (in particular versions) into appropriate parent (depenendencyManager, pluginManagement).
My question has been asked before, which I know, but I think that I am trying to do something slightly different, where existing answers are not appropriate.
Essentially, I do want to have multiple projects in Eclipse that will be built (preferably) into one final WAR file. Ideally like this:
root - pom.xml
|___ java-app
|___ web-service-v1
|___ web-service-v2
|___ web-service-v3
|___ rest-service
|___ batch-service
Imagine the Java App as the actual application, and each additional component runs as a decoupled view layer for the Java App itself. Ultimately, the Java application will be running in a tomcat instance, with the different modules providing their services. I would like all the different modules also to run in the same Spring container.
I don't know that running in Maven modules is the best way of doing this, but I would really prefer to have each component in a separate Eclipse project that ultimately get built together.
Can anyone provide any suggestions as to how I would use Maven to build this?
Just make a separate war module:
root - pom.xml (packaging: pom!!!)
|___ java-app
|___ web-service-v1
..
+--- mod-war (pom.xml)
and put the dependencies of the modules you would like to have added to the war file into the pom and that's it.
The main Maven idea is that each module must produce a single build artifact (e.g. a jar or a war file). The parent pom is usually responsible for global configuration and dependency management and also for a proper module orchestration. If your final result need to be a WAR file, then last module in the list will be the web application. The other modules could supply classes that war file depend on.
There are more complicated build structures, but above one should be sufficient for you.
This is somewhat dated, but hope this additional info helps someone.
#Mouscellaneous An example of keeping Spring configs in each module and referencing them from the web.xml can be found here in the Sonatype book. I guess this is what you are looking for.