I have maven multi-modules project. At the parent level, i have some java files. And in the parent pom.xml, at the package phase i do some stuff.
Usually, when i run mvn package at parent level, the package phase of parent pom will be run and all the modules will be packaged as well.
I am looking for a way that allow me to do these (when i run mvn package):
allow me to run only paren pom.xml (the script at the package phase), not the modules. This is the 1st priority.
allow me to run paren pom.xml and some particular modules (like module 1, module 2 BUT not module 3 , module 4).
Can i use profile for those issue?
Thanks.
While I agree with the fact that you may not have optimal project structure, the answer is that Maven 2.2.1 has an option "--non-recursive" which satisfies your first requirement:
-N,--non-recursive Do not recurse into sub-projects
So something like this:
mvn --non-recursive clean compile
Why do you want to have java code on the top level? In my opinion this is not a very good idea. Have your code in the subprojects and let the top-level project be responsible for holding the general information and configuration of the entire project.
If you have some base-library code in the top-level project now, you can put it in a sub-project and set up dependencies between the projects.
Take a look at Maven parent pom vs modules pom
The nature of your question indicates that your project structure may not be optimal.
Related
In the pom for a webapp, I'm looking for a way to recompile the local source code for two dependencies, then copy those jars over to the webapp's WEB-INF/lib directory. Is there a Maven 2 plugin that would allow me to do this, or some better approach using Maven 2?
I don't know if there is an easy way to do that.
One solution is to put all three projects in a reactor (a project with ), they will build in the right order when the reactor project is invoked.
I have a multi module maven project and I would like to use versions in such a way that the developer has to touch only the root project pom to change the version of all modules.
For example
ProjA contains
Module1
Module2
Module3
All the modules contain their own Poms and have ProjA's pom as their parent. Once I run the build I get a jar created for each module. Now For building a newer version of ProjA, I just have to change the version of the ProjA's pom and all the poms of the modules should pick up this new version from the parent. This works if I harcode the parent version in all the module's pom. But this will also force me to update the poms of all modules for every version change in the parent pom which defeats it purpose.
Is there a way to avoid this and still achieve the stated behaviour?
Use the Maven Versions Plugin and its versions:update-child-modules goal:
versions:update-child-modules updates the parent section of the child modules of a project so the version matches the version of the current project. For example, if you have an aggregator pom that is also the parent for the projects that it aggregates and the children and parent versions get out of sync, this mojo can help fix the versions of the child modules. (Note you may need to invoke Maven with the -N option in order to run this goal if your project is broken so badly that it cannot build because of the version mis-match).
I have two maven projects:
project-api
project-impl
project-impl's POM specifies a dependency on project-api. The top level aggregation pom lists modules project-api and project-impl.
If I run compile at top level, the dependencies resolves correctly. If I run compile at project-impl, then it can't find dependency project-api. How can I set up maven such that when project-impl compiles, it first compiles and collects its dependencies on other projects?
you can only do that from the root project
mvn -pl child -am
this will build your sub project and also all dependencies in the same tree. in general, when you have a multi module project, you should always build from the parent, never from the child. And if you only want to build one or two child projects, do this:
mvn -pl child
OR
mvn -pl child2,child3
(projects child2 and child3 are build, but child1 and child4 aren't)
You need a dependency on api in the POM of the impl module.
When you compile on the toplevel project the reactor will figure out the right order to build things.
To separately build the project-impl you must first 'mvn install' the the project-api module or it will not find the right dependencies.
If you work in a team, an automated build server which pushes artifacts to a central repository can help to ease the pain here because this can drive you nuts.
This all works very well, however ot works the "maven" way, which is not always as we humans would do things.
Is there any way I can copy one pom.xml dependencies into other pom.xml
Update: Well, I have project A and Project B.
Project B is using some dependencies ( like Junit.jar, commons-httpclient, commons-collections, struts)
In the Project A : I would like to copy all project B dependencies in some out folder
This I can specify manually all dependencies jars of Project B in Project A but I would like to do automatically some script in Project A pom.xml.
Note: I don't want to build the project B in Project A pom.xml , I am building Project B separately
Does this make any sense?
If I understand well what you mean, keep only the dependencies in project B pom.xml. If you need something else in this pom, create another directory level B1, and push every other elements in it. Then makes B pom.xml a pom packaging with one module:B1.
Then you can make project B pom.xml the parent of project A pom.xml. A will inherit dependencies from B.
While I understand the spirit of the question (and only the spirit), the relation between project A and project B is still unclear so I'm not sure of the best way to implement this. Here are the options.
First solution: leverage transitive dependencies. There are some rules about them, but basically, if you declare a dependency on Project B in Project A, you'll get some of its dependencies transitively.
Second solution: use inheritance.
Third option: use another project of type pom to group the dependencies and declare a dependency on this pom.
I think the maven invoker plugin does pretty much exactly what you need:
http://maven.apache.org/plugins/maven-invoker-plugin/install-mojo.html
Or create a java class using the maven API, programmatically build a maven project and export the dependencies
start here:
http://maven.apache.org/ref/2.2.1/maven-project/apidocs
read a model:
http://maven.apache.org/ref/2.0.11/maven-model/apidocs/org/apache/maven/model/io/xpp3/MavenXpp3Reader.html
construct a MavenProject object using the model:
http://maven.apache.org/ref/2.2.1/maven-project/apidocs/org/apache/maven/project/MavenProject.html#MavenProject(org.apache.maven.model.Model%29
resolve and export the dependencies
Sean
We are planning on restructuring a complex project with many modules/pieces, what ever you wanna call it. In order to move toward a standard directory structure, we would like to adopt the maven file structure.
So the big question is: Can anybody provide a description of the maven file structure, where we don't have to dig through all the maven speak?
Please see
http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
src/main/java Application/Library sources
src/main/resources Application/Library resources
src/main/filters Resource filter files
src/main/assembly Assembly descriptors
src/main/config Configuration files
src/main/webapp Web application sources
src/test/java Test sources
src/test/resources Test resources
src/test/filters Test resource filter files
src/site Site
LICENSE.txt Project's license
README.txt Project's readme
BTW, we did that migration on existing projects.
It was a really long and hard task to make everything work as intended, but we are finally done and happy with it.
UPDATED
When you have many projects, you have the same structure for each project.
Now the real problem starts when you want to group them. We had a hard time reading Maven documentation and best-practices, and deciding what was the appropriate structure for us.
The basic idea would be to group related projects in a common directory (that we call a module), allowing to process the module as a whole without listing them. But if you open the module in an IDE (Eclipse in our case), the projects themselves belong to it, but are not opened as subprojects (that notion doesn't exist in Eclipse).
We ended up with a strict hierarchy, that freed us from many maven problems:
The actual coding projects (java projects) are always leaf in our directory tree. They are the only ones we open in the IDE. They are of type JAR, or WAR.
Their parents/modules are always of type POM. They have no java code.
I've been using the same approach as Jens on a number of projects both with Maven 2.2.1 and now with Maven 3.0-alpha-6: POM modules define the module structure of your project tree, JAR/WAR modules are the leaves of the tree. All modules have the same version.
Advantages:
You can
place properties or dependencies on
specific levels in the module
hierarchy and they will be inherited
to all sub-modules.
You can build
related modules simply by going to
the appropriate level in the tree and
running "mvn install" - Maven will
work out the correct build order
according.
Various Maven plugins such
as the release plugin rely on this
tree structure.
The latest Maven
Eclipse plugin can handle this
structure very well and will
represent the tree as a flat list.
There is an experimental feature in
the plugin which ensures that
so-called "shadowed" artifacts appear
only once which helps when searching
for resources in Eclipse.
Disadvantages:
Extension takes some time. For instance, if you decide that a JAR module requires sub-modules, you will need to convert the existing JAR module into a POM module and then distribute its contents to the newly created JAR sub-modules as POM modules cannot contain any code themselves.
All the POM modules will appear in Eclipse and can slow down the build somewhat. Hoever, you can close them and Eclipse will source them from the repository instead.