My question is really simple, thought I haven't found anything online related to it.
Is the maven-surefire-plugin able to have a dependency excluded but at class level and not at group-id:artifact-id level?
My problem:
I have a web project, related to a plain java project A. This A project contains hundred of classes that do a variety of things (connects to the database, sends web services, calculates stuff, manages the logs, context, sessions, etc...) and the dependency is quite strong. Since all unit testing on the web project will be hard to do without this A project I need to have it as a dependency even for the testing. But of course I cannot use some of the classes in there (mainly the DB connection and the session stuff). So I thought that instead of mocking them (because there are like a few dozens of them and I want to do different things with the functions (like writing to a file that it tried to connect or read the "session" from an xml file)) I can create a A-test project and include the classes I want from this new project and exclude the classes I don't need from the A project.
I know I can copy/paste all the project and then replace the classes I want, but if something changes in project A, I then have to maintain it in A-test (and I am very lazy and don't like to work twice). I thought that maybe I could have some kind of plugin in maven that will copy all the other classes (the one I am not... let say 'overriding'), every time. But it seems a waste of time if I just can tell the plugin which classes to use during the test step.
Thanks for your help!
Related
Experts,
I need some expert advice on how to approach the below use case in spring boot.
I need to have a maven multi-module approach to my project.
I need to have a single jar as output of the final build process.
There are to be common modules for controllers, data access and other functionality
Other modules are to be created based on functionality domain for eg a module for Payroll, a module for Admin etc etc.
Each domain functional module will then have their own controllers extending the common controller, exception handler and so on.
Each module will also have its own set of thyme leaf pages.
The reason for following such an approach is we have development in phases and we will be rolling out based on functional modules.
Here are the issues that I can sense using this approach.
Where do I add the spring web dependency? If I add to the parent pom - it gets replicated across the children and there will be port conflict issues as each module loads. the same issue will also be there the moment I add it to two child modules.
How do I build the fat jar which has all the jars from all modules and works as the final deployment?
All the text that I read i can't see anything even close to what I am trying to achieve.
AD1. They will not unless you are trying to setup independent application context in each module. Of course you can do that(it might be complicated but I believe it's achievable), but for me it's an overkill. Personally I think it's better to have one application context and rely on scanning components that are present in classpath.
AD2. The structure in maven might be a little bit complicated and overwhelming at first glance but it makes sense. Here's how I see it:
Create a parent module that will aggregate each module in project and will declare library/plugin dependencies for submodules.
Create 1-N shared submodules that will be used in other modules. With come common logic, utils, etc.
Create 1-N submodules that will be handling your business logic
Create an application submodule that creates application context and loads configuration and components from classpath
Create a submodule that will be responsible for packaging process, either to war, jar, uber-jar or whatever else you desire. Maven jar plugin should do that for you. For executable uber-jar, you have dedicated tool from spring.
Now you can choose three ways(these ways I know) of loading your modules.
1. Include some modules in maven build based on the build configuration via maven profiles and let spring IoC container load all the components he finds in the classpath
2. Include all of the modules in maven build and load them depending on spring active profiles - you can think about it as of feature flag. You annotate your components or configuration class with #Profile("XYZ") telling spring IoC container whether to instantiate component or not. You will need (most flexible solution) to provide a property file which tells spring which profiles are active and thus which modules should be loaded
3. Mix of these two above.
Solution 1 pros:
build is faster (modules that are not included will be skipped during build)
final build file is light (modules that are not included are... not included ;))
nobody can run module that is not present
Solution 1 contras:
project descriptor in maven may explode as you might have many different profiles
Solution 2 pros:
it's fairly easy and fun to maintain modules from code
less mess in project descriptor
Solution 2 contras:
somebody can run module that is not intended to be run as it's present in classpath, but just excluded during runtime via spring active profiles
final build file might be overweight - unused code is still present in code
build might take longer - unused code will be compiled
Summary:
It's not easy to build well structured project from scratch. It's much more easier to create a monolith and then split it into modules. It's because if you already created a project, you've probably already identified all the domains and relations between them.
Over past 8 years of using maven, I honestly and strongly recommend using gradle as it's far more flexible than maven. Maven is really great tool, but when it comes to weird customization it often fails as it's build capabilities rely on plugins. You can't write a piece of code on the fly to perform some custom build behaviour while buidling your project, you must have a dedicated plugin for doing that. If such plugin exists it's fine, if it's not you will probably end up writing your own and handling its shipment, so anyone in your company can easily perform project build.
I hope it helps. Have fun ;)
While creating a new web application using spring-boot, I wondered about a philosophical question: is the best practice to have only one maven module (and so one jar) for both server-side app and static web content of the client (to generate another jar, maybe?), or is it better to have one maven module for server and another one for client-side?
In other words, is it better to have this maven architecture:
MyProject-parent
- MyProject
or this one ?
MyProject-parent
- MyProject-server
- MyProject-html-client
- MyProject-mobile-client
- ...
As I would like to have a browser client and a mobile one, I would be tempted to say it's a good idea to have separate modules. However, using Spring-boot, it's possible to generate a fat jar, i.e. a jar containing all the other ones. As a consequence, the recommended architecture is, I suppose, only one maven module.
So is there a "better" solution? If yes, can you give me arguments?
I'd prefer the multi module approach for the following reasons:
The project is gonna grow and it gets better organized this way,
which means it would be easier to maintain in future and if you break
the modules properly in the beginning, you are not gonna have to lose
time to refactor and split it into different modules later.
It's better "layered”
It's better for bug fix or make new functionalities, since you can
focus on only one module and run the test only for that one.
As you are using Maven, it helps a lot with the dependencies, you can
build it all with one single maven command and it takes care of the
build order. So I can't see any advantage of using single module for
your case.
You might need to release MyProject-mobile-client without releasing
MyProject-html-client any time in future in case you are planning to
use maven release.
I have some years of experience with maven projects, even with multi modules ones (which has made me hate the multi modules feature of maven (so the disclaimer is now done)) and even if I really like maven there is something I cannot get a clear answer about :
What is a typical usecase of a multi module maven project ? What is the added value of such a structure compared to simple dependencies and parent pom ?
I have seen a lot of configuration of multi module projects but all of them could have clearly been addressed by creating a simple structure of dependency library living their own life as deliverables (even with a parent pom, as a separate deliverable : factorising depedencies and configuration) and I haven't found any usecase where I can clearly see an added value of the multi module structure.
I have always found that this kind of structure brings an overkilling complexity with no real benefit : where am I missing something ? (to be truly honest, I can get that some ear can benefit from this kind of structure but except from that particular usecase, any other real use and benefit ?)
Here's a real life case.
I have a multi-module project (and to your rant... I haven't seen any complications with it.) The end result is a webapp but I have different modules for api, impl, and webapp.
12 months after creating the project I find that I have to integrate with Amazon S3 using a stand-alone process run from a jar. I add a new module which depends on api/impl and write my code for the integration in the new module. I use the assembly plugin (or something like it) to create a runnable jar and now I have a war I can deploy in tomcat and a process I can deploy on another server. I have no web classes in my S3 integration process and I have no Amazon dependencies in my webapp but I can share all the stuff in api and impl.
3 months after that we decide to create a REST webapp. We want to do it as a separate app instead of just new URL mappings in the existing webapp. Simple. One more module, another webapp created as the result of the maven build with no special tinkering. Business logic is shared easily between webapp and rest-webapp and I can deploy them as needed.
The major benefit of multi modules are
one single maven command to build all your modules at once.
and the most important : maven take care of the build order for you.
configuring your CI-server is also very easy: one single jenkins job to build everything.
I already worked in a project with about 30 submodules. Sometimes, you need to change something in more than module, and running one single command and being sure that everything that need to be compiled is compiled in the correct order is a must.
EDIT
Why 30 submodules ?
Huge framework with lot's a features, lot's of developers, separation of features on a module base. It's a real life use case and the separation of the code into module was really meaningful.
I think you are correct in that most project that use multi modules, actually don't need them.
At where I work we use multimodule projects (and I think that for a good reason). We have something similar to a service oriented architecture, so each application
A client module
An interface module (which has shared objects between the client and implementation)
an implementation module
a war module
I agree that putting that implementation and war module in the same actual module would be ok, but the (arguably) benefit of this is that is very clear division between the classes that solve the problem and how the application communicates with the external world.
In previous projects that involved just a web application, I've tried to put everything in the same module, as it made testing easier, given the modules I was using.
Multi modules can help you with re-use your code.
It's one of the best benefits you'll feel in work.
Imagine if you have 3 web projects with a security layer, You'll have to copy paste your code 3 times and trying connect it with each project.
But what if you create a security module a project with a specific job.
It'll be easy to use it by injecting it to your app and then boom it works.
Also as mentioned in #ben75's answer the one maven build command and the correct order of building all your used jars. You'll think no more about which depends on another.
I find maven modules extremely useful for the following reasons:
Architecture layering and boundaries
For example, I make a maven module application-contract which contains the interfaces my presentation layer sees. So I have UI->Presenter-> application-contract <-application-impl <- infrastructure -> domain. This way, I know that my presentation/UI layer will not have access to classes from my Domain/application layers. If domain classes are not in classpath when I code in UI, I cant use them. And I like it this way (utilizing the class path restrictions). Perhaps Java 9 modules can solve this problem too, but (unfortunately) I have work with Java 8.
Running tests in one module each time
When I change code to a layer which is a module (as mentioned previously) I can run its tests only, without re-runing tests from code I did not change. This gives me speed. My presentation layer tests need ~3 seconds (for 300 tests). Every time I change code to a Presenter or whatever below application layer, I don't want my database H2 integration tests to run. Or My Image processing tests to run. Because these do IO and they are slow.
Building
Pretty much the same thing. When I change code to UI, i have only to build and deploy UI stuff (my UI is in Java).
We are writing a new set of services and have decided to make them share a common interface... calling it a BaseService. The idea is that whenever anyone wants to develop a new service in our organization, they should be just able to extend and use this BaseService.
We have written a few other classes which also form a part of this base jar, it does things like handle transactions and connect to database using hibernate etc.
Right now all the services that extend the BaseService are a part of the same project (Eclipse + Maven), and some of the services are dependent on each other, but because they are in the same project we don't have a problem with dependencies.However, we expect 40-50 services to be written which would extend base service and would also be interdependent.
I am worried that the size of the base project would be huge and that just because when someone has to use one service they might have to depend on my base jar which has 50 services.
Is there a way that we can make some projects dynamically dependent on others?
Lets say I have a service A which depends on service B, when I build/compile Service A,it should be able to realize that it has a dependency on service B and automatically use the Service B jar.
I have heard of OSGi, will it solve my problem or is there a way I can do it with Maven or is there a simpler solution ?
Sorry about the long post !
Thanks in advance for your suggestions
It doesn't make any sense to "dynamically" manage project dependencies, since build dependencies are by definition not dynamic.
Your question, at least for the moment, seems to be entirely about how to build your code rather than about how to run it. If you are interested in creating a runtime system in which new service implementations can be dynamically added then OSGi may be the solution to look at. An extra advantage here would be that you could enforce the separation of API from implementation, and prevent the implementing services from invalidly depending on parts of your core module that you do not want them to have visibility of.
You could also use OSGi to manage evolution of your core service API through versioning; for example how do you communicate the fact that a non-breaking change has been made to the API versus a breaking change etc.
I would say there are two options depending if i understand your question correct. First one. You have already defined an interface (java term) and now you have different implementations of that. The simple solution for Maven would be to a have a module which is called for example: service-api and than this will be released and can be used by others as dependencies. On their side they simply implement the interface. No problem with the dependencies. If you are more talking about OSGi than you should take a look to maven-tycho.
I'm new to XML Schema and to JAXB and wondering what the best or expected approach to using the Maven JAXB plugin (http://static.highsource.org/mjiip/maven-jaxb2-plugin/generate-mojo.html)is.
I have a simple XML document format for which I've defined a schema. I'm primarily interested in reading a compliant XML file into Java, but I'll probably also want to add extra properties to the POJOs which won't be in the XML, but will be used at runtime.
By default the plugin places generated code into ${project.build.directory}/generated-sources/xjc. What I think I want to do is copy the generated code into /src/main/java/whatever and add to/modify the code to add my extra properties. When I change the schema, I'd then merge changes form the newly generated POJOs into my own ones.
The alternative is to tell the plugin to place the generated source directly into /src/main/java and to perhaps subclass the POJOs to add my own properties, but I'm not sure whether the marshaling/unmarshaling can still be made to use my extended classes.
Anyone have any guidance on which approach is more normal or what the pitfalls of each are?
In your place I'd leave the generated sources where they are so that the corresponding jar can be built by Maven without further configuration and put your custom code in a different project that depends on the first one. This ensures that everything is build in the right order.
It is your choice whether to derive from the generated classes or just use instances of them in your code, as attributes or, even better, local variables. Personally I'd avoid derivation; after all JAXB is just low level machinery you use to perform I/O in a specific format.
Most importantly: forget about modifying the generated sources; why introduce an error prone manual step in your development process when you can get the same effect automatically?
(To provide a slight variation on to Nicola's answer)
If your schema rarely changes it might make sense to have a completely separate build which just creates the JAXB generated code, jars it, versions it, and sticks it in your repository.
Then in your downstream code you use that jar as a dependency and subclass the JAXB code as necessary to add your new fields.
We went this route because we felt that having JAXB complile every time we did a build was unnecessary as our schemas were pretty static.
Most importantly: forget about modifying the generated sources; why introduce an error prone manual step in your development process when you can get the same effect automatically?
Absolutely.
To elaborate and extend on a point already well-made... if there are a lot of implicit relationships and things you'd like to put "getters" on the JAXB code for, bite the bullet and wrap the JAXB class hierarchy in one that does exactly what you want where you want it.
With IDE-assisted delegation, this is only a little tedious, and factors a lot of straightforward, distracting, low-level code out of your main app.
Another benefit of this is that you'll spend a lot less time fighting JAXB to generate things exactly the way you want - the wrappers will make you care a whole lot less.