I have a project which has multiple small utility classes which I want to package as separate jars, e.g. json-utils, xml-utils etc.
How can I manage this kind of build within a larger project?
Is the only way to do this by declaring each of these classes within a their own separate module? And does each one then need its own subfolder?
One of the basic concepts of Maven is one project (module), one artifact (jar, war, etc.):
Because a project is defined by a unique set of coordinates consisting of a group identifier, an artifact identifier, and a version [...]
So, "yes" to your last two questions.
Related
Under a common parent I have three Maven projects that are loosely related, and I must add the jars that all of these projects generate and their dependencies to a third party ear. For each of those three projects I have properly configurate de dependency:copy-dependencies goal.
In order to have things as automated as possible, I want to join all the jars in a single location.
An initial idea would be using an empty "joiner" project that depends on all of the previous three projects, and just use dependency:copy-dependencies on it. But I do not really like the idea of an empty project with its empty artifact, and I am wondering if there is a more standard way of doing this (ideally by copying the dependencies in a directory of the parent that does not need to be commited to version control) with the standard plugins.
I need to create a Spring MVC web application where each of the services should be created as a separate JAR file. Some of the docs suggest that multiple Maven modules can be used for this. But what I understood is, that each module also needs to be created as a separate Eclipse project.
Can I have all the controllers, service and DAOs in the same Eclipse project, while still creating separate jars for each service (and a war file for the whole application) with Maven?
Short answer:
Yes, you could create multiple build targets (jar files) out of single project by using maven-jar-plugin (profiles, executions).
https://maven.apache.org/plugins/maven-jar-plugin/
Should you do it?
I believe most people will agree with me that you should not do it, you should stick to one of the most important core concepts of Maven: modularity.
Now, Have you asked yourself the question, Do I really need to create multiple modules (jar Files) for my application? Can I manage all pieces of code in one single project?
Maybe you just need some guidance about how to organize your java packages in one single project.
https://dzone.com/articles/layered-architecture-is-good - Using layered architecture
http://www.javapractices.com/topic/TopicAction.do?Id=205 - Packages by feature vs Layers
NOTE: If you think that your project will grow fast and the number of classes will be a large number, it is probably a good candidate to be a multi module application.
If you still have the feeling that you have to create multiple modules, there are several interesting posts about how to address modularity in the design of applications, in these posts they provide very interesting reasons/criteria why you should split your application into modules.
How to decompose a system into modules?
Spring Java Maven Project + Module Design
Good Luck!
What is the problem of separate modules and hence separate Eclipse projects? If you declare a Maven dependency between the modules, you'll be able to have compile dependencies between the classes in the corresponding Eclipse projects.
So I suppose that it is possible to force multiple Maven modules into one Eclipse project, but I don't know any good reason to do so.
Very new to Maven, can someone please explain to me the difference between using maven modules vs just adding a dependency to your maven project to another maven project in your workspace? When would you use one over the other?
A dependency is a pre-built entity. You get the artifact for that dependency from Maven Central (or Nexus or the like.) It is common to use dependencies for code that belongs to other teams or projects. For example, suppose you need a CSV library in Android. You'd pull it as a dependency.
A Maven module gets built just like your project does. It is common to use Maven modules for components that the project owns. For example, maybe your project creates three jar files.
A dependency can be thought of as a lib/jar (aka Artifact in Maven parlance) that you need to use for building and/or running your code.
This artifact can either be built by your one of the modules of your multi module project or a third party pre-build library (for example log4j).
One of the concepts of maven is that each module is going to output a single artifact (say a jar). So in case of a complex project it is good idea to split your project to multiple modules. And these modules can be dependent on each other via declared dependencies.
See http://books.sonatype.com/mvnex-book/reference/multimodule-sect-intro.html for example of how a web app is split to parent and child modules and how they are linked.
One of the most confusing aspects of Maven is the fact that the parent pom can act as both a parent and as an aggregator.
99% of the functionality you think about in Maven is the parent pom aspect, where you inherit things like repositories, plugins, and most importantly, dependencies.
Dependencies are hard, tangible relationships between your libs that are evaluated during each build. If you think of your software as a meal, it's basically saying A requires ingredient B.
So let's say you're preparing lasagne. Then your dependency chain would look something like this:
lasagne
<- meatSauce
<- groundBeef
<- tomatoPaste
<- cheese
<- noodles
The key thing is, each of the above items (meatSause, groundBeef, cheese, etc) are individual builds that have their individual set of dependencies.
By contrast, the only section of your pom that pertains to aggregation is the modules section:
<modules>
<module>meatSauce</module>
<module>groundBeef</module>
<module>tomatoPaste</module>
<module>cheese</module>
<module>noodles</module>
</modules>
Aggregation simply tells your build engine that it should run these 5 builds in rapid succession:
groundBeef -> tomatoPaste -> cheese -> noodles -> meatSauce
The main benefit of aggregation is the convenience (just click build once) and ensuring the builds are in the correct order (e.g. you wouldn't want to build meatSauce before tomatoPaste).
Here's the thing though: even if you organize the libs as standalone projects without module aggregation, your build will still come out the same provided you build in the correct order.
Moreover, both Jenkins and Eclipse have mechanisms for triggering builds if a dependent project has changed (e.g. changing groundBeef will automatically trigger meatSauce).
Therefore if you're building out of Jenkins or Eclipse, there is no need for aggregation
I've following scenario:
ProjectA have two dependencies depA and dep2
I want to create two builds one with both dependencies and another one just have one dependency.
Now, my question is:
How can I achieve custom builds?
Can I create simply two POM files? If yes, then how should I be building projects using specific POM?
There are two ways you could create multiple output packages. One is to use the maven assembly plugin to create multiple archives. The other is to create a multi-module project and give each artifact it's own pom.xml. I would recommend the latter case as it embeds less assembly logic in your pom. In this case I would create at least three modules... one for the project artifact with no packaged dependencies and two others for that artifact plus the various dependency items.
I want to create maven multi module project, but it should not like normal module project. My requirement is divide web project in to many parts and some module contents common pages, when building project it need to create many web war files.
Is there any maven plugin for this kind of requirement?
Thank You.
Depending on how many war files you need to create, you can use overlays to merge in common pages. This would work if it's ok to have one module per war.
Otherwise, I suggest using different profiles to create each different war. Then you would run the build once per war.