Maven newmbie here. Been looking over the docs at the official Maven site and am trying to understand the difference between a Maven archetype and the actual directory structure of a Maven-based project.
Does an archetype dictate the project directory structure, or are they two separate concepts? If they are different, then what sorts of things/behaviors does an archetype control?
Thanks in advance!
All archetypes should share the same basic project directory structure.
Some archetypes will add directories that are specific to the nature of the project you are creating (i.e. a J2EE archetype might have an additional WebContent folder, a flex archetype might generate a flex source directory, etc...).
Additionally, archetypes will generate a basic POM including the plugins you need.
A maven archetype is basically a reusable project template. Archetype can create a working Maven project with a proper directory structure and some sample code to get you up and running quick. There is number of archetypes available to create various projects. For example you can create a basic web aplication or web application with SEAM support for JBoss server, etc.
Related
I am in the process of designing a maven plugin that will pick up on a set of sql scripts contained within src/main/resources of a given project and then running them as part of a maven build.
Was just wondering if there is a standard way of using project resources within maven plugins or whether there is any examples that I can take a look at? I assume other plugins such as the maven-javadoc-plugin do something similar but I am not sure where to look
Currently I'm working on a Maven plugin that should generate files in all projects (OSGi bundles) that have a certain Eclipse project nature.
How can I access the contents of the projects included in the build and the project natures by using the Maven API?
Maven is a standalone build tool, not an Eclipse plugin. You cannot access Eclipse project settings from core Maven API.
Eclipse supports Maven with the M2E Eclipse plugin. It is possible to write M2E extensions and in the extension you can query the project natures via the functions of AbstractProjectConfigurator class.
However, M2E extensions will not run when you compile your code in the command line. I suggest that you choose one of the followings:
Write an Eclipse plugin that generates the source code into the src folder of the maven project. Code generation should be started by the user manually (selecting a context menu in the project or something).
Avoid using Eclipse project natures and solve your questions based on analyzing the source and pom of your project.
If you need to react on certain aspects in the source code like it looks from the thread with Balazs then you can simply write an ordinary maven plugin and include it in the parent pom. It will then run in every project and can analyze the code and react based on it.
I am new to Maven and using it to build a project on my local. This is working nicely on my local. Now, I want to run the same project on my server and the server does not have Maven installed. So I wanted to ask if there is any way by which, when I build a Maven project on my local, I could include all the required jars in it and then simply transfer it to my server? I know Maven creates the repository in C:\Documents and Settings\username\.m2 on Windows.
But how can I include all the jars in project the way we do traditionally? I saw this question. But it talks about creating a custom repository and I don't have Maven installed at all. so I guess it is not a suitable solution to me.
Thanks.
You can use the Maven Assembly Plugin. From the documentation:
The Assembly Plugin for Maven is primarily intended to allow users to aggregate the project output along with its dependencies, modules, site documentation, and other files into a single distributable archive.
Today, I've been looking at Maven Multi-Module and EAR projects and they seem quite similar in that both seem to define an assembly of a collection of other projects - it almost seems like an EAR project should just be an alternate packaging for a multi-module project.
Have I misunderstood something? Or do these types of project work together?
Following Pascal's answer:
Updated to clarify the question, hopefully that will help if it's not easy to understand; sorry it's maybe not phrased very well, the ear stuff is kinda new to me...
So say I have two projects, one producing a war and the other a utility jar. The war depends on the jar and I need to package them up into an ear for deployment. Should I use a project with a pom packaging type? I guess I have to use a project with an ear packaging type somewhere to produce the final artifact, so am I best using just a project with ear packaging, or projects with both pom and ear? If both, how?
EAR projects work just fine as part of a larger aggregated project. In those cases when you do not want to have the EAR be a separate project; you could always create the file via an assembly.
This approach makes sense in some cases. Usually where you have to create multiple versions of the EAR or when you would like to create the deploy a large EAR file but have no need to keep the artifact once created.
I've used this approach to deal with a corporate standard that requires all deployable to be EAR files, even when the app is a single WAR file. An assembly can create the EAR with its single WAR file and deployment descriptors.
Have I misunderstood something? Or do these types of project work together?
I'm not sure I understood the question but I'm tempted to answer that they work together:
Aggregating modules allow to, well, aggregate modules and they must have a pom packaging (and only pom modules can have nested projects).
An EAR module is just a module with an ear packaging (and has specific bindings) and can be part of a multi-module project.
Both have different purposes. But they work together.
Can I make a single maven project that can be included as a dependency (to reference Java classes inside) and executed as a plugin?
I'm working on a library to help with hosting GWT on a LAMP stack. For someone to use this, they need to extend some Java classes (so it must be a dependency) and they need to invoke a maven plugin (so it needs to be a plugin). The plugin code references the same Java classes, so if they are seperate projects, the plugin one must depend on the library one.
As is, I have the library as a normal maven project, and the plugin as a maven plugin that depends on the library. This means that to do a release, I have to release two different artifacts, and the dependent project must update both version numbers for both artifacts. It'd be nice to have a single project.
You'd be better of by doing the following
project for the jar, Foo:Foo.jar
project that uses Foo:Foo.jar as a
dependency that builds the plugin
Maven parent project that
builds 1&2
The directory structure would look like this
\project\pom.xml
\project\foo\pom.xml
\project\foo\src\main\java\foo.java
\project\plugin\pom.xml
\project\plugin\src\main\resources
\project\plugin\src\main\java
From \project you can do a mvn clean package to build \project\foo\target\foo.jar and \project\plugin\target\plugin.jar
Hope this helps.
If you create a maven plugin it still has a artifactId/groupId/version. There's no reason it can't be references both in your section and in your section. On the other hand, if thats ugly, why not just make a library with the common code that both your main project and your maven plugin project depend on?
EDIT:
Sorry, wasn't clear on the second part. Look into composite maven projects, where there is a top level pom that defines a number of child modules. In this case, the maven plugin and the common library code could be separate children producing separate artifacts, but you only need one version number and one release command executed from the top level. I haven't done this but there are any number of open source projects that do. its often used as an idiom to put testing code into a single module that can be referenced by all the others, without having it go out in any distributable jar.
The best practice is to not do what you're suggesting. Examples of this include PMD, BND, JUnit/TestNG, and so on - no serious projects seem to package the maven plugin with the library proper.
One way to get both alternatives is to use maven assemblies to have two seperate maven projects for each the library proper and the plugin and then a separate packaging as a jar containing the classes from both.