I have a multi-module maven project, and I'm trying to create an assembly for the project. The assembly should be a zip file, including all of the jars from the dependent projects as well as all of the resources from those projects (this is for legacy support reasons - I know this isn't a good practice, but in this case, we really can't do much about it).
I have an assembly that builds a zip and includes the contents of the build output directory (which will get the resources). If I run that from the parent pom, it doesn't actually build a zip (presumably because the parent project is of type pom, not a jar). If I run an assembly from one of the individual projects, it does include the jars and all the dependencies (I specified including the dependencies). It includes the output directory for that project, but not the child projects.
Do I need to do something like run an assembly from the parent that iterates over the child projects and runs their assemblies (the assemblies for each of the child projects would be the same though - it would include the jar, the dependencies and the output directory)? I'm not even sure this is possible ... any guidance would be appreciated.
I suggest to check the whole Section 8. Maven Assemblies of the Maven: The Complete Reference book and in particular the following subsection 8.2.4. Assembling Assemblies via Assembly Dependencies. It describes a very similar requirement and a setup.
Related
In fact I have 2 different problems, but I think they are kind of related:
I have an artifact, with an assembly descriptor set which will build an extra JAR (with extra classifier). By default, Maven2/3 will deploy the assembly generated together with the main artifact to remove Maven repository. Is there any way that I can deploy only the main artifact but not the assembly?
I have an artifact, in which I have jar plugin generate another artifact with different classifier (more specific, an EJB artifact, and I generate an client JAR). I want to deploy only the client JAR to Maven repo coz I think the main EJB artifact is not really going to be shared by other project. Is it possible to do so?
Thanks a lot
editied to provide more info:
The reason for avoiding deploy the EJB, is because the EJB main artifact is not going to be depended by other project except the containing project. The containing project will build a EAR (which contains the EJB), and normally we only need that build locally (by mvn package). However, the EJB client is something that we will deploy to our repo to let other project share when they need to communicate with our application.
Honestly it doesn't harm to deploy the EJB too, but I just want to see if I can save unnecessary waste of disk space on our repository.
Similarly, for deploying assembly, it is because the project is something we want to deploy to let other project to depends on. However, when building that project, we also have a separate assembly created on the same time (for example, an all-in-one executable jar) which we only need that built locally, and it is not something that other projects will depends on.
Turn off the 'attach' option to the assembly plugin. Then it won't be officially an artifact and it won't deploy; it will just lurk in the target directory, sulking that you don't love it as much as it's elder sibling and plot revenge.
Based on your first question i would like to know why do you create the supplemental assembly which is usually deployed as well as the main artifact. If you wan't to prevent you can put the creation of the assembly into a profile but this means you will not generate the supplemental artifact in your usual build only by activating the profile.
In Maven, is it possible to link additional dependent java src from outside the project folders, so that when we build our main package, maven may include such classes into final jar?
just as we can link any source folder to our project in Eclipse and eclipse treats it as regular project source?
In Maven, is it possible to link additional dependent java src from outside the project folders
Technically, it's possible to add source folders to a build and this is usually done using the build-helper-maven-plugin. However, I would recommend against doing so for directories outside a given module, a maven module should be self contained.
Im trying to setup maven to assemble all my build artifacts into a central distribution folder. to help with explainations, ive uploaded a sample project here
This is a simple multi-module project with 2 j2ee components, each of those has a war, and ear sub-project. If you comment out the assembly plugin in the top level pom, everything will build fine.
There is also an outputFolder which is how i want things to look when the assembling is all done. Also in the outputFolder are misc jar files that will come from other sub-projects that just build a single jar (currently we have about 20 of these application jars). Now since all the j2ee projects have the same directory structure and resulting distribution formats, I wanted to create a common assembly descriptor to be re-used across all of our j2ee components (currently theres about 15).
What I have so far does not work - in that it wont find the binary artifacts from any of the subprojects. Ive tried using moduleSet and dependencySet sections in the assembly descriptor, but those dont seem to work either, i alwasy get something like: The following patterns were never triggered in this artifact inclusion filter: 'myCompany:j2ee_A_ear:ear'
Or if I try to put an assembly descriptor in the top level project, it causes wierd dependency errors when packaging my ear files.
Ive tried to use the dependency-copy plugin, but that seems to cause more problems than it solves. Also others have said, the dependency plugin is the way to go for this. Ive tried creating packaging only projects -- a sibling of the j2ee_A and j2ee_B projects in my example, but it cant seem to find any of the modules or dependencies
So im looking for an assembly descriptor (or descriptor s) that will be:
a) reusable across any number of j2ee sub-projects
b) also support single jar files
c) copy everything to a single folder
Ideas, suggestions and examples are welcome.
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.
My project generates 3/4 assemblies, 3 jars and 1 war.[I need to use assemblies itself]
I need to include 2 of these assembly jars into my war.
How can I ensure that before assembly war creation , other 2 jars are created ?
Please respond
You have three choices:
define all the assembly executions in one plugin configuration, and order them as needed.
See this answer for more details.
Define an earlier phase for your jar assemblies so that they have all been packaged before the war is packaged.
Move the jar content into separate projects and specify them as dependencies of the war project so they are packaged automatically. This is the "Maven way" of handling this. It would also allow you to potentially reuse the jars in other wars.
I'd recommend option 3 myself, but the other two should both work.