I have my standard flyway config in my pom file and I am trying to override in through system properties, as mentioned here.
Here is my configuration in the pom file:
<plugin>
<groupId>com.googlecode.flyway</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<url>dbUrl</url>
<user>dbUser</user>
<password>dbPass</password>
<schemas>
<schema>core</schema>
<schema>public</schema>
</schemas>
</configuration>
</plugin>
And following is the command line that I'm running:
mvn clean compile flyway:migrate -Dflyway.url=anotherDbUrl -Dflyway.user=anotherDbUser -Dflyway.password=anotherDbPass
The documentation in the above link says System properties > Maven properties > Plugin configuration. Am I missing something?
Good catch. This seems to have broken along the way. Could you please file an issue? I'll fix this in time for 2.2.1.
Related
I have configured the Jetty Maven plugin to run my compiled war.
Here is the relevant part of my pom.xml.
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.4.50.v20221201</version>
<configuration>
<war>${jway.webapps.dir}/myapp.war</war>
<scanIntervalSeconds>2</scanIntervalSeconds>
</configuration>
</plugin>
If I execute mvn jetty:run-war, my war is build and Jetty serves the app as expected.
I have configured scanIntervalSeconds to allow hot redeploy.
However, if I rebuild using mvn install, I get the following error during redeployment:
java.lang.IllegalStateException: Failed to delete temp dir F:\...\myproject\target\tmp
at org.eclipse.jetty.webapp.WebInfConfiguration.configureTempDirectory (WebInfConfiguration.java:532)
at org.eclipse.jetty.webapp.WebInfConfiguration.resolveTempDirectory (WebInfConfiguration.java:424)
at org.eclipse.jetty.webapp.WebInfConfiguration.preConfigure (WebInfConfiguration.java:140)
at org.eclipse.jetty.webapp.WebAppContext.preConfigure (WebAppContext.java:488)
at org.eclipse.jetty.webapp.WebAppContext.doStart (WebAppContext.java:523)
at org.eclipse.jetty.maven.plugin.JettyWebAppContext.doStart (JettyWebAppContext.java:397)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start (AbstractLifeCycle.java:73)
at org.eclipse.jetty.maven.plugin.JettyRunWarMojo.restartWebApp (JettyRunWarMojo.java:113)
at org.eclipse.jetty.maven.plugin.AbstractJettyMojo$1.filesChanged (AbstractJettyMojo.java:472)
at org.eclipse.jetty.util.Scanner.reportBulkChanges (Scanner.java:848)
at org.eclipse.jetty.util.Scanner.reportDifferences (Scanner.java:765)
at org.eclipse.jetty.util.Scanner.scan (Scanner.java:641)
at org.eclipse.jetty.util.Scanner$1.run (Scanner.java:558)
at java.util.TimerThread.mainLoop (Timer.java:555)
at java.util.TimerThread.run (Timer.java:505)
It seems that Jetty wants to delete the file, but Windows locks the file. In the plugin documentation, I have not found any configuration which seems to be helpful. Furthermore I have nothing found on Google. Is there any way to solve this issue?
I don't know if its relevant, but I do not use the jetty:run goal, because my war is build using a third party tool and I do not have a standard directory structure.
The jetty documentation contains a section about Troubleshooting Locked Files on Windows.
So I updated my plugin config according to the documentation:
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.4.50.v20221201</version>
<configuration>
<war>${jway.webapps.dir}/myapp.war</war>
<scanIntervalSeconds>2</scanIntervalSeconds>
<webApp>
<_initParams>
<org.eclipse.jetty.servlet.Default.useFileMappedBuffer>false</org.eclipse.jetty.servlet.Default.useFileMappedBuffer>
</_initParams>
</webApp>
</configuration>
</plugin>
It seems like maven assembly plugin always output to ${project.dir}/target regardless of all the descriptor fields I set. Is this feature supported by maven assembly plugin?
You can of course change that behaviour by using the correct configuration for outputDirectory like this:
<plugin>
<groupId>org.apache.maven.plugin</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.5.5</version>
<configuration>
<outputDirectory>TheLocationYouLike</outputDirectory>
..
</configuration>
</plugin>
But i can't recommend that, cause it is against the convention over configuration paradigm.
I only want to document two classes from a package. In standard javadoc tool, it would be something like:
C:> javadoc -d C:\home\html C:\home\src\java\awt\classA.java C:\home\src\java\awt\classB.java
How can I do it in maven-javadoc-plugin?
sourceFileIncludes should do what you're looking for.
https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#sourceFileIncludes
Here's an example:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.10.1</version>
<configuration>
<sourceFileIncludes>
<include>com/mycompany/myproject/MyClass.java</include>
</sourceFileIncludes>
</configuration>
</plugin>
UPDATE:
I tried this out on one of my maven projects and it worked at the package level, but not on individual classes. It looks like these open Maven issues are the cause:
http://jira.codehaus.org/browse/MJAVADOC-388
http://jira.codehaus.org/browse/MJAVADOC-365
Note that issue #365 is actually related to sourceFileExcludes; the fix for that is scheduled for maven-javadoc-plugin 2.11.
I have a JHipster generated application with an YAML property file that looks like this:
storage:
location: ${user.home}/my/folder
My problem is that the variable ${user.home} is resolved at build time, when I run mvn package (on Jenkins). So the property is already resolved in the resulting artifact, hence when I deploy on on my server, that path contains the resolved home of the user Jenkins.
Anybody know who is doing this and why? I was expecting that the variable would be resolved at runtime.
Thanks.
Valentin
I'm not totally sure of how JHipster builds on top of Spring Boot, but my guess would be that it's Maven's resource filtering that's expanding ${user.home} at build time. It's enabled by default by spring-boot-starter-parent for application.properties and application.yaml in src/main/resources.
This Spring Boot issue contains some more information, along with details of a configuration change that you may like to make so that ${…} entries are no longer filtered:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
<configuration>
<encoding>UTF-8</encoding>
<delimiters>
<delimiter>#</delimiter>
</delimiters>
<useDefaultDelimiters>false</useDefaultDelimiters>
</configuration>
</plugin>
I would like to setup my maven release to run in batch mode, but I'm not a fan of the default scm tag ${artifactId}-${releaseVersion}. Instead, I'd like to simply tag it with ${releaseVersion}; however, I'm unclear if such a property exists (ie. without the -SNAPSHOT suffix).
I'd like the configuration to resemble the code below. Is such a default tagging possible with the maven-release-plugin?
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.0</version>
<configuration>
<tag>${releaseVersion}</tag>
</configuration>
</plugin>
I just got this to work when using Hudson to do my release. I noted that Hudson (with the Maven Release Plugin) is initiating the command with a property like -Dproject.rel.com.example:my-artifact-id=1.0.1. Using the following plugin configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<configuration>
<tag>REL-${project.rel.com.example:my-artifact-id}</tag>
</configuration>
</plugin>
Resulted in the tag being REL-1.0.1
I'm new to the release plugin but I would assume something similar would work from the command line.
You can pass in the properties for:
releaseVersion -- What version you want it to be released as (1.0)
developmentVersion -- The next version (2.0-SNAPSHOT)
tag -- The name of the tag
a 1.0-SNAPSHOT implies a 1.0 release version, but doesn't set it. You can set that property in your POM file as a regular property.
try this:
<configuration>
<tag>${project.version}</tag>
</configuration>