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
Related
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.
I want to define a plugin configuration along with dependencies in the separate project B, then attach it to other project A so I can run phases/goals from the project B from project A. Is this even possible with maven?
You can run goals from plugins from the repository, if you give the full qualified name of the plugin, i.e.
groupId:artifactId:version:goal
If you want to use the short form, you either need to add it to your (parent) pom or to your settings.xml.
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
How can I make maven do a site:site and a site:deploy when the deploy is run?
Am I best off to make my own plugin (modified version of maven-release-plugin) or is there an easy way in Maven (configuration of a plugin within a profile)?
Thanks!
EDIT for clarification: I basically want a site-deploy done (to a special url) for snapshot releases. Namely the javadoc. Thanks!
Create two profiles.
The first will be active unless a property has been defined. It will use one URL.
The second one will be triggered by some property.
In each profile define the required settings for the site plugin with their respective differences.
We are using Maven(3.0.3) as build tool and we need to have different version for different environments (DEV , TEST, QA ) . If we pass version property value during build time based on environment , the installed POM doesn't have the passed property values instead it still has the ${app-version} string.
I saw already there is a bug for this http://jira.codehaus.org/browse/MNG-2971
Is there any other alternative ,because we cannot different POM file for different environments ,which will be hard to maintain..
Thanks
Vijay
Create different artifacts for the environments and use the parameter as a classifier. The pom is the same for all three artifacts but the classifier separates them.
Apparently Maven does not make any variable/property substitution when installing the POM. It is installed as is, that is the principle. You'd better not read any properties from POM (unless this is e.g. version number), bout you should configure your properties in external file (one per stage, e.g. dev.properties, test.properties, ...) and then configure Maven profiles (again, one per stage) and invoke Maven like mvn -Pdev depending on what you want to build. In profile you can package your final application with whatever properties you like (e.g. with the help of build-helper-maven-plugin:add-resource or maven-antrun-plugin + copy rule).
Alternatively you can filter your resources. For example, you can filter your Spring context XML file, which refers the properties file (so you package all property files, but Spring will refer only some specific). Or you can filter another properties file from which you will learn what is the "main" properties file to use (double indirection).
You should create the archives for your different targets within a single build and use as already mentioned the classifier to separate those artifacts from each others.