i want to create an functionality in which i have to change the dependancy in POM file and properties file dynamically.
You need to elaborate more on the requirements and put more info on what you're trying to achieve.
You can use Maven profiles to change dependencies dynamically. Reference Link also Similar Solution
For properties file, follow these Reference Link also Similar Solution
Related
When configuring the Surefire Maven plugin for Quarkus, I have come accross the following in the doc
<maven.settings>${session.request.userSettingsFile.path}</maven.settings>
For my project I would also need to do the same thing for the settings-security.xml file because we use password encryption.
In Quarkus this can be done using
<settings.security>
I can define this with a project property in the pom.xml with the hard-coded path of the settings-security.xml file in my CI/CD environment (it is not the default one). But ideally I would like to extract it from the Maven execution environment using something similar to ${session.request.userSettingsFile.path}
I have 2 questions (I still have a very limited experience of Maven for the moment, so please bear with me)
I have found plenty of examples with the ${session.request.userSettingsFile.path} property, but no documentation. Anyone know where these properties are documented? It is not at all clear to me where they come from.
Is there an equivalent to ${session.request.userSettingsFile.path} for the settings-security.xml file, or do I have to define the path in the project properties?
Thanks
I have a more than one spring boot modules. There is a dependency for each other modules. For each project has a module. Here I dont want to use #CamponentScan("com.myapp.register,com.module.admin") or #SpringBootApplication(scanBasePackages={"com.myapp.register","com.module.admin"})
in my project. Because if in future if we want add one more base package i dont want go for above approach.
If any other way to add the base packages in our package.
I thought spring.factories is better for this. I mean this is also same like properties files. spring.factories is configure the auto configuration. But i dont know how to add the base packages into that file.
I saw some examples in few tutorials, they provide only configuration classes only.
I done this way but still we need to use #ComponentScan in my code. I dont want this approch.
I want to add the all the base packages into the spring.factories
is it possible? If it is possible plese provide solution and sample way for that.
I don't think that is the purpose of spring.factories file. If you want to develop your modules with Auto Configuring capabilities then you can go for that. For that you can use following tutorials Spring Boot Auto Configuration 1 and Spring Boot Auto Configuration 2.
In your case you can either stick a similar package naming convention like com.myapp.module and can have #ComponentScan("com.myapp.module.*").
I have a Spring Integration requirement , where I need to externalize the libraries and properties file from my war file. I am able to achieve this through Maven assembly plugin, where i create a zip file which may contain
lib/*.jar
properties/{artifactId}/*.properties
The reason I am adding the artifact Id to the path is, I will be creating 100s of wars in future and would need to distinguish between them.
This wars will not contain Web.xml and the Initializer is part of one of my libraries file.
THe Initializer should know the artifactId in order to load the correct properties.
With maven, the maven artifact details gets published to
META-INF/maven/${groupId}/${artifactId}/pom.properties
META-INF/maven/${groupId}/${artifactId}/pom.xml
If I could move these files to
META-INF/maven/pom.properties
META-INF/maven/pom.xml
My application would be able to read the artifact id from pom.properties.
I need help in achieve this.
Or if there are any other approach please help in solving the issue.
The Maven archiver component does that: see here at addMavenDescriptor element. It doesn't seem to be possible to customize the paths of these files.
But I guess every property you need can just be placed in a specific file and so you just have to create a resource file (properties like) containing all the information you want and let Maven filter that file for you.
I am new to maven profiles and am trying to create some different profiles in my pom file for my spring mvc webapp.
I have a property file in my classpath named env.properties. It lives in ...
Project Root>src>main>resources
And the content looks like this....
#spring.profiles.active=mock
#spring.profiles.active=test
spring.profiles.active=server
Is it possible to create my maven profile based on this file?
i.e. if spring.profiles.active=server is uncommitted so then the active profile is server?
is it acceptable to work the other way around?
as in, you set the properties in the pom.xml then generate the configuration file using this maven plugin http://mojo.codehaus.org/properties-maven-plugin/write-project-properties-mojo.html
I don't think it will work by loading the file around because the plugin would load the properties after the project profile is set
My maven top level project refers to a common-db project. In this project I have a spring file which defines the DB parameters.
However, I want the top-level project to define the DB parameters through the profile and inject these into the spring config file in /src/main/resources.
The top-level project only does the filtering on its own /src/main/resources files and ignores those located in the JAR dependencies.
How can I do this?
So you want to depend on common-db but then modify its contents to change the parameters in the config file? Ok, if you really want to do that, you could do something convoluted where you use dependency:unpack to expand the common-db jar, then overwrite / filter its contents, and then use a custom jar:jar execution to re-jar up the dependency and ship it with your application.
But, wow - why would you jump through all these hoops? Like #hoaz suggested, just place your application-specific config in the same classpath location so that it is loaded before common-db's default configuration. This is the convention followed by many, many Java libraries.