I have 2 maven2 profiles, selenium and jspc. Now for "selenium" id'd like to have an implicit activation of "jspc", so that I don't have to write mvn -Pselenium,jspc from the command line. Is this possible ?
You can't "chain" profile activations (maven reference) but you can activate them both through the same property:
<activation>
<property>
<name>profile.selenium</name>
</property>
</activation>
And the run mvn -Dprofile.selenium
Related
I'm running a spring boot project with three different property files (application.properties, application-prod.properties, application-uat.properties. I'm using Maven and if I don't specify any argument, it will pick the default property file which is application.properties. Here's how the related files look.
application.properties
#Set active profile
spring.profiles.active=#activatedProperties#
#MongoDB configuration
spring.data.mongodb.host=${MONGODB_HOST:localhost}
spring.data.mongodb.port=${MONGODB_PORT:27017}
spring.data.mongodb.database=database
spring.data.mongodb.username=username
spring.data.mongodb.password=password
pom.xml
<profiles>
<profile>
<id>UAT</id>
<properties>
<activatedProperties>uat</activatedProperties>
</properties>
</profile>
<profile>
<id>PROD</id>
<properties>
<activatedProperties>prod</activatedProperties>
</properties>
</profile>
</profiles>
How can I achieve the same with Gradle? How can I let Gradle to pick the default (application.properties) if I don't specify any arguement?
I think this link will be useful for you...
https://docs.gradle.org/current/userguide/migrating_from_maven.html#migmvn:profiles_and_properties
Sample:
if (!hasProperty('buildProfile')) ext.buildProfile = 'default'
apply from: "profile-${buildProfile}.gradle"
task greeting {
doLast {
println message
}
}
#profile-default.gradle
ext.message = 'foobar'
#profile-test.gradle
ext.message = 'testing 1 2 3'
#profile-prod.gradle
ext.message = 'Hello, world!'
This link can be useful too:
https://www.baeldung.com/spring-profiles
I need to set flyway migration and I don't want to put password and username in pom.xml, I created flyway.properties file, but it's not working, I'm getting this error
Failed to execute goal org.flywaydb:flyway-maven-plugin:6.5.1:clean (default-cli) on project entesting: org.flywaydb.core.api.FlywayException: Unable to connect to the database. Configure the url, user and password!
flyway.properties file is in same directory as pom.xml
flyway.user=sa
flyway.password=passwordForThis
flyway.url=jdbc:sqlserver://172.23.176.144;database=DB_Name
flyway.locations=filesystem:src/main/resources/db/migration
flyway.driver=com.microsoft.sqlserver.jdbc.SQLServerDriver
pom.xml flyway plugin config:
<plugin>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<version>6.5.1</version>
<configuration>
<url>jdbc:sqlserver://172.23.176.144;database=DB_Name</url>
<user>sa</user>
<password>passwordForThis</password>
</configuration>
</plugin>
To summarize I don't want to add password, username etc. in pom.xml(that works), I want it to be in flyway.propeties.
Flyway can be configured in a number of ways beyond directly putting it into the maven pom.xml. See documentation on configuring the maven plugin
The contents of the properties file you showed looks like the contents of a flyway.conf file.
Flyway will search for and automatically load the <user-home>/flyway.conf config file if present.
It is also possible to point Flyway at one or more additional config files. This is achieved by supplying the System property flyway.configFiles as follows:
mvn -Dflyway.configFiles=path/to/myAlternativeConfig.conf flyway:migrate
See https://flywaydb.org/documentation/maven/#config-files for more information.
Alternatively for storing the database user and password, Maven settings.xml files can also be used:
<settings>
<servers>
<server>
<!-- By default Flyway will look for the server with the id 'flyway-db' -->
<!-- This can be customized by configuring the 'serverId' property -->
<id>flyway-db</id>
<username>myUser</username>
<password>mySecretPwd</password>
</server>
</servers>
</settings>
I am trying to use Maven for a Java native project, using it to determine whether the current system is 64 bit or 32 bit. So that if the system is 32 bit, the following tag
<linkerStartOption>\foo\${the.folder}\Microsoft SDK\lib</linkerStartOption>
has the value \foo\Program Files\Microsoft SDK\lib, or if the system is 64 bit, have the link be the value \foo\Program Files (x86)\Microsoft SDK\lib.
The problem is currently my project uses <activeByDefault> tag to set a release version profile, which is being overwritten when the profile for determining 32 bit or 64 bit system is activated. This caused the properties determined by the release profile to not be available and cause the Java native build to fail. The release profile is used for release and there is also a debug profile used for debugging, which uses different <linkerStartOption> flags, so I don't want to just have release profile flags always be active.
My question is if there is a way for my native Java application to determine the 32-bit Windows Program Files path without deactivating the release profile triggered as <activeByDefault>?
Here is my profile for determining system architecture:
<profile>
<id>architecture</id>
<activation>
<os>
<family>Windows</family>
<arch>amd64</arch>
</os>
</activation>
<properties>
<the.folder>${env.PROGRAMFILES(X86)}</the.folder>
</properties>
</profile>
Here is the release profile being overwritten:
<profile>
<id>release</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<options>/foo -bar</options>
</properties>
</profile>
I have two java projects A and B, If I have a credentials.properties file in A and I want to access the same properties file in project B, Is there a way I can achieve this?
The two projects are maven build.
Try this:
<resource>
<directory>${other projects dir}/src/main/resources</directory>
<includes>
<include>*.properties</include>
</includes>
<filtering>true</filtering>
</resource>
Give the path as a full path
Keep the property file in the class path of B and set Project B as a dependency to project A.
Commiting cleartext passwords into your source control is normally a bad idea...
How about using a shared Maven profile in your settings file? ($HOME/.m2/settings.xml):
<settings>
..
<profiles>
<profile>
<id>credentials</dev>
<activeByDefault>true</activeByDefault>
<properties>
<password1>XXXXX</password1>
<password2>YYYYY</password2>
..
..
</properties>
</profile>
..
</profiles>
..
</settings>
This approach is more Maven friendly and encryption is supported.
If you use Jenkins to build your code, you can use a plugin to manage the settings file centrally:
How to manage maven settings.xml on a shared jenkins server?
Your project can still have a default value, the key point is that the real passwords are set externally to files under source control.
I'm trying to use a custom maven wagon extension to deploy a jar to my own repository. Can I somehow configure in settings.xml that it recognizes the custom url scheme to be used with the specific wagon or do I have to always modify pom files to contain the wagon extension?
There doesn't need to be a base pom or any pom available when using the deploy-file. Settings.xml is the only place which is guaranteed to be there, but I can't figure out how to use it to define extensions.
OK, ok, a correction: you cannot define the <build> element inside a <profile> defined in settings.xml. You could activate the profile in settings.xml, but define it in your base-pom.
Sorry, the only other way I could think of (probably what are you looking for), is to copy the extension jar directly under $M2_HOME/lib. All $M2_HOME/lib/*.jar are put in the classpath, so this must virtually have the same effect as an <extension>.
The extension however is better, because you can more easily control which version of the extension is used (e.g. trough the base-pom).
OK just try copying the extension jar under
$M2_HOME/lib
I don't know if the comment above by Brian Fox is still valid in 2013. But in the end I had to create a minimal pom.xml in the directory where I tried to upload the artifact to enable the wagon build extension.
I had to add groupId, artifactId and version to the pom.xml so that Maven would not complain although I provided them to the deploy-file goal on the commandline (I guess deploy-file would only care about the commandline parameters though):
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><modelVersion>4.0.0</modelVersion>
<groupId>your-groupId</groupId>
<artifactId>your-artifactId</artifactId>
<version>your-version</version>
<build>
<extensions>
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ssh</artifactId>
<version>2.4</version>
</extension>
</extensions>
</build>
</project>
With this simple "pom.xml" in place I could execute the deploy-file finally using scp as the protocol:
mvn deploy:deploy-file -Durl=scp://shell.sourceforge.net:/home/project-web/... -DrepositoryId=repoId -Dfile=my-file.jar -DgroupId=your-groupId -DartifactId=your-artifactId -Dversion=your-version -Dpackaging=jar
You need to add the wagon extension to your top level pom.xml. Most environments have a corporate one at the top of all their projects (best practice), so this generally isn't too painful for individual developers -- they just inherit from the corporate pom.
<build>
<extensions>
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-scm</artifactId>
<version>1.0-alpha-7-SNAPSHOT</version>
</extension>
<extension>
<groupId>org.apache.maven.scm</groupId>
<artifactId>maven-scm-manager-plexus</artifactId>
<version>1.0-beta-3-SNAPSHOT</version>
</extension>
<extension>
<groupId>org.apache.maven.scm</groupId>
<artifactId>maven-scm-provider-svnexe</artifactId>
<version>1.0-beta-3-SNAPSHOT</version>
</extension>
</extensions>
</build>
<distributionManagement>
<site>
<id>my.svn.server</id>
<url>scm:svn:https://username#svn.apache.org/svn/root/module</url>
</site>
</distributionManagement>
When you register your provider, it also registers the protocol pattern as well I believe. You can see a full list of the existing providers here.
I believe it is the getScmType() method that registers the extension, but I'm not 100% certain.
/** {#inheritDoc} */
public String getScmType()
{
return "git";
}
The link to the Git provider's source can be found here.
siddhadev is right, but there are few additional things...
(I'd put this in a comment but I don't have enough reputation)
You can keep your JARs cleanly separated by putting them under:
$M2_HOME/lib/ext
You need all of the dependencies, so do something like:
cd ~/.m2/repository/org/apache/maven/wagon/wagon-ssh-external/2.2
cp wagon-ssh-external-2.2.jar $M2_HOME/lib/ext
cp wagon-ssh-external-2.2.pom pom.xml
mvn dependency:copy-dependencies -DoutputDirectory=$M2_HOME/lib/ext