Code Modules with Maven 2

Each code module will produce a single artifact (war, ear, jar). Ideally artifacts that have an API and corresponding implementation can be separated into two separate artifacts: one code module will produce a jar with the API, the other code module produces the implementation.Artifacts will have a group identifier, artifact identifier, version, and packaging format. Generally the group identifier and version are fixed by the parent pom.

Modules reside in subdirectories of the base project. The module subdirectory does not need to be named the same as the artifact identifier, but by convention they are the same.

In the base pom.xml, modules are defined like so:

<project>
  ...
  <modules>
    <module>context-common-api</module>
    <module>portal-caching-api</module>
    ... 
  </modules>
  ...
</project>

By listing a module in the <modules> element, the Maven 2 lifecycle will be activated for that module when running maven 2 commands from the base directory. For example, running mvn compile from the base directory will compile the source code in any module with package type of jar.

Goals of modularization

Define explicit dependencies between distinct "chunks" of code, especially framework code.
Separate API from Implementation
- Allow for vendors, etc to plug in their own implementations of an API
- Well defined API's with loose coupling promotes easier-to-maintain code

So when considering the question what constitutes a module, I consider:

What is the responsibility of the code in question? Code with distinct responsibility should be given its own module (imo).
- If you can't tell what the responsibility of the code is, or mostly everything fits but for this one class, consider refactoring.
Is it an API, or an implementation
Will a vendor ever want to replace the impl with their own?

Module List for Maven 2 Trunk

Often times code modules can be derived from the Java package hierarchy. What I did to arrive at this list was look at the existing uPortal 3 package structure and started by creating a code module for each major package (note that the 'code moduel per package' rule is not a documented M2 convention, I just made it up).

This is a list of modules that I came up with, sometimes following the 'code module per package' rule and sometimes not. These modules can be seen in the Maven 2 Branch (note that this branch was a first-run exercise at mavenizing uP3. While it won't ever get promoted to trunk it still has some value as a sandbox).

Pre Pluto 1.1.x integration

Note that this work on the Maven 2 branch took place prior to the work Eric did on replacing Pluto 1.0.x with Pluto 1.1.x. Since the Pluto 1.0.x OM was very invasive, I imagine that with Pluto 1.1 some of these modules will be able to have a much cleaner dependency graph.

Module sub-directory	Artifact Identifier	Packaging Format	Notes
context-common-api	context-commmon-api	jar	I had trouble divvying up the context code modules, but I think each deserves its own.
context-common-impl	context-common-impl	jar	Common context implementation.
pluto-stubs	pluto-stubs	jar	Stubs of Pluto 1.0.x interfaces
portal-caching-api	portal-caching-api	jar
portal-caching-impl	portal-caching-impl	jar	Caching API implementation.
portal-core-api	portal-core-api	jar	I moved some servlets out of the core module to the web module.
portal-core-api	portal-core-impl	jar
portal-context-api	portal-context-api	jar
portal-context-impl	portal-context-impl	jar
portal-context-dummy	portal-context-dummy	jar
portal-context-uportal2	portal-context-uportal2	jar
portal-rendering-api	portal-rendering-api	jar
portal-rendering-impl	portal-rendering-impl	jar
portal-servlet	portal-servlet	jar	Not sure what is up with this one, need to revisit
portal-url-api	portal-url-api	jar	Because url munging is now a first class citizen in uP3, I think this deserves its own module
portal-url-impl	portal-url-impl	jar
problem-manager-api	problem-manager-api	jar
problem-manager-impl	problem-manager-impl	jar
security-api	security-api	jar
security-impl	security-impl	jar

Browser not supported