Maven Kicking the tyres without changing your project structure
So you're interested in kicking the maven tyres, so to speak, or just want to see what it's all about. The following provides hints on how to try maven with your current WebObjects projects, if say you're using the standard WOLips ant builds, without having to adopt a different file structure. Whilst this is not the recommended approach for the long term it allows you to try things out side-by-side with your current build system.
What's the aim
This might be stating the obvious, but an OO developer will, in the course of time (or is supposed to anyway), build up various encapsulated, reusable, libraries or frameworks that can be tapped into for differing projects. So let's assume we have multiple frameworks and applications in our build. Each of these has some common ground, such as their dependencies on certain WebObjects frameworks, or the file layout, and of course they each may have something distinctive about them.
The layout of the frameworks and applications might look like this:
Unknown macro: noformat. Click on this message for details.
Our aim is twofold:
- put as much configuration as possible that's shared between all frameworks, for example, into /frameworks/pom.xml so we only have to define it once. The configuration is inherited by a child pom.
- Be able to issue a single command that will package each and every framework and application.
Key Concepts
Typical things that make up a pom are as follows. (Note: only pom identification is mandatory. All the others have defaults.)
- pom identification (who am I?)
The base triplet used to identify an artifact (i.e., product)
Unknown macro: noformat. Click on this message for details. - pom packaging (i.e., what are we building?)
The default value for the packaging element is JAR if not specified. For the purposes of this exercise, we'll use JAR for the frameworks and woapplication for the applications, which requires the woproject maven plugin (TODO revisit this scenario with the apple maven plugin)
Unknown macro: noformat. Click on this message for details. - pom parent identification (who do I belong to?)
Unknown macro: noformat. Click on this message for details. - modules (a.k.a kids; who belongs to me?)
Unknown macro: noformat. Click on this message for details. - dependencies (what do I need?)
Unknown macro: noformat. Click on this message for details. - build sources/resources (what do I have?)
- properties and filtering resources (variable definitions)
- dependency/plugin management (shared configuration and versioning)
- repositories (where to find dependencies and plugins)
Of course, with the plethora of plugins available for maven, this is only the tip of the iceberg. However, these main concepts will suffice for now.
Alternate File System Layout Concepts
As you would (i.e., should) have read by now, Maven has what it calls standards. One such standard is the standard directory layout. One of the advantages of following the standards is that you get something for free: you have less to configure (or even almost nothing) in order to build a jar, for example, from your sources and resources. When that's not possible, options are available that allow you to subvert these standards or provide extra resouces.
The following roughly resembles the current WebObjects WOLips produced project layout (a.k.a Fluffy Bunny layout).
Unknown macro: noformat. Click on this message for details.
Assuming your building a framework, for example, the following is an extract from the relevant pom.xml. It specifies where to find your java source files and resources. Notice we've also defined the target path for each resource. (See the Maven Model#classresource for a definition of targetPath)
<...>
<build>
<sourceDirectory>Sources</sourceDirectory>
<testSourceDirectory>Tests</testSourceDirectory>
<resources>
<resource>
<targetPath>Resources</targetPath>
<filtering>false</filtering>
<directory>Components</directory>
</resource>
<resource>
<targetPath>Resources</targetPath>
<filtering>false</filtering>
<directory>Resources</directory>
</resource>
<resource>
<targetPath>WebServerResources</targetPath>
<filtering>false</filtering>
<directory>WebServerResources</directory>
</resource>
</resources>
<...>
</build>
<...>
So, concentrating on our frameworks alone for the moment, assuming all of your frameworks share the above project layout the above can happily go into your /frameworks/pom.xml file and as such be shared by all sub-modules (i.e., frameworks).
Project Dependencies Concepts
Most projects, of course, have dependencies on other libraries or frameworks.
Project Dependencies Prerequisites
details to come...
Packaging Frameworks as Jars
details to come...
Packaging Applications
details to come...
Project Inheritance
details to come...
Eclipse Integration
details to come...
Putting It All Together
details to come...