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
Related
This is the structure of my project.
The parent contains no code.
module child1 is a spring boot application.
modules child2, child3 are jars libraries.
child1 depends on child2 and child3
parent
| build.gradle
| settings.gradle
| [no code]
child1
| build.gradle
| src/
| main/
| java/
| resources/
| application.properties
| test/
| java/
| resources/
| application.properties
child2
| build.gradle
| src/
| main/
| java/
| test/
| java/
child3
| build.gradle
| src/
| main/
| java/
| test/
| java/
I have a property called "datapath" that I would like to inject into classes in each of the modules.
There are two possible values for "datapath", one for tests and one for production.
I set the production value in
child1/src/main/resources/application.properties
and the test value in
child1/src/test/resources/application.properties
I have tried creating configuration classes and specifying PropertySource.
But the result has been that though child1 picks up the correct application properties in both test and main, spring does not find them in other modules.
Can you propose a strategy for me to implement this?
In particular:
The tests in the child1 are annotated SpringBootTest but preferably child2 and child3 should not depend on spring boot (just spring framework for autowiring)
I would like to be able to use the #Value annotation on configuration classes in the child modules.
How do I direct spring to resolve these properties from the application.properties in the child1 module, using the one in src/test/resources for tests and the one in src/main/resources for production?
As I have chosen a very "classical" structure, I would like to be able to achieve this with as few as possible moving parts. In particular I would prefer not to have to specify paths explicitly in annotations.
I assume that in child2 and child3 you need application.properties only for test. Then in test you can use #TestPropertySource where you can point relative path to properties file in child1 or add datapath explicitly:
#TestPropertySource(properties = { "datapath=value" })
public class Child2Test {
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 am working on a project that needs to be refactored in order to achieve decoupled modules.
I need to us an Adapter to decide which module to route to depending on some config.
+===========+
| Front-end |
+===========+
| |
+==================+ +==================+
| RESTful Service1 | | RESTful Service2 |
+==================+ +==================+
| |
+=========================+ +=========+
| Adapter | --- | Config |
+=========================+ +=========+
| | |
+=========+ +=========+ +=========+
| Module1 | | Module2 | | Module3 |
+=========+ +=========+ +=========+
I have a Java application, and want to package the modules in JARS using Maven.
RESTful Service1 will either talk to Module1 or Module2 while RESTful Service2 will always talk to Module3. I need to establish which is the nest way to package these modules.
RESTful Service1 will be in it's own Jar while Module1 and Module2 will have their own Jars too.
Question
Seeing that RESTful Service2 will always talk toModule3 only, should they be in the same Jar? Or should I separate them into two seperate Jars too?
Thanks
Because RS2 when deployed always needs to work with M3, putting them in the same jar offers one benefit: we won’t forget M3 when deploying RS2. But the downside is that it is difficult to reuse and deploy M3 to another system which does not require RS2.
I think the benefit above is little. Often, when deploying a system you should have a document or checklist. Even if some component was forgotten, chance is that you could detect and fix it quickly.
So the better option is to seperate RS2 and M3 into two jars.
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'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.