i use the maven-buildnumber-plugin to generate my version number for JAR/WAR/EAR packages. So when doing a compile i'll get for example ${project.version}-${buildNumber}, because is set to this value. But when using mvn deploy just ${project.version} is the filename, samen when i set in pom.xml to XX ${buildNumber} then the filename ist file-XXX ${buildNumber} (<- not the content of buildNumber, instead ${buildNumber as test}). What do i do wrong? i also want to have the files installed with ${project.version} ${buildNumber}.
thx for any help
markus
Not 100% sure I follow your question, but I had a problem getting a build number in my WAR manifest. The discussion here helped me out. I had to create a global property called build.version
<properties>
<build.version>${project.version}-r${buildNumber}</build.version>
</properties>
and use that instead of using ${buildNumber} directly. Hopefully that'll be some help with your problem.
Related
I am trying to add a WSDL module to my existing application, but I'm struggling to get the dependencies resolved.
According to their website, this is the correct dependency
<dependency>
<groupId>org.ow2.easywsdl</groupId>
<artifactId>easywsdl-wsdl</artifactId>
<version>2.1</version>
</dependency>
After a search (search.maven.org), I already changed the version to 2.3 and there are a bunch of files that are downloaded into my local repository, but when running the application (with the websites demo code), I bump into this error:
java.lang.ClassNotFoundException: com.ebmwebsourcing.easycommons.uri.UriManager
And I believe it has something to do with the missing artifacts :
com.ebmwebsourcing.easycommons:easycommons.uri:jar:1.1
com.ebmwebsourcing.easycommons:easycommons.logger:jar:1.1
In particular the first one. Now, I'm relatively new to using Maven... How would I go about solving this?
Thanks.
The solution is to add the petalslink repository. Appearantly the standard maven repository doesn't contain the easycommons dependency. The petalslink repository does.
How can I use maven properties in site APT files? For example I want to use ${project.version} in the index.apt so I can always refer to the latest version without manually changing the index.apt file before deploying the site.
Found it. Just had to rename the apt files to *.apt.vm. Maven then pipes the files through Velocity which can process the properties.
My download.apt.vm looks like this:
Download
{{${sitePublishUrl}}}
where the pom.xml contains
<properties>
<sitePublishBase>http://artifactory.foo.com/mvn/libs-release-local</sitePublishBase>
<sitePublishUrl>${sitePublishBase}/${project.groupId}/${project.artifactId}/${project.version}</sitePublishUrl>
</properties>
Note: custom properties containing a dot (e.g. ${my.repository}) will not work. This is a limitation of Velocity. Instead use something like ${myRepository}.
See also http://maven.apache.org/plugins/maven-site-plugin/examples/creating-content.html#Filtering
I want to put a configuration file in my Maven project. Looking at the standard directory layout, there are two places that seem sensible, "src/main/resources" and "src/main/config". Could someone explain the difference between these, and explain when you would put something in config and when in resources?
In this case, the file I'm looking at is ehcache.xml, but my question isn't ehcache specific, I'm curious for log4j.properties etc.
A bit of googling discovered this person had the same question, but the answers seemed contradictory, and not very authorative.
The email exchange at http://www.mail-archive.com/users#maven.apache.org/msg90985.html
says:
"This is all theory... Perhaps while writing the docs, someone involved with Maven development thought it might be useful to have a src/main/config directory and so it was included in docs, but since it was never implemented in the code, it is not being used today."
and
"The directory [src/main/config] doesn't show up on the classpath so the application or test classes
can't read anything in it."
So just use src/main/resources.
Note: I don't know if this is true (I'm the question asker), but that would explain why so many people on the web recommend src/main/resources for log4j.properties. If people agree this is the right answer could you let me know (comment or vote) I put it here to save other people the typing.
scr/main/resources is a place where you put your images, sounds, templates, language bundles, textual and binary files used by the source code. All config files like excache.xml, log4j.properties, logback.xml and others go to src/main/config.
Add to your pom.xml:
<build>
<resources>
<resource>
<targetPath>.</targetPath>
<directory>src/main/config</directory>
</resource>
</resources>
</build>
The inclusion of src/main/config in Maven's standard directory layout has been removed due in part to the confusion caused between src/main/config and src/main/resources. This very stackoverflow question is actually referenced in the JIRA ticket for the removal of src/main/config from Maven's standard.
Short answer: Use src/main/resources not src/main/config. It's the (new) Maven way.
Use case is pretty straightforward if you ask me. (It seems src/main/config has since been removed standard directory layout)
/src/main/resources go on into jar and thus on classpath
/src/main/config is intended for assembly plugin where you might construct a
zip file:
hello-world.zip
lib/
<dependencies>
bin/
run.bat
run.sh
config/
config.properies
When using the release plug-in for Maven on Hudson(1.368), I am getting an error that my distributionManagement section is missing during the deployment phase to our Nexus Maven Repository Manager. If I deploy without using release It woks just fine so should not be a misconfiguration with the server, the section or the settings.
It is worth noting that my company uses different pom files for Hudson and have named them differently. Also the settings.xml in in the individual project directories. This has never been a problem as Hudson allows for the name of the pom and the location and name of the settings file to be specified.
The reason I note the above is that when distributionManagement is moved into the regular pom.xml it does find it (but still doesn't work because its missing the username and password in the settings file). This confuses the heck out of me since for the prior parts of the release process, it uses the correct pom and settings. It just seems to forget them later on. What is going on here?
Thank you in advance.
UPDATE
It seems that the maven release plug-in spins up a new instance of maven which, it seems, is using the default pom.xml rather than our differently named pom. More testing is needed.
The answer (for any lost souls who stumble upon this question) is that maven was indeed forking out a new process which was not using the correct pom file and settings. The solution was to add a section to the pom file as thus:
<plugin>
<artifactId>maven-release-plugin</artifactId>
<version>2.0</version>
<configuration>
<goals>-f POMFILE -s SETTINGSFILE deploy</goals>
</configuration>
</plugin>
This specified those two files to the new maven process.
If I deploy without using release It woks just fine so should not be a misconfiguration with the server, the section or the settings.
Well, there is clearly a misconfiguration somewhere, be it at the Hudson level. But it will be hard to spot it without seeing the pom, the settings, the active profiles, the profiles used during the release, the Hudson setup, etc.
First step: try to reproduce the problem on the command line using the exact same configuration as Hudson.
Second step: use the Maven Help Plugin to understand and debug the issue. More specifically, the following goals:
help:active-profiles
help:effective-pom
help:effective-settings
The reason I note the above is that when distributionManagement is moved into the regular pom.xml it does find it (but still doesn't work because its missing the username and password in the settings file).
It's unclear where the distributionManagement is specified if outside the project's pom.xml (in a corporate environment, it goes typically in a corporate pom.xml, is it the case here?).
It's also unclear if you are actually providing the username and password for a server id matching the repository id of the distributionManagement.
But somehow, a wrong combination is used here. Double check what profiles/settings are active during release/deploy to spot the problem as suggested.
See also
The Maven Deploy Plugin Usage page
First of all, I do have some sort of understanding that the following might not be the generally accepted way to do things.
We have a Maven 2 project that has a version number which should be updated each week or so, during a new release. During this process, I've tried to eliminate all the things one has to remember and I've made a bash script that handles the process interactively.
However, my problem is updating the pom version from the command line. I can do this with sed but I don't think it is very convenient. I was wondering if there is any maven plugin that would be able to modify the pom.xml directly from the command line. The version is set in the properties section of the pom. Would it be possible to write a plugin that would change the properties?
Thanks in advance.
Update
It seems that my issue was with project versions defined as properties (that were applied when filtering) which seems now a bit dumb.
One thing that I'm still looking for an answer is how to get the version of certain project reliably to the command line. Previously I had a "pretty unique" property that I got using grep, but now the <version> element is not unique as in child project there is at least two of these. I would need some sort of XML parser if Maven has no solutions, but my goal is to make the script as independent as possible.
I'm not sure if I should've created a new question from this, but I didn't. Getting the version is very closely related to the setting the version.
I was wondering if there is any maven plugin that would be able to modify the pom.xml directly from the command line.
The Versions Maven Plugin can do this. Check the following goal:
versions:set can be used to set the project version from the command line, updating the details of any child modules as necessary.
From Maven POM reference:
env.X: Prefixing a variable with
"env." will return the shell's
environment variable. For example,
${env.PATH} contains the PATH
environment variable. Note: While
environment variables themselves are
case-insensitive on Windows, lookup of
properties is case-sensitive. In other
words, while the Windows shell returns
the same value for %PATH% and %Path%,
Maven distinguishes between
${env.PATH} and ${env.Path}. As of
Maven 2.1.0, the names of environment
variables are normalized to all
upper-case for the sake of
reliability.
That means that you can have an environment variable like $MYMAVENPROJECTVERSION and read it as this:
<version>${env.MYMAVENPROJECTVERSION}</version>
You can update this environment variable every week, before running build.
Hope this will help you.