Question

Eclipse has a nice feature I'm using - check out maven projects from SCM - which takes the parent pom of a multi-module project, checks it out, and then checks out all of its modules to the local workstation. It's very easy to use, and very clean. Awesome to use with a team. It stores the projects in hierarchical fashion (which I like) ... e.g. - the parent pom is the root, and all of the modules are in folders within the parent.

However, now I am going to be adding another element - an organization-wide POM for settings which rarely change. The only thing I'm confused about, is how this is going to alter my structure for other (unrelated) projects which all use the organization-wide pom. I do not want to list other superpoms as "modules" of the company parent, I just want it to be very simple.

Is there any way I can get my multi-module parent projects (the one with POM packaging) to be actually be a module of the organization-wide pom, without having three levels of folders in each project? For example, can I store that pom in my archiva repository, so it could be resolved using dependencies (as opposed to actually having the file at the root of my projects)?

Would I need to alter my projects from a hierarchical structure to a flat structure (all modules in same directory as parent) to make this work, if I actually had to have the organization-wide pom as the root of each multi-module project I have at my company?

How do people who work for organizations which use this structure, generally store and check out these projects? What am I missing here? The multi-module project (without the parent pom) is so clean and usable. Adding another layer (the super super pom) is really confusing the crap out of me!

Thanks!

Was it helpful?

Solution

You do not need to list modules in the organisations pom to be able to link to it as a parent POM and have it inherit common settings. If you store the organisations POM in archiva, or Nexus or Artifactory etc., then you just need to point to the repository in either your settings.xml or inside of the pom.xml files for each project. You do not need to add a dependency on the organisations POM file, as the parent element will organise that for you.

Have you tried putting an empty path in for the parent pom link:

<relativePath></relativePath>

That should make maven look for the parent pom in a repository and not on the file system.

OTHER TIPS

The organization pom (i would call it a company pom) should be handles as an usual maven artifact which means it must be in VCS and of course it's needs to be released via the maven release plugin. Furthermore a company should have only a single release repository and one for SNAPSHOTs. The company pom should have it's own repository, cause it's identified by groupId, artifactId and version so i can simply be put into the release repository and references as parent from different projects by it GAV coordinates (groupId, artifactId, version). The relativePath should usually not needed. A multimodule build should work withtout a relative path (be aware of the "Convention over Configuration" paradigm).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top