is it possible to create maven profile based on property file in classpath - maven

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

Related

How to chnage properties file and dependancy dynamically in spring boot

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

SpringBoot: GroupId and ArtifactId based on a property dynamically

Define GroupId and ArtifactId based on a property file
I would like to know if from Eclipse is possible to set dynamically the GroupId and ArtifactId from a property set on the file application.properties in a SpringBoot application
because from the same project I generate 2 different projects (core project and web project) based on #Profile
Attached Image
No it's not possible to set groupid and artifact id using properties file.But for profile setting using pom directly you can use below option.
"Profiles can be explicitly specified using the -P CLI option.This option takes an argument that is a comma-delimited list of profile-ids to use. When this option is specified, the profile(s) specified in the option argument will be activated in addition to any profiles which are activated by their activation configuration or the section in settings.xml"
Profiles can be activated in the Maven settings, via the section. This section takes a list of elements, each containing a <profile-id> inside.
<settings>
...
<activeProfiles>
<activeProfile>profile-1</activeProfile>
</activeProfiles>
...
</settings>
In case of using spring boot you can also apply spring.profiles.active=profile-1,profile-2
CHECKOUT THIS URL FOR FURTHER MORE
You want to built two or more different jars depending on the active profile set in project.
Maven can support this see https://maven.apache.org/guides/mini/guide-building-for-different-environments.html ,which creates profiles for building and packaging artifacts for different environments.
This feature was meant to support different build environments e.g production,development,testing... but i don't think anyone will be arresting you if you use profiles to modularize your project.

How to generate/retain javadocs for one module that is built with two maven profiles?

I have two maven profiles. Each profile generates javadocs for one module. Is there a way by which I can edit the apidocs/index.html page to allow to retain the classes generated by one profile and append the new classes generated by other profile? Right now I can generate the javadocs for individual profile builds but cannot retain the older classes when we build the project with the second profile as it overrides the earlier apidocs.
One way is to use the outputDirectory property of maven javadoc plugin, to set it to a different location for each profile.
See:
https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-no-fork-mojo.html#outputDirectory

Spring how to get Maven artifact name in runtime

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.

Maven filter src/main/resources of a JAR dependency

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.

Resources