I'm currently working on changing building process of legacy project. Right now it is built by a custom-made solution and our aim is to adjust it to a standard one - maven.
This is a standalone application and current output of a build is a directory with following structure:
OUR_APPLICATION
|
|_bin
| |_start.sh
| |_stop.sh
|
|_etc
| |_app.properties
|
|_jar
| |_app_classes1.jar
| |_app_classes2.jar
|
|_lib
|_third_party_library.jar
I am wondering what's the best way to achieve similar output with maven and still follow best practises (or at least break them as little as possible).
I'm leaning towards creation of multi-module project (separate modules for Java code, configuration files and shell scripts) and then using maven-assembly-plugin for combining it all together, but I'm not entirely sure how (if at all) it can be properly done.
Still I'm not sure whether its the best fit for me and I will be very grateful for any feedback.
You are on the right way (imo): Maven is a good tool for producing deployable artifacts. And the maven-assembly-plugin fits the needs that you described. It could produce a ZIP file containing the application structure you described.
The default artifact type that Maven produces is simply a JAR. This is ok for libraries. The application structure that you described seems to have three of them: app_classe1.jar, app_classes2.jar, and third_party_library.jar (I know, there could be more of them).
The Maven setup that I would suggest (and keep in mind: other ways exist): Create a multi-module project, which has modules for each application JAR and one module for assembling them. The parent project then simply builds them all. Like this:
ParentProject
|
|-- pom.xml (the parent one, that describes all modules)
|
|-- Module1 (producing app_classes1.jar)
| |
| |-- pom.xml
| |-- src/...
|
|-- Module2 (producing app_classes2.jar)
| |
| |-- pom.xml
| |-- src/...
|
|-- AssemblyModule (the one that produces a ZIP, for example)
|
|-- pom.xml (with type POM because it does not produce a JAR)
The assembly module should not have the default artifact type (JAR), but should be set to type POM. The pom.xml of that assembly module then configures the maven-assembly-plugin to create a ZIP file. The content of this ZIP file is highly configurable. Additionally, this plugin attaches the result artifact (the ZIP) to the build, so that it will be uploaded to a repository, if that is also configured.
Related
I have a monorepo with the following structure:
app
|lib
| -moduleA
| |-pom.xml
| -moduleB
| |-pom.xml
|services
| |-foo
| |-pom.xml
| |bar
| |-pom.xml
| |gamma
| |-pom.xml
My end goal here is to deploy the application's war files to aws via GitHub actions. I am able to deploy individual services whenever there are changes in them, with the command mvn clean install -Dmaven.clean.failOnError=false -f services/foo/pom.xml.
However, I am not sure how to update the services whenever a module it depends on is modified. For eg., foo and gamma depend on moduleA. Whenever moduleA is modified, I would like to build war files only for foo and gamma and exclude bar since there are no changes for it. Pretty new to java, any ideas how to achieve this? TIA
Was able to find a flag that updates the dependencies of the module
--also-make-dependents
I have the following Maven project structure with Junit and Cucumber:
| root project
| Module 1
| src
| main
| test
| java
| tests // where all step definitions from Module 1 are stored
| resources
| features // feature files from Module 1
| Module 2
| src
| main
| test
| java
| tests // where all step definitions from Module 2 are stored
| resources
| features // feature files from Module 2
I want to reuse the steps from Module 1 in Module 2. Is it possible to import step definitions from Module 1 to Module 2 to reuse them there?
What you are already doing is kind of correct approach. You need to consider the following:
Since your Step Defs are in test the are not transitively take part in module2 class path
Make also sure there that the step defs in module1 are in a proper package relationships to your module2: your runner class in module2 is in the same package or above than your feature file which is in the same package or above than your step definition class
Make sure that module2 has module1 as a dependency
So to remediate point 1 in your example you need to move your step definition in module1 from test to main
I want to exclude a specific file from the base jar while running my project (which will use the base jar as dependency)
Base project structure looks like:-
baselib
|
|----src
| |
| |--some packages
| |
| |--resources
| | -- somefile.xml
|
|---target
Another project called "mycustomproject" will have "baselib" as dependency jar in pom.xml
My question i,s how to debug/run (Debug As/Run As-> Spring Boot App) the "mycustomproject" by excluding "somefile.xml" alone. I cannot remove this file in "baselib" since some one is using it.
Could someone share some inputs here?
I'm working on a spring application that contains submodules, roughly looking like the following:
project
|-- module1
||-- src
|| -- main
|| |-- java
|| -- resources
|| |-- null
|| -- pom.xml
Module 2:
|-- module2
| |-- src
| | -- main
| | |-- java
| | -- resources
| | -- spring-dao.xml
| -- pom.xml
-- pom.xml
now,I'm using Juit4 to test module1,while I have to offer spring-dao.xml in module1,like this:
#ContextConfiguration({"classpath*:spring/spring-dao.xml"})
But the spring configuration file(spring-dao.xml) is in module2, and module2 is dependent on module1. That causes I can't put module2.jar into module1 via the pom.xml of module1 as it causes a module cycle.
How can I test module1?
I'm not sure I understand completely, but here's how I read it:
Module 1 has a dependency on Module 2, and Module 2 has a dependency on Module 1.
The short answer is you cannot do this. The idea behind modules is to segregate unrelated code. I often do this with generated code, keeping that in a separate module. The generated code shouldn't have any dependencies on my main application, but my main application depends on the generated code.
I can think of a couple solutions:
If the two modules are that heavily dependent on each other, they should be refactored into a single module. This seems like the best approach, based on what you've described.
If this still isn't desireable, make a third module to hold common dependencies between the two projects.
I am using maven-gae-plugin from http://code.google.com/p/maven-gae-plugin/ to create a multi-module project using inheritance (parent-project reference)
The structure that I have is as below:
|
`-- pom.xml
|-- base-api-project (packaging=jar)
| `-- pom.xml
|-- main-www-project (packaging=war)
| `-- pom.xml
The root pom.xml is configured as parent + aggregator (with reference to the modules).
When I build using the root pom.xml, everything is compiled and packaged great.
However, when I run mvn gae:run in the main-www-project folder, I get an error that the base-api-project is not found in the registered repositories. I scans all registered repositories...
But my question is... if it's already there in ~/.m2/repository, then why should I hunt across the net?
I there something wrong that I'm doing?
When using snapshot versions maven will always look for the latest snapshot, whereas releases will be resolved locally first.
However, each artifact in the local repo will also need the corresponding POM, and that POM may declare dependencies that are not in the local repo, or are snapshot versions (etc. recursively).