I started working with Maven and I am not sure how to handle the package-hierarchy.
Lets say I have a project-topic "MyPrj" that has 2 programms "ProgA" and "ProgB" (both with their own main) and both use classes together (e.g. "Both").
3 packages:
MyPrj.ProgA
MyPrj.ProgB
MyPrj.Both
ProgA and ProgB do have differnt dependencies!
So should I create 1 Maven project with subdirs ProgA, ProgB and Both and all dependencies in 1 POM
OR
should I create 3 Maven projects and somehow reference to Both
OR
something else?
Related
I have two services A and B which placed in monorepo in different maven modules, also they have Aggregate pom.xml which contains the next modules:
<modules>
<module>A</module>
<module>B</module>
</modules>
Both services are talking through gRPC and have common protocol which described in the proto files.
The grpc-java manual says, that I must put my proto files into src/main/resourses/proto folder.
It means I have to copy the same proto files bewteen two services:
A/src/main/resourses/proto/somefile.proto
B/src/main/resourses/proto/somefile.proto
Which is code duplication actually.
The main question - How can I share and compile proto files between two maven modules in monorepo?
I have done the next:
Created the separate library which contains only proto files. Let's call it C.
Added C dependency to A and B modules.
Aggregated pom.xml looks like:
<modules>
<module>C</module>
<module>A</module>
<module>B</module>
</modules>
The approach seems quite havy for that case and I don't want to have a separate maven module for that.
Moreover, I will definetley face with a problem, if I use different language for B service (something other than java and maven).
Is there a known solution for this problem? Can I share protofiles without separate library/module? Any examples appreciated.
I've been wrong with
The grpc-java manual says, that I must put my proto files into
src/main/resourses/proto folder.
We can set protoSourceRoot configuration for grpc-java plugin. We can specify any required proto source folder as follows:
<protoSourceRoot>${basedir}/../proto</protoSourceRoot>
It means no need in separate maven module and library.
I'm working on a multi module spring-boot project to build a REST API. Here is my project structure:
Parent project (packaging is pom)
core module (#SpringBootApplication + handle path like / or /status)
restControllerA module (Handle path like /routeA/*)
restControllerB module (Handle path like /routeB/*)
Everything is working in this project :)
In another non Spring project I would like to reuse a service of restControllerB. This service return the result of the request body validation.
First I try to add the restControllerB.jar as a dependency to this new project... But this jar does not contain its depedencies (who are in the fatJAR "core.jar"). When I run the project, I get a lot of ClassNotFoundException.
How can I manage to reuse this service as a dependency ? I thought to create a validator module which implements the validatorService interface, but I'm not sure if it is the best solution.
After few hours googling, It seems that creating an external librairy is the right choice. I create an external module and add it as a dependecy to restControllerB.
I'm currently writing a custom maven plugin for generating a XML file in a multi-module maven project.
My maven structure is pretty standard: one parent project and a module by project components in the parent project folder:
-- Parent
-- module A
-- module B
-- module C
I need to list, by module, a set of classes flagged by a custom annotation.
I already wrote a set of custom annotations and an annocation processor to create a XML file at compile time in the corresponding module output directory (${project.build.outputDirectory}) .
Now i need to merge each module XML into one file, but i don't know how to access each modules from within my maven plugin except having each path set as parameters (i don't like this method).
Any idea on how to do this ?
Does maven plugins can traverse project modules ?
Thank you in advance.
To get the list list of all projects you can use:
List<MavenProject> projectList = MavenSession.getProjectDependencyGraph().getSortedProjects()
If one of your goals is correctly executed you will get everything you need. Every MavenProject contains a getBaseDir() etc.
After some researches, it seems that MavenProject.getCollectedProjects() will return the list of projects beeing manipulated by a goal execution in a multi-module project.
I have a maven project that contains many components. I need to add a new one called "Component" witch has one module like described in the list below:
Component
com.module
src
main
java
resources
META-INF
module
test
java
Thanks
When you need to add a new component as a maven module with many packages, maybe this would be a suitable approach. The module itself is then part of a multi module project (see Maven by Example):
Component [Name of the maven module]
src
main
java
com.module.a
com.module.b
...
resources
META-INF
module
test
java
resources
I have a webserver project that works with soap webservices and saves data to db.
Now I'd like to write some importer classes that process build some kind of database cache on a regular basis. These importer classes should reuse lot's of the webserver project (especially the domain leyer, domain POJOs, database services, configs etc). The importers shall later run on a different machine than the webserver, thus independently.
How does a maven/eclipse project have to be structured so that I can separate these two projects, but reuse lots of the common code?
Would I place the classes just both into the same project? Or would I move the common code to a single jar, and create 1 webserver and 1 importer project using this jar as dependency?
Your last paragraph did give a rational solution.
If the importer and web application is something that is closely related, and the "reusability" for those "common class" is aimed to be within this project only, what you can do is having a multi-module project like this:
foo // your project name
+ foo-main // your reusable classes, you may split it into several modules if appropriate
+ foo-web // have foo-main as dependency
+ foo-importer // have foo-main as dependency
+ foo-parent // my personal preference is to make parent project a module, not mandatory
If your importer is something irrelevant to your foo project, but you still want to reuse, you can split it out
foo // your project name
+ foo-main // your reusable classes, you may split it into several modules if appropriate
+ foo-web // have foo-main as dependency
+ foo-parent // my personal preference is to make parent project a module, not mandatory
bar-importer // another project, having foo-main as dependency
or even make that common code a separate project
app-common // the common code in original foo-main,
// maybe a multi-module project
foo // your project name
+ foo-main // foo-specific codes, have app-common as dependency
+ foo-web // have foo-main as dependency
bar-importer // having app-common as dependency
For Eclipse, there should be nothing to worry about. Given you are using latest Eclipse + M2E plugin (should already been bundled with latest Eclipse), if you have correct POM, when you are importing the projects to Eclipse (by Import -> Existing Maven Project), relationships between projects should already been created.