Is it not possible to include dependencies based on class properties? E.g. if I am building a framework that I want to integrate with any customer system, the type of DB the customer uses could be a variable but my framework may use it if it can acquire a data source. So in this case, my Maven project should be able to integrate with any DB by declaring the corresponding DB war as dependency.
E.g.
<dependency>
<artifactId>${database.artifactId}</artifactId>
....
</dependency>
But this database.artifactId in itself will be read from properties file that may be accesible to customer code, so the idea of having parent pom declare the versions and artifactId as mentioned here may not suit my case.
Is there a work around or is this use case itself so wrong? I strongly think if we build a framework that is more like a product the customer can integrate with, this flexibility of declaring any runtime dependency based on propertie should be there.
Thanks,
Paddy
This is not how it is done with Maven.
If, as in your case, you write a framework that may use different dependencies, then you do not somehow conditionally depend on the concrete implementation. This would not work, as the exact list of dependencies is constructed at build time (i.e. when the Maven artifact of you framework is built and installed).
Rather, there should be a special Maven artifact which describes just the interface of the functionality that you need. This artifact will typically contain the (Java) interfaces your framework needs; this is what your framework will depend on.
Then, when using your framework, a concrete implementation of these interfaces must be included - by the people using your framework, because only they know which implementation they use.
This is explained for example in "Maven by Example", chapter "7.10.1. Programming to Interface Projects".
Example:
JDBC: The interface is part of the JDK, so a framework that uses JDBC does not need to declare any special dependencies (if JDBC were not part of the JDK, you would depend on a Maven artifact like "jdbc-api" or similar). A software that actually uses JDBC will have to depend on whatever JDBC driver it actually uses (Oracle, HSQL etc.).
Related
I have multiple packages with same name like org.abc.com.client.* in different external libraries/dependencies which have same groupId name but unique artifactId name.
Therefore, it looks like:
<dependency>
<groupId>same_name</groupId>
<artifactId>unique</artifactId>
<version>same_or_different</version>
</dependency>
and unique artifactId has same package name. I don't need AOP for a class.
I want write #Around for a package specific to particular artifactId.
#Around("call(* package(org.abc.com.client)_of_specific_artifactId1(..))")
public void doSomething(){}
#Around("call(* package(org.abc.com.client)_of_specific_artifactId2(..))")
public void logSomething(){}
The artifact ID is a piece of build-time information and should be utterly irrelevant during runtime. BTW, artifact IDs can change, dependencies be re-packaged into uber JARs via Maven Shade or Maven Assembly plugins etc. What you want to do is simply bad design. You should refactor your libraries or find another way to differentiate them from each other.
FWIW, you can solve your problem also during build time by applying native AspectJ aspects to selected artifacts using binary weaving, creating new woven artifacts which can replace the original ones. The AspectJ Maven plugin does that for you, if configured correctly. For Gradle have a look at Freefair.
Update: About 7 years ago, I answered another question involving binary weaving of input JARs. It is a more complex multi-module scenario and if you read the whole answer, you are also going to find a link to a GitHub repository with a complete MCVE. Just replace the the Maven plugin org.codehaus.mojo:aspectj-maven-plugin:1.7 by dev.aspectj:aspectj-maven-plugin:1.13, because the MojoHaus version only supports up to Java 8 and misses some features compared the Aspectj.dev version.
we have a kotlin-microservice that needs to expose a maven-artifact that defines all DataTransferObjects that are required/emitted by that microservice (e.g. kotlin data-classes that represent events published to the event-bus).
client of that microservice is however a pure java application which shall depend on this kotlin-DTO-maven-artifact but not transitively get the kotlin-stdlib or any other kotlin-specific dependencies injected.
can we provide the kotlin-DTOs without introducing any kotlin-dependency?
The easiest and the most reasonable for me would be to create those DTOs as Java classes since the Kotlin is compatible with such classes
You don't need for this any additional tools or tricks. Inside this artifact you can easily use Lombok to not write plenty of boiler plate code
I want to reuse and centralize the utils I created for my Spring REST API for my future projects. That's why I thought I'd outsource them to my own project and make them available as a Maven dependency.
These Util files e.g. a basic service, basic controllers also contain Spring annotations, i.e. I need some Spring dependencies in my Util dependency. Now I'm a bit unsure whether I'm making a mistake or not.
First of all, I'm not sure if I should even use spring dependencies in a utility dependency or try to remove everything. Otherwise, I'll have to specify a spring version, but it might differ from the version I want to use later in the project it's included in. How am I supposed to solve this?
It is perfectly reasonable to have dependencies for your dependencies (these are called transitive dependencies). Of course, you should keep the number as low as possible, but on the other hand, you do not want to reinvent the wheel.
When somebody uses your dependency, they will automatically draw the transitive dependency on spring. Now, several cases can occur:
If this is the only reference to spring, the version is just used as you stated it.
If at some other point, a different version of spring is given, Maven dependency mediation kicks in. It decides by a "nearest is best" rule which version to take.
But: You can always set the spring version in <dependencyManagement> and then overwrite all transitively given version numbers.
That is the main concept of Maven. Your utility module must shipped together with Spring dependencies. It's called transitive dependencies.
Try to imagine that situation when all dependencies had excluded. In that case nobody will never know what kind and which version of Spring dependencies are needed.
Maven has a very good dependency conflict resolution. It's based on nearest-newest principle. So you can override those Spring versions easily and your application will use only one of that.
Take a look at these:
[1] Dependency Mechanism
[2] Dependency Mediation and Conflict Resolution
I read a lot of posts regarding the ways to use spring-boot-starter-parent in a spring boot project.
Essentially, I read posts (Spring documentation also talks about this) describing two ways to do this
To use spring-boot-starter-parent as the project parent directly. It gives us the benefits of having the dependency management as well as the plugin management.
The other way is to import the spring-boot-starter parent in the project pom (we may need this in case we already have a parent pom for the project).
It allows us to get the benefits of dependency management but not the plugin management)
I am creating a new Maven multi module project. Ideally I would like to have my own custom parent and also get all the benefits of using the Spring-boot-starter-parent.
I was wondering if it made sense to create a custom parent for my maven projects. This parent would in turn be a child of the spring-boot-starter-parent.
If I am not missing anything, this way I could get the benefits of having the dependency management and plugin management from spring-boot-starter-parent and at the
same time have a custom parent for all my projects where I could define some other common dependencies or if needed override the dependencies defined in the
spring-boot-starter-parent which would then be inherited by all my projects.
Does this design make sense or am I missing something.
What are the drawbacks of this approach?
There are no drawbacks -- this is exactly what you're meant to do if you want a multimodule spring-boot project. However, consider this: typically multi-module projects have all modules versioned together, released together, and dependant on each other. This rarely makes sense in a group of spring-boot modules, which are typically of the micro-service style and which require independent evolution. So, you should question your need for a multi-module project at all.
I have a Maven 3 project that uses Hibernate 3. In the Hibernate properties file, there is an entry for hibernate.connection.provider_class with the class corresponding to the C3P0 connection provider (org.hibernate.connection.C3P0ConnectionProvider). Obviously, this class is only used at runtime, so I don't need to add the corresponding dependency in my POM with the compile scope. Now, I want to give the possibility to use any connection pooling framework desired, so I also don't add a runtime dependency to the POM.
What is the best practice?
I thought about adding an entry to the classpath corresponding to the runtime dependency (in this case, hibernate-c3p0) when the application is run (for example, using the command line). But, I don't know if it's possible.
This is almost (maybe exactly) the same problem as with SLF4J. I don't know if Hibernate also uses the facade pattern for connection pooling.
Thanks
Since your code doesn't depend on the connection pooling (neither the main code nor the tests need it), there is no point to mention the dependency anywhere.
If anyone should mention it, then that would be Hibernate because Hibernate offers this feature in its config.
But you can add it to your POM with optional: true to indicate:
I support this feature
If you use it, then I recommend this framework and this version
That will make life slightly more simple for consumers of your project.
But overall, you should not mention features provided/needed by other projects unless they have some impact on your code (like when you offer a more simple way to configure connection pooling for Hibernate).
[EDIT] Your main concern is probably how to configure the project for QA. The technical term for this new movement is "DevOps" - instead of producing a dump WAR which the customer (QA) has to configure painstakingly, configuration is part of the development process just like everything else. What you pass on is a completely configured, ready-to-run setup.
To implement this, create another Maven module called "project-qa" which depends on your project and everything else you need to turn the dead code into a running application (so it will depend on DBCP plus it will contain all the necessary config files).
Maven supports overlayed WARs which will allow you to implement this painlessly.
You can mark your dependency as optional. In this case it will not be packaged into archives. In this case you have to ensure that your container provides required library.
You could use a different profile for each connection provider. In each profile you put the runtime dependency that correspond to the connection provider you want to use and change the hibernate.connection.provider_class property accordingly.
For more details about how to configure dependencies in profiles, see Different dependencies for different build profiles in maven.
To see how to change the value of the hibernate.connection.provider_class property see How can I change a .properties file in maven depending on my profile?