i got 2 Applications (EAR-s), each of them have own EJB-module.
Now i am trying to build applications with maven.
The trouble is that each of EJB-modules are using own EJB-client module and EJB-client module from another application.
In maven topology EJB-core and EJB-client module must be placed in one project, so i get round-dependency and can't build applications.
Any suggestions?
ear-1.ear depends on
module-1-core.jar
module-1-client.jar
module-2-client.jar
ear-2.ear depends on
module-2-core.jar
module-2-client.jar
module-2-client.jar
module-x-core.jar depends on
module-x-client.jar
You shall not have cycles like this.
Related
I'm currently learning gitlab ci/cd and ran into a problem.
I am a java developer and I have written a multi-module maven project with microservice architecture.
At the root of the project, I have a BOM file in which the heir modules are declared and dependencies are declared in the dependencyManagment tag so that all microservices use the same versions of spring-cloud. Each module has its own repository. Logically, each module has its own database and pom refers to the parent (bom) to import dependency versions.
The question is that when writing gitlab pipelines, I get an error: Non-resolvable parent POM for (module name) ... It is logical that he has nowhere to get dependency versions, etc., but in this case, how to control the versions of the libraries of all modules or can maybe it's not needed at all?
Help me come up with a work plan.
At the moment the diagram looks like this:
root(bom) -> childModule(pom)
alsoRoot -> childModule(pom)
First, try this link for your error.
Also, for your project unless it represents a whole microservice, it is fine. But, it seems like you have implemented many microservices in one project. Every microservice should be an isolated project with its own dependencies and release process.
Each microservice project should be:
Independent
Autonomous
Easy to deploy individually
I'm trying to understand the difference(s) between structuring a project with the Java Platform Module System (JPMS) versus structuring a project using multi-poms.
Is the main difference that the JPMS encapsulates the code while a multi-pom project separates project dependencies?
I've searched on google but I haven't found a good explanation on the differences, but rather I see the word module getting used interchangably.
The computing industry often recycles terms. Context is everything.
The two kinds of “module” you present are unrelated, orthogonal issues.
The Java Platform Module System (JPMS) is a way to identify to the Java compiler namespaces amongst all the classes and methods available at runtime.
Multi-module in Apache Maven is a way to conjoin into one project what could be handled as separate projects. Each module in the project has its own POM with its own dependency and build settings, yet all can be managed as one super-project when combined as a Maven multi-module. Each module results in producing an artifact, such as a JAR or WAR file.
Very simple apps in Java may use neither.
Ideally new Java apps would use the JPMS, but it is still technically optional. In a perfect world, JPMS would have been included in the original Java, but was in fact added only recently, in Java 9. JPMS is quite handy if your app will run as a standalone, with a JVM bundled, because you can include a JVM that has been stripped down to only the parts actually used by your particular app (see jlink, jpackage, and related tools enabled by JPMS).
Maven multi-module projects are generally only used for complicated projects such as an app that includes a piece of functionality which may be spun-off for use in other projects. Or a multi-module Maven project may be good for an app that combines both a frontend user-interface module along with a backend business-logic module where we want to manage each part separately yet combine them into a single deliverable, such as a Vaadin Flow web app.
I can see how you could become confused, as both have to do with arranging classes. To oversimplify, Maven modules are about compile-time (dependency management and build automation) while Java Platform Module System is about runtime.
I’ve read that Gradle is more adept at managing a multi-module project. You might consider switching from Maven to Gradle for your multi-module projects. Gradle obtains your dependencies from Maven repositories.
Well here is an interesting experience i had since last couple of weeks structuring my maven multi module project.
When i decided to use maven for my build life cycle management i had couple of reason that i wished to choose maven.
a. Mostly development teams are divided so that each team can work on separate Module within the project like Team-A to work on User Management System, Team-B to work on Authorization System, Team-C to work on Document Management System...and so on. Each team has java developers, testers, UI experts etc.
So the maven Project structure should be such that each team can independently work on their respective modules. They must be able to code, compile, build, test, deploy their module without having to compile, test modules belonging to other teams.
And thus i came to conclusion that each development module of the maven multi-module project must represent a Functional Module
After some discussions on forums i found people suggesting me to follow layered approach were child modules must be layers like controller-layer,service-layer,dao-layer etc. I did not pay heed to this advice because this not solving my purpose of teams working on individual module. This way for large project the build and deployment time for each team during development increases which does impact the project time-lines. sometimes the build and deploy time is upto 30 minutes say if there are 10 to 11 modules in the project.
But i did pay heed to a suggestion that keeping DAO layer separate for each module is not a good idea as DAO is highly granular and reused by other modules. and so the dependency of one module on other would would any how become greater.
I found a solution to this problem by creating a common module and moving DAOs and DOMAIN to the common module which will be inherited as a dependency by each module. And this seems to be a more viable option. Now the Project Structure looks like this.
Now when i build the project and run the webapp on server, It complains 404, Resource Not Found. I found that this is because the WEB-INF/classes folder is missing, src/main/java is missing in web-app module. I searched and found couple of links that suggested it is Deployment Assembly issue in Eclipse. So i need to manually create these folders and add in the deployment assembly because maven does not do it.
But the bigger questions are
do i need to move the Controller classes like com.mycompany.usermgmtsys.controller.UserMgmtController etc.. to src/main/java Or maven should find the controllers from the module jars included as dependency in WEB-INF/lib.
I dont want to do this i.e. putting java file in web-app. i want all the controllers should be available to the web-app as dependency for example WEB-INF/lib/usermgmtsystem.jar. But then wouldnt the Tomcat be looking for controllers in classes folder.
I dont know what should i do ? Any suggestions would be appreciated.
Its the way the eclipse render maven based project. It generally creates two structure. One based on master pom (parent project) and others based on individual module pom. however doing changes in any structure will reflect in the other one. As a practice I do changes in individual module folder structures and is more easy to read too.
Personally I try to avoid multi-module projects as, if you're using the Maven Release Plugin, you are locked into releasing all your modules together.
While this may sound like a convenience the problem arises when you need to do bug fix release to one of the modules - you end up releasing all the modules, not just the module with the bug fix, incrementing their version even though they haven't changed.
You also take a hit if you're running CI with multi-module projects - you're build typically runs over all modules from you root pom but if you're working in a particular module, you end up taking the hit of building those that haven't changed, in effect losing some of the benefits that the modularization was meant to provide.
So, go with independent modules but, and this is the important bit, create a common 'dependency' pom used by each.
A 'dependency' pom is a pom that standardizes all the dependencies across your projects and is different in that those dependencies are specified in the dependencyManagement section rather than the dependencies section (it also sets up standard plugin config, etc). This allows your project poms to specify the dependency pom as their parent and then declare the dependencies they need minus the versions, which are picked up from the 'dependency' pom and thus standardized across your projects.
If you are still concerned about being able to built everything, this can be achieved with a simple batch-file.
This is a good question. There are many aspects that must be considered for a useful project layout. I'd like to try to answer one which you didn't mention. Is your app extensible by users? If it is, then consider creating a separate module for your public API layer (service interfaces, DTOs used by those services, and Exceptions thrown by the services).
In our app, we have several maven modules per functional area. The idea is that a group worked on a feature within just one functional area and this isolation kept them messing with sources being modified by another group. Each functional area is broken down further in maven sub-modules we call "api", "domain", and "service" - we don't lump services/controllers, domain, and exceptions into a single module. The api module contains those classes we want to expose to customers for their customizations. Our service layer is the implementation of those interfaces. Further, we do not allow one module's service to call another module's service as this would bypass our service orchestration layer where customer can attach extensions to our services. Using separate maven modules per functional area helps enforce this.
We have other modules (internal-api, web, adapter) but they don't really add to this topic.
I figured out the issue. Controllers are presentation-layer components. The dispatcher expects the presentation layer components in the WEB-INF/classes folder in the target rather than looking for it in the lib. I am not sure if this is valid only for maven based structuring in eclipse. So finally these are the changes i have made
a. Created a src/main/java source folder in web-app. It is not generated by default in web-app module.
b. Add packages and respective controllers in the src/main/java folder.
So the final structure that i have (i am not pasting exact eclipse snapshot, this is generalized view)
I am wanting to mavenize our projects but have a somewhat complex scenario. Need opinions on the best way to handle a situation in which classes from a web app are required by other apps that are built and deployed along side it.
My projects look like this:
Suite web app.
POS web app.
Membership app.
Two packages within the Suite app are used in the POS and Membership app, as well as in the server lib.
I am not really sure how to approach this. Should we designate/automate a regular build of the Suite app for the purpose of pushing the Suite jars to the repo to be used as a dependency, or should this all be taken care of in the top level pom for each build? There's also the issue of building the server lib.
Thoughts appreciated!
If there are interdependencies between your projects you either let your CI server take care of the logic (e.g. build your dependencies before your dependents, or if a dependency changes, rebuild the dependents) or you let maven do it using the reactor and using a multi module project. In there, POS and membership would have a maven dependency towards Suite (if i understand correctly your setup)
If you go with the latter, you need to have an aggregator pom that aggregates the three projects as <modules>s. This will be the pom where you will launch maven, so the reactor can do its job of determining the order
I need to build java project. The project should include two modules: domain and web.
The domain module contains all the entities, the business logic and hibernate integration.
The web module should be depend on the domain module and contains web application using apache wicket.
I wonder about the maven usage.
Should I create a project and modules using maven? If so, how?
What kind of archetype are relevant for my project and modules?
What is better experience - create the project myself or use maven?
I am using intellij.
I'm assuming you don't need a server for others to access your code,
but rather, you want to use maven/ant for internal project
organization/dependency resolution/source organization.
Should I create a project and modules using maven?
Yes, either maven or ant will be useful for any non-trivial Java or Java EE project with external dependencies, and build/testing requirements.
If so, how?
Either ant/maven will allow you to easily setup a platform independent "build" file, so that you can easily resolve dependencies, build your jar executables, and run unit tests in order by issuing a single command, rather than multiple clicks to different plugins in whatver the ide-of-the-month is. You can do this in eclipse using the maven plugin to create a new maven project, or , as you suggest, by creating an artifact by running the regular mvn install.
What kind of archetype are relevant for my project and modules?
To learn use maven-archetype-quickstart.
For a regular (simple) j2ee app, try maven-archetype-webapp.
There is also a j2ee archetype as well.
What is better experience - create the project myself or use maven?
A simple, 3-step, robust method for setting up a maven project :
1) Use maven archetypes to create and setup your "hello world" project.
2) Import the maven project into your ide as a java project.
3) Edit/refine/fix code in your IDE, but use maven to build and test the whole application.
Update: external web frameworks
Creating a wicket (or gwt or any other framework) oriented web app will
Be best done following specific tutorials related to the framework itself. In order to add theframework libs, just paste the maven info in your pom.xml like thus, and run a "mvn install" command :
<dependency>
<groupId>org.apache.wicket</groupId>
<artifactId>wicket-core</artifactId>
<version>1.5.3</version>
</dependency>
I'd recommend you to use maven. The reasons why I use maven:
IDE agnostic. You can use idea, eclipse or some other ID.
Dependencies management
Powerful plugin system
You can manually create 3 maven module
app.parent with pom packaging and no parent.
app.domain with jar packaging and app.parent parent
app.web with war packaging and app.parent parent
and import app.parent to idea.
Also checkout Wicket quick-start Maven archetype creation page http://wicket.apache.org/start/quickstart.html