I'm using the maven-jaxb2-plugin (from org.jvnet.jaxb2.maven2) to generate classes from an XSD schema. All is working fine and the generated classes are all that I need. Except for one thing, all the generated comments inside those classes are using my computer locale (which is french).
I'd like to be able to change the locale of the generated comments (to use english for example). Can it be done through the plugin configuration or the project configuration in the pom.xml ? Or must it be done in my shell when I run the mvn command?
I tried setting the project.build.sourceEncoding but that doesn't change the locale. I tried setting the user.language or user.country but that doesn't have any effect on the output.
There is an option to pass some arguments to the xjc command that I could use, but I cannot find anything related to locale when calling xjc.
The best thing is to put the following into your pom:
<project>
...
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
...
</project>
The above will also influence the maven-compiler-plugin etc. Furthermore the jaxb2-maven-plugin will also be influenced by the above property (${project.build.sourceEncoding}).
Related
I want to populate some external files from the same project with some variables from pom.xml before the compilation phase.
<properties>
<version.Var1>1.0.0-1</version.Var1>
<version.Var2>1.0.0-2</version.Var2>
<version.Var3>1.0.0-3</version.Var3>
</properties>
What is the best approach for doing that? Let's imagine that I have a file called versions.xml, and I want to use the previous versions(Var1,Var2,Var3) there.
I want to know which is the best approach.
You can try to import properties into project using:
properties-maven-plugin
I'm getting an error when running maven build (unable to load a dependency).
[ERROR] Failed to execute goal on . . .
Could not transfer artifact my.group:libme1:${someVariable} from/to . . .
I believe that the developer that published this artifact was supposed to be setting the variable ${someVariable} but didn't. I think this is a bug but I'm trying to work around it by setting the variable.
The POM for the JAR I'm depending on my.group:libme1:1.2.3 looks like this (snippet highlighting the issue):
<groupId>my.group</groupId>
<artifactId>libme1</artifactId>
<parent>
<groupId>my.group</groupId>
<artifactId>libme1-parent</artifactId>
<version>${someVariable}</version>
</parent>
I tried defining it by adding -DsomeVariable=1.2.3 on the command line but it didn't work. For example, this command
mvn -DsomeVariable=1.2.3 clean install
should work based on Baeldung's article but doesn't.
I also ran:
mvn -DsomeVariable=1.2.3 help:effective-pom
and I see the variable being set, so I know he POM I'm using has that defined, but for some reason another POM doesn't pick up that value (or that is how it appears to me).
Is there any way to set the variable so it can be used in another POM? I'm guessing this is not possible.
Searching for an answer I found:
The maven doc
https://maven.apache.org/settings.html#Activation
If you know that this is bug, please let me know. I'm also reaching out to the publish of the artifact to ask them how this is supposed to work.
Basically the dependency's pom is invalid, the reasoning is following:
maven allows developers to do following things:
define dependencies in parent pom
impose restrictions on dependencies via <dependencyManagement> in both current and parent pom
use placeholders ${...} in <version> element, which somehow get resolved via system properties and current/parent pom properties
all those features mentioned above are very convenient from development perspective, however when you publish artifacts those features cause a pain in behind: that became not possible to use external library without it's parent pom, because parent pom may define dependencies and properties.
In your particular case someone have define version of parent pom as ${someVariable}, that in turn means it is not possible to use that library without information about the value of ${someVariable}. However, even if you had known the "correct" value of ${someVariable} and might specify it via system properties, that would cause some weird behaviour: today you may specify one value for ${someVariable}, tomorrow you (or someone else) will specify another value and ultimately you will get different builds, due to that maven denies such configurations (that is much better to fail a build rather than build something unreliable), that would be wiser to initially deny publishing such poms, but we have what we have.
It might be that the variable was stored in some user's settings.xml.
This would allow checking out an older version already in production for writing patches.
<settings>
...
<profiles>
<profile>
<id>work-in-progress</id>
<properties>
<someVariable>1.2.3</someVariable>
</properties>
</profile>
</profiles>
<activeProfiles>
<activeProfile>work-in-progress</activeProfile>
</activeProfiles>
</settings>
So you might do that too. And search in users' directories, .m2 repo directories where usually the settings.xml is stored.
I would like to deploy java app twice to one tomcat server, each time with different environment properties.
I would like to find a way like
mvn tomcat7:deploy -Denvironment=local
I don't mind using other maven plugin.
With no need to change files after deploy.
Is it somehow possible?
Thank you for you answer.
You can have a configuration file (something like e.g. application.properties) that you enable resource filtering for. You could then parameterize the values in that configuration file, and pass in different parameter values for each of the deployments (-Dkey1=value1 -Dkey2=value2).
You could pass the different parameter values on the command-line, or you could cement them in different profiles, and just activate the appropriate profile from the command-line (-Psecond-deployment).
What seems a little unfortunate from the suggested approach in your question is: in its most basic sense Maven is a build tool, meant to produce a consistent artifact from a build. This is no longer the case with the suggested approach in your question. If this is a web application that is never used as a dependency of other module, this may be fine. But just highlighting that different deployment configurations is a deployment concern, not a build concern.
I used little workaround.
I created different profiles which I use to update application property.
example:
In my POM I have:
<profiles>
<profile>
<id>local</id>
<properties>
<environment>local</environment>
....
</properties>
</profile>
and in application.property file I have
environment=#environment#
(That # are correct! )
This way I can deploy my app with defined environment by using command
mvn -P local tomcat7:deploy
and use environment variable anywhere else as ${environment}
I have made some code changes to javac and would like maven to use the version of javac that I changed. Unfortunately, it appears that maven ships its own javac implementation. How can I get maven to compile sources using the system wide javac (the one that is executed when running javac in the shell).
Without really knowing what these options mean, I tried providing the fork, and forceJavacCompilerUse which I found here: http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html
But they do not appear to help at all.
You're in the right ballpark. Look here:
http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html
To avoid hard-coding a filesystem path for the executable, you can use
a property. For example:
<executable>${JAVA_1_4_HOME}/bin/javac</executable>
Each developer then defines this property in settings.xml, or sets an
environment variable, so that the build remains portable.
<settings>
[...]
<profiles>
[...]
<profile>
<id>compiler</id>
<properties>
<JAVA_1_4_HOME>C:\Program Files\Java\j2sdk1.4.2_09</JAVA_1_4_HOME>
</properties>
</profile>
</profiles>
[...]
<activeProfiles>
<activeProfile>compiler</activeProfile>
</activeProfiles>
</settings>
If you build with a different JDK, you may want to customize the jar
file manifest.
I believe the key is setting an explicit <executable>. And I suspect it can probably be hard-coded, without messing with environment variables or other clauses.
See also this link, and look at the "executable" in the sample pom.xml:
Where is the JDK version to be used by Maven compiler specified?
I believe maven looks for JVA_HOME for finding the java. So when you set it to your specific java maven should be able to use it
Please do you know if it's possible to automatically replace one Maven plugin with another in the POM files for a project?
The context is that I'm trying to intercept a Scala build using a Scala compiler plugin, for which I want to be able to specify the Scala compiler plugin as an argument to scalac from the command-line (i.e. not within the POM files). This is possible using the latest version of the Scala Maven plugin (known as scala-maven-plugin) by using its addScalacArgs flag - see here: http://davidb.github.com/scala-maven-plugin/apidocs/scala_maven/ScalaMojoSupport.html. However, it's not possible for the old version of the plugin (known as maven-scala-plugin), and I'd need to add the argument in all the various POM files (not an attractive proposition when dealing with a large, third-party project).
My thinking is that if I can automatically replace the old version of the plugin with the new version in the POM files, then I can use addScalacArgs and everything will work out well. I can probably cook up some code to do this (evidently doing it manually would be no better than going through and adding the argument), but it seems like the sort of thing that might be a supported Maven use-case.
Being specific, I'm trying to replace this plugin:
<plugin>
<groupId>org.scala-tools</groupId>
<artifactId>maven-scala-plugin</artifactId>
...
</plugin>
with this one:
<plugin>
<groupId>net.alchim31.maven</groupId>
<artifactId>scala-maven-plugin</artifactId>
...
</plugin>
You can do this with two profiles in your pom. One activate by default the other not. Then you can easily select which to use accordingly which profile you choose.
For exemple, here is a older post in the same spirit : How do I exclude a dependency in provided scope when running in Maven test scope?