That Java Thing, Part 14: Maven Environment Setup

Sun Feb 21 17:51:37 EST 2016

Tags: java maven
  1. Nov 02 2015 - That Java Thing, Part 1: The Java Problem in the Community
  2. Nov 03 2015 - That Java Thing, Part 2: Intro to OSGi
  3. Nov 04 2015 - That Java Thing, Part 3: Eclipse Prep
  4. Nov 05 2015 - That Java Thing, Part 4: Creating the Plugin
  5. Nov 06 2015 - That Java Thing, Part 5: Expanding the Plugin
  6. Nov 08 2015 - That Java Thing, Part 6: Creating the Feature and Update Site
  7. Nov 09 2015 - That Java Thing, Part 7: Adding a Managed Bean to the Plugin
  8. Nov 10 2015 - That Java Thing, Part 8: Source Bundles
  9. Nov 11 2015 - That Java Thing, Part 9: Expanding the Plugin - Jars
  10. Nov 12 2015 - That Java Thing, Part 10: Expanding the Plugin - Serving Resources
  11. Nov 16 2015 - That Java Thing, Interlude: Effective Java
  12. Dec 01 2015 - That Java Thing, Part 11: Diagnostics
  13. Dec 03 2015 - That Java Thing, Part 12: Expanding the Plugin - JAX-RS
  14. Feb 19 2016 - That Java Thing, Part 13: Introduction to Maven
  15. Feb 21 2016 - That Java Thing, Part 14: Maven Environment Setup
  16. Feb 22 2016 - That Java Thing, Part 15: Converting the Projects
  17. Feb 23 2016 - That Java Thing, Part 16: Maven Fallout
  18. Feb 26 2017 - That Java Thing, Part 17: My Current XPages Plug-in Dev Environment

Before diving into the task of converting our plugin projects to Maven, there's a bit of setup we need to do. In a basic case, Maven doesn't require much setup beyond the project file itself - it's a "convention over configuration" type of thing that tries to make doing things the default way smooth. However, since it's also a "Java" thing, that means that anything out of the ordinary requires a bunch of XML.

Our big "out of the ordinary" aspect is OSGi. Maven and OSGi are often at loggerheads, but the conflict won't be too great in our situation. Still, it does mean there will be a few hoops to jump through, and one of those hoops is dealing with our dependency on the XPages runtime plugins. Since these plugins are not packaged as fully-Mavenized artifacts (yet (hopefully)), we'll need to configure Tycho to read the p2 (Eclipse) style.

In part 3, we downloaded the Build Management Update Site from OpenNTF, and we'll reuse that here. What we need to do is create a global Maven settings file that, for now, will just contain a definition of a variable to point to this update site. It would also be possible to specify this inside the project itself, but it's better form to use a consistent variable name (the most common convention is notes-platform) in the project files and then have your local settings point to it on your machine.

The global Maven settings file is called settings.xml and is stored in a folder named .m2 in your user's home directory (e.g. C:\Users\someuser\.m2 or /Users/someuser/.m2). Creating a folder named with a leading dot can be a pain in Explorer and the Finder, so it may be necessary to drop into a command line or other tool to do it. One way or another, create this file and set its contents similar to this:

<?xml version="1.0"?>
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
	<profiles>
		<profile>
			<id>main</id>
			<properties>
				<notes-platform>file:///C:/IBM/UpdateSite</notes-platform>
			</properties>
		</profile>
	</profiles>
	<activeProfiles>
		<activeProfile>main</activeProfile>
	</activeProfiles>
</settings>

Adjust the file:// URL as necessary to point to the location on your computer. It has to be a file URL and not a normal path, presumably because repositories are usually expected to be remote HTTP sites.

This is the only configuration we need before getting to the project, but it's a good preview of the sort of "try pasting this big block of XML somewhere" advice you're in for when it comes to Maven use. Over time, the structure of the XML and how it relates to Maven's behavior begins to crystallize, but it's definitely cumbersome to start with, and it will get more opaque before it gets less so.

Depending on your proclivities, this may be a good opportunity to install standalone Maven as well. Eclipse has its own embedded version, so this is not required, but it can be handy sometimes to be able to run Maven from the command line. On your average Linux distribution or OS X with Homebrew, Maven should be installable with a package manager. Otherwise, Maven can be downloaded from maven.apache.org - it doesn't have an installer as such, as it's essentially some scripts around Java classes, but they have tips for adding it to your path.

Next, we'll get to the real meat of this process: actually converting the projects to Maven.

New Comment