When creating a project with the webapp archetype in Maven, they subtly advise not putting any Java source in the webapp project by not including the "src/main/java" folder.
What do you name your Maven projects?
project-webapp for the project that contains the JSP, CSS, Images, etc.
project for the project that contains domain specific entities
? for the project that contains the web application files like Servlets, Listeners, etc.
My first inclination would be to use "webapp" for the project containing the web application files (Servlets/Listeners), however the archetype uses "webapp" to convey the JSP/CSS/Images project and would cause confusion to other developers.
When creating a project with the webapp archetype in Maven, they subtly advise not putting any Java source in the webapp project by not including the "src/main/java" folder.
That's not really true. When you create a project with the maven-archetype-quickstart, you don't get a src/main/resources directory. Would that mean you should not put resources in this project? No.
What do you name your Maven projects?
There is no general rules, nor conventions. Use something that makes sense for your organization and your team. But as I said above, your initial assumption is not true and putting Java code inside a maven war module is a common practice (except for code you want to share between modules).
Not sure if this below link directly answers your question, but it makes sense to refer it
Refer their JIRA task here Document the naming convention for archetypes
As per this, the naming convention can be as below
The Artifact id of the archetype should be of the format -archetype-
Ex: + maven-archetype-quickstart : Which indicates the archetype is from maven and the project is a quick start
Same way you scala-archetype-simple : Which indicates it is from scala and is a simple scala project
Best of luck
Related
When Functional testing Mule xml configurations, what is the best practice/conventions for naming test packages?
If testing standard Java, usually I use the same package name as the code under test i.e:
src/main/java
com.mycomapany.MyClass
src/test/java
com.mycompany.MyClassTest
But with mule xml files they are always just in src/main/app
i.e src/main/app/MyMuleFlow.xml
And tests are in src/test/java
So there is no simple correlation. What are the standard conventions for this?
As for the code location, you can add: custom source code in src/main/java and custom resources in src/main/resources.
i.e. Mule projects follow the standard Maven project layout, with the addition of src/main/app for Mule configuration files. Therefore you shouldn't feel any difference from your standard Java projects.
As for the package names, there's absolutely no constraint for Mule: do whatever you do in your standard Java projects.
I'm new to Maven and have skimmed over the documentation as I am following the Hibernate tutorial at http://docs.jboss.org/hibernate/stable/core/reference/en/html_single/#tutorial-firstapp-mvn.
I have installed Maven and successfully setup a web-app but this does not contain all of the standard directories mentioned in the tutorial. Am I going mad?
When building my Maven project I am using the maven-archetype-webapp. This gives me the arh-webapp\src\main\resources and arh-webapp\src\main\webapp directories but I'm missing quite a few directories mentioned on the link http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html.
Surely I don't have to manually add these? If not then the Hibernate documentation does not mention what archetype to use in order to achieve the directory structure used in their tutorial. Please can someone enlighten me.
What archetype do I need to use in order to have the above directory plus the src/main/java directory? If there is no such archetype then can easily append these using Maven? and how?
Surely you'll have to manually add these.
Just create those directories that according to the Maven convention are missing. Remember, a Maven Archetype is just a starting point to save you time configuring your workspace. After encountering many problems in some Archetypes myself I've been accustomed to just use a basic-web-app-archetype and then customize it myself, as a beginner with Maven you'll be better off doing that, and will learn a lot.
Regards.
Not all the directories mentioned are required for your standard web application. In fact, the reason behind the presence of the src/main/java, src/main/resources and the src/main/webapp directories is due to the archetype that you've used.
IMHO, the book titled "Better Builds with Maven" will serve you better; the Sonatype books on Maven might also help. The complete Maven documentation is also available as a PDF file, for future reference.
But just in case, you need some clarity on the terms used, here's some:
Archetype: A pattern for projects. Simple web applications (with no dependencies on other frameworks/libraries) have their own archetypes, so do applications using Spring, Hibernate, Seam, etc. Some archetypes will result in creation of different directories, as they are coded that way. You might be able to change the directory structures in most cases, although I cannot vouch for every archetype. For instance, it is quite possible to place your sources in 'src' instead of 'src/main/java', although this requires additional configuration in the POM.
Lifecycles, Phases and Goals: A Maven build lifecycle is a series of phases, with each phase executing a set of goals. Maven can be commanded to execute a build phase, which results in execution of all phases until and including the specified phase.
Maven plugins: Maven plugins contain one or more goals. Goals need not be bound to phases, but usually you would bind them to particular phases. Plugins are the basis for everything operational in Maven; you're using plugins even though you are just compiling the application (the Maven compiler plugin is a core plugin that is present in the Maven distribution).
I hope the above helps, but I would suggest that the reference books be followed.
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.
I have following Maven projects set up:
PM-Core
PM-Web (with a dependency to PM-Core)
Now, this project is used for several clients but for each client there are some small differences: mostly differences in configuration files but some clients also require additional java files (which may not be installed for the other clients).
I've been considering several alternatives on how to support this with maven but am still looking for the perfect solution.
The best solution I can think of is to create a separate maven project for each client (e.g. PM-CLIENT1, ...) which contains only the client specific configuration files and additional java files or jsp's, ... . Next step would be to consider the PM-Web project and the client project as one web project, meaning: have them combined (packaged) into 1 war file with files from the client project having precedence over files from the PM-Web project.
More concrete: running mvn package on PM-Client1 would take everything from PM-Web, add/replace the files from PM-Client1 and then package this into a single war.
So the question is: how to achieve this with maven?
Yes, this can be done using Overlays. The sample on the webpage is exactly what you are talking about.
For the project structure, you could have something like this:
.
|-- PM-Core
|-- PM-WebCommon (of type war, depends on core)
|-- PM-Client1 (of type war, depends on webcommon)
`-- PM-Client2 (of type war, depends on webcommon)
And use overlay in PM-Client1 and PM-Client2 to "merge" them with PM-WebCommon and package wars for each client.
UPDATE I won't cover all the details but I think that declaring the war dependency with a scope of type runtime is required when using overlay, this is how overlay do work (actually, the whole overlay thing is a kind of hack). Now, to solve your eclipse issue, one solution would be to create a JAR containing the classes of the PM-WebCommon project. To do so, use the attachClasses optional parameter and set it to true. This will tell maven to create a PM-WebCommon-<version>-classes.jar that you'll then be able to declare as dependency in PM-Client1 (with a provided scope). For the details, have a look at MWAR-73 and MWAR-131. This is also discussed in the FAQ of the war plugin. Note that this is not a recommended practice, the right way would be to move the classes to a separate module (and this is the other solution I wanted to mention).
UPDATE (201001018): I've tried the attachClasses parameter and it works with version 2.1-beta-1 of the plugin.
You could use profiles see http://maven.apache.org/guides/mini/guide-building-for-different-environments.html and use classifiers to distinguish between the artifacts from the different builds for the same version.
In this setup, you could create additional optional modules for each of your clients specific customisations under the parent project i.e.
+ PM
++ PM-Core
++ PM-Web
++ PM-Client1
++ PM-Client2
Or you could look at using use the maven assembly plugin
Compare also the answers for question different WAR files, shared resources .
I have this scenarion in my project:
Maven2 for dependency management
One project 'common-web' (war) contains all images, css files, js files, layout files etc. It also contains custom tags (*.tagx files) that we use in our project. They are located in WEB-INF\tags direcotry.
Second project (also war) has dependency on common-web, we use those custom tags in our *.jsp files by importing them in this way:
<%# taglib prefix="custom" tagdir="/WEB-INF/tags" %>
This works great in runtime, but is a big problem during development, because NetBeans does not see those custom tags and does not give me Intellisence.
In Eclipse I managed to work around this issue by linking tags directory in this second project. Can I do something similar in NetBeans? Or is there any better way to work around this issue?
I'm no NetBeans export so apologies if this makes no sense, but I understand from this article that it will discover taglibs in referenced jars.
Would it be possible to move the shared tags into a jar and reference it in both wars instead of trying to have one war reference another? If the taglibs jar project is deployed to the Maven repository it would be managed by Maven and available to both projects.