I have a base project named : ParentProject that contains all common businesses needed for children.
I also have 2 children Child1Project and Child2Project those project inherit all businesses of the ParentProject.
In the future, I may have Child3Project, Child4Project, so on.
So what should I do to organize those project in MULE ESB 3.7?
Many thanks.
One way to do this will be to make sure all your projects use Maven as build tool. Now, while creating the POM for the parent project, make sure it's packaging is "jar". Now, whenever you want too add this parent project properties to your child project, you'll just need to import the jar to the child project, or the repository configuration of the parent project in the POM of the child project.
Related
I use a project layout like the first one described in the accepted answer to this question. If my parent-pom is managed, built and deployed separate from my project POMs, how can I ensure the pluginManagement section of my parent-pom is valid?
Maven only checks plugins that actually get used in the build as far as I can tell. Since most of the plugins I'm declaring in pluginManagement don't get used when I build the parent-pom, I have no way of knowing if I have an invalid entry until a child project tries to use a plugin it expects to be managed by the parent-pom.
I've tried the versions plugin, but it seems to ignore plugins that don't exist (ex: typos). I've tried declaring the plugins in my parent-pom with inherited=false, but then I have to tie every declared plugin to a phase. Plus, I don't necessarily want to run those plugins against my parent-pom.
I know lots of people use a parent-pom or a super-pom of some type, so there has to be something I'm overlooking.
In your parent pom module create a set of test maven projects, all inheriting parent pom, using some or all of the plugins defined there, and have parent pom run and verify build success of test maven projects. maven-invoker-plugin can help you in accomplishing all this. This plugin is used a lot for testing maven core plugins so you can find more usage examples in sources of maven core plugins.
Another advice is to add plugins to parent pom pluginManagement only when you need them, then you will have opportunity to test it as well. So steps are, start building a project which uses a given plugin not yet present in parent pom, add plugin to parent pom, release parent pom snapshot, make use of that snapshot in new project, if all OK release parent pom, and adjust reference to parent pom in new project. Later for another or same project if you need additional plugin or newer version of plugin already specified in parent pom, adjust parent pom, release new parent pom snapshot, check if it works for the given project, and if it does release parent pom, and adjust parent reference to newly released parent pom.
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.
I am sitting with a problem on how to structor a maven project.
This is the structur on the project
So I am able to build every project like bbbbb/pom.xml and so on. Fx the bbbb/pom.xml has a parent that is in aaaaaa/parent/pom.xml. Then this has a parent in the root. But if I now want to build them all and add them all to a package how is that done?
Usual structure for nested maven projects would be:
/parent
pom.xml
/sub1
pom.xml
/sub2
pom.xml
...
Each pom in subX prohect references parent and parent pom lists SubX as modules. This way you should be able to build each subX project individually as well as everything from parent.
Not clear what you mean by 'add them all to a package'? Generally in maven there is 'one artifact per project' - so if you need say EAR you would create another subproject under same parent with packaging=ear. If you need 'all in one jar' you could look at maven-assembly-plugin, again in separate subproject perhaps.
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
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.