I'm new to maven, I keep running in to the following syntax:
<include>**/*</include>
Im not sure how to interpret **/*, is this some Java or maven convention?
It is more related to <fileset> Ant convention upon which Maven is built.
**/* : all files in all subdirectories: see Ant Patterns.
When ** is used as the name of a directory in the pattern, it matches zero or more directories.
For example: /test/** matches all files/directories under /test/, such as /test/x.java, or /test/foo/bar/xyz.html, but not /xyz.xml.
Related
At the end of my ant build id like it to call the equivalent of the command line call
mvn install:install-file -Dfile=my.jar -DgroupId=com.company.project -DartifactId=my_project -Dversion=1.0 -Dpackaging=jar -DgeneratePom=true
so that it will add the newly built jar to a maven repository which another project will rely on.
Ive tried using the maven-ant-task and have added the maven-ant-task jar to the ant built project and the following code to the build.xml:
<target name ="minstall" depends="jar">
<artifact:pom id="maven_install" file="maven_install.xml" />
<artifact:install file="${out.dir}/my_project.jar">
<pom refid="maven_install"/>
</artifact:install>
</target>
but seem to be missing something as it wont work for me. To begin with i get the error in the build.xml (ant build file) saying
The prefix "artifact" for element "artifact:pom" is not bound.
What am I doing wrong. I am fairly new to ant?
On a realted question what is the purpose of the associated POM file? I would not normally have a POM in this project as it is an ant build
Perhaps maven-ant-task jar is not installed, i.e. not in your ant CLASSPATH. You can follow this instruction for this.
As mentioned previously, you need to make sure the tasks are defined in your ant script, and the artifact namespace is understood.
The POM file is used (in this case) to tell the Maven repositories the dependencies of the JAR you are putting in the repository. The POM should also specify the JAR's identification information (groupId, artifactId, version number, license, etc.).
Strictly speaking, you do not need an external POM, you could define the information in your build.xml file as follows:
<!-- Assuming tasks defined, and 'artifact' namespace exists -->
<artifact:pom id="maven_install" groupId="com.whatever" artifactId="some-jar"
version="1.0" packaging="jar">
<dependency groupId="..." artifactId="..." version="..."/>
<dependency groupId="..." artifactId="..." version="..."/>
<license name="apache" url="http://www.apache.org"/> <!-- can be omitted -->
</artifact:pom>
<target name ="minstall" depends="jar">
<artifact:install file="${out.dir}/my_project.jar" pomRefId="maven_install"/>
</target>
When you install the JAR in the 'minstall' task, the POM should be generated with the appropriate dependencies in the local Repository.
That message means you are missing an xmlns:artifact attribute in your build.xml. Have a look at the installation page in the docs for an example.
As to the purpose of the POM file, it's mostly metadata so that maven can figure out dependencies properly. In a real maven build it also describes how to build, test and package. But in your case all that is done by ant instead.
I think that it makes no sense to put such commands in Ant's build.xml. If you want to have your jar file installed in your maven repo just use mvn install command.
Besides that, I guess that you are somehow confusing the purpose of Maven and Ant tools in your project. What I'd suggest is to use Maven as your main build tool. You can configure invokation of Ant targets in your POM file if you really need that. Personally, I think it is the best solution to have Ant called by Maven. Maven goals (such as clean, test, package, install and so on) are very simple to use and powerful (I guess that you can read it in every Maven tutorial).
In a multi-module maven project, is there a variable that points to the root project folder?
${project.basedir} points to the current project's directory,
${project.parent.basedir} points to the parent project's directory,
but is there a variable that always points to the root directory (the one from which the maven command was executed), no matter from which project inside the reactor?
I realized that the problem I wanted to solve is pretty much unsolvable. I wanted a variable that pointed to either project.basedir, project.parent.basedir, project.parent.parent.basedir etc, whichever is higher. But since a project's parent pom need not be it's parent in the file system, my whole approach won't help. So I am accepting Pascal's answer because it answers my question (even if my question does not solve my problem).
is there a variable that always points to the root directory (the one from which the maven command was executed)
user.dir (the working directory) should be that directory.
In the latest maven, you can use ${maven.multiModuleProjectDirectory}.
In Maven 3, ${session.executionRootDirectory} is "a variable that always points to the ... directory ... from which the maven command was executed."
Note that this is distinct from a property that gives the top-level root directory of a multi-module project, regardless of where in the directory structure mvn is executed from. Such a property does not exist to my knowledge, but you can use the ${basedir}/.. hack to achieve it. See this thread on maven-users for more details.
See also: Finding the root directory of a multi module maven reactor project
Use directory-maven-plugin with directory-of goal.
Unlike other suggestions:
This solution works for multi-module projects.
It works whether you build the whole project or a sub-module
It works whether you run maven from the root folder or a sub-module (unlike ${session.executionRootDirectory}
There's no need to set a relative path property in each and every sub-module!
The plugin lets you set a property of your choice to the absolute-path of any of the project's modules. In my case I set it to the root module...
In my project root pom:
<plugin>
<groupId>org.commonjava.maven.plugins</groupId>
<artifactId>directory-maven-plugin</artifactId>
<version>0.1</version>
<executions>
<execution>
<id>directories</id>
<goals>
<goal>directory-of</goal>
</goals>
<phase>initialize</phase>
<configuration>
<property>myproject.basedir</property>
<project>
<groupId>com.my.domain</groupId>
<artifactId>my-root-artifact</artifactId>
</project>
</configuration>
</execution>
</executions>
</plugin>
From then on, ${myproject.basedir} in any sub-module pom always has the path of the project root module. And of course, you can set the property to any module, not just the root...
Such property can be created using: directory-maven-plugin.
Using the plugin's highest-basedir goal you can assign the root path to any property you specify.
For me, there was a need for root directory during variable interpolation, not for plugins section - for local directory relative to root with hand-crafted jars. I know this is a bad practice to have local directory with jars, but this was a requirement of project.
Why I was unable to use different solutions:
${session.executionRootDirectory} and ${user.dir} are tied with directory from which maven command was executed. I want to refer to the same directory independently of directory, from which maven was launched.
${project.basedir} ,as mentioned above, points to current project directory, so child modules will search for jars in wrong location.
I had about 100 projects, so defining relative paths or usage of accepted answer for this question is quite complex in my case.
Directory plugin can be used only for plugin configurations, not for variable interpolation
So, in my case with bad requirements I have used environment variable which refers project root and used it in pom.xml. Use it as last resort, when other solutions do not work. Here is example, how I use environment variable in my case:
<repositories>
<repository>
<id>local-maven-repo</id>
<!--NOTE: export PROJECT_ROOT=<location>-->
<url>file:///${env.PROJECT_ROOT}/local-repo</url>
</repository>
</repositories>
As far I think, there is no such variable. There are only workaround like in accepted answer of Maven2 property that indicates the parent directory .
I am very new to Maven and running into a problem that I can't figure out. I have a multi-module project setup. In one of the sub-modules, I have some Unix bash scripts. In my assembly file, I want to build a zip file that contains all my Unix scripts with line ending of either "unix" or "lf". Every thing works as expected when I package my application at the sub-module level (scripts do have the right Unix line ending). However, when I package my application at the master project level, scripts don't end up in Unix line ending. Is there a solution for this problem ? Thanks.
Here is a sample snippet of my assembly file: (which is defined for one of my submodules at the submodule level)
<fileSet>
<directory>src/main/scripts</directory>
<outputDirectory>bin</outputDirectory>
<lineEnding>unix</lineEnding>
<fileMode>0755</fileMode>
</fileSet>
Looks like you're running into this bug: http://jira.codehaus.org/browse/MASSEMBLY-237.
Just force the assembly plugin version to 2.2-beta-3 and your problem should be solved.
We have our project build using maven. We try to run our unit test cases in maven build itself and for doing that we need to add DB2 driver jar in the dependency of all the sub projects.
Instead of doing that, we need a solution to specify the absolute path of the jar file as a mvn command line argument to use it in the running of unit test cases.
This is because the driver jar is available in our app server lib folder and we don't want to specify it in the dependencies of our projects.
Couldn't find a suitable solution googling it, hence requesting for an expert solution here.
Any workaround would be of greater help.
Thanks in advance.
The usual way would be to add a dependency to the database driver and limit the dependency to testing (test scope). So the library is available for unit tests but will not deployed and jar'ed.
Practically spoken, I'd create a maven artifact for this driver (just a basic POM file) and place it on the build servers maven repository (or the nexus, if you use it for the projects).
I'm using a dependency with scope set to 'system' to reference a jar that is available in the container but not in any maven repository. In this case the jar is put in a folder named 'lib' in the project like this, :
<dependency>
<groupId>groupId</groupId>
<artifactId>artifactId</artifactId>
<version>version</version>
<scope>system</scope>
<systemPath>${project.basedir}/lib/library.jar</systemPath>
</dependency>
The groupId, artifactId and version can be set to any value you want, the trick was that system dependencies have to be given with an absolute path, which is worked around by using the project.basedir property. It should also be possible to specify the complete path as a property.
We have our project build using maven. We try to run our unit test cases in maven build itself and for doing that we need to add DB2 driver jar in the dependency of all the sub projects.
Well, the maven way would be to declare the DB2 driver as dependency with a test scope in a parent project.
Instead of doing that, we need a solution to specify the absolute path of the jar file as a mvn command line argument to use it in the running of unit test cases.
You could use the additionalClasspathElement in the plugin configuration to pass the path to the driver:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<additionalClasspathElements>
<additionalClasspathElement>path/to/additional/resources</additionalClasspathElement>
</additionalClasspathElements>
</configuration>
</plugin>
If you variablelize it, you could pass the value on the command line.
But to be honest, I can't understand why you don't install the driver in a corporate repository and declare it as dependency. And if you don't have a corporate repository, use a file based repo as described in this previous answer (please, don't use the system scope bad practice). There is no good reason to go the hacky way.
I'm building a Maven project which has half a dozen modules.
I'm fine with importing it myself using either Maven or Ivy, but other teams would like to use those jars as well, but their practice is to commit the jars and source jars to version control.
I'd like to generate a zip/tar assembly of all modules and their sources which they can use however they like.
I've read Maven Assembly Plugin: Including Module Binaries but I'm shy of using it because:
The linked FAQ entry returns a 404;
I need to manually specify all modules.
Is there an alternative?
Update: I've tried using the built-in assembly descriptors
mvn assembly:assembly -DprojectModulesOnly=true
mvn assembly:assembly
and both failed with
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to create assembly: Error creating assembly archive bin: You must set at least one file.
right after all the module builds have run.
I think you're on the right lines, the moduleSets options of the assembly plugin handles what you're after.
If you're looking for some useful documentation, the Module Selection section of the Maven book covers it quite thoroughly, including how to configure includes and excludes, handle binaries and sources, and exclude external dependencies.
I had this problem, for me, the solution was NOT put / at the beginning of your <fileset><directory>
If you do that will work on Windows, not on Unix/Linux!
<fileSet>
<directory>src/main/</directory>
<outputDirectory></outputDirectory>
<includes>
<include>VERSION</include>
</includes>
</fileSet>
works whereas
<fileSet>
<directory>/src/main/</directory>
<outputDirectory></outputDirectory>
<includes>
<include>VERSION</include>
</includes>
</fileSet>
causes
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.3:single (execution-pluggin-assembly) on project test3: Failed to create assembly: Error creating assembly archive assembly: You must set at least one file. -> [Help 1]
Have a look at the How to use assembly:assembly using predefined descriptor ids. I think the bin and src pre-defined descriptor files are what you need.
Sounds like you need a build-server of some kind. I was at JavaZone 2009 this week and looked at Hudson CI http://hudson-ci.org/
The server will create the artifacts you or other teams can use/download.