consortium-settings.xml

<?xml version="1.0" encoding="UTF-8"?>

<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">
	
	<pluginGroups>
		<!-- pluginGroup | Specifies a further group identifier to use for plugin 
			lookup. <pluginGroup>com.your.plugins</pluginGroup> -->
	</pluginGroups>

	<!-- proxies | This is a list of proxies which can be used on this machine 
		to connect to the network. | Unless otherwise specified (by system property 
		or command-line switch), the first proxy | specification in this list marked 
		as active will be used. | -->
	<proxies>
		<!-- proxy | Specification for one proxy, to be used in connecting to the 
			network. | <proxy> <id>optional</id> <active>true</active> <protocol>http</protocol> 
			<username>proxyuser</username> <password>proxypass</password> <host>proxy.host.net</host> 
			<port>80</port> <nonProxyHosts>local.net|some.host.com</nonProxyHosts> </proxy> -->
	</proxies>

	<!-- servers | This is a list of authentication profiles, keyed by the server-id 
		used within the system. | Authentication profiles can be used whenever maven 
		must make a connection to a remote server. | -->
	<servers>
		<!-- server | Specifies the authentication information to use when connecting 
			to a particular server, identified by | a unique name within the system (referred 
			to by the 'id' attribute below). | | NOTE: You should either specify username/password 
			OR privateKey/passphrase, since these pairings are | used together. | <server> 
			<id>deploymentRepo</id> <username>repouser</username> <password>repopwd</password> 
			</server> -->

	</servers>

	<!-- mirrors | This is a list of mirrors to be used in downloading artifacts 
		from remote repositories. | | It works like this: a POM may declare a repository 
		to use in resolving certain artifacts. | However, this repository may have 
		problems with heavy traffic at times, so people have mirrored | it to several 
		places. | | That repository definition will have a unique id, so we can create 
		a mirror reference for that | repository, to be used as an alternate download 
		site. The mirror site will be the preferred | server for that repository. 
		| -->
	<mirrors>
		<!-- mirror | Specifies a repository mirror site to use instead of a given 
			repository. The repository that | this mirror serves has an ID that matches 
			the mirrorOf element of this mirror. IDs are used | for inheritance and direct 
			lookup purposes, and must be unique across the set of mirrors. | <mirror> 
			<id>mirrorId</id> <mirrorOf>repositoryId</mirrorOf> <name>Human Readable 
			Name for this Mirror.</name> <url>http://my.repository.com/repo/path</url> 
			</mirror> -->
	</mirrors>

	<!-- profiles | This is a list of profiles which can be activated in a variety 
		of ways, and which can modify | the build process. Profiles provided in the 
		settings.xml are intended to provide local machine- | specific paths and 
		repository locations which allow the build to work in the local environment. 
		| | For example, if you have an integration testing plugin - like cactus 
		- that needs to know where | your Tomcat instance is installed, you can provide 
		a variable here such that the variable is | dereferenced during the build 
		process to configure the cactus plugin. | | As noted above, profiles can 
		be activated in a variety of ways. One way - the activeProfiles | section 
		of this document (settings.xml) - will be discussed later. Another way essentially 
		| relies on the detection of a system property, either matching a particular 
		value for the property, | or merely testing its existence. Profiles can also 
		be activated by JDK version prefix, where a | value of '1.4' might activate 
		a profile when the build is executed on a JDK version of '1.4.2_07'. | Finally, 
		the list of active profiles can be specified directly from the command line. 
		| | NOTE: For profiles defined in the settings.xml, you are restricted to 
		specifying only artifact | repositories, plugin repositories, and free-form 
		properties to be used as configuration | variables for plugins in the POM. 
		| | -->
	<profiles>
		<!-- profile | Specifies a set of introductions to the build process, to 
			be activated using one or more of the | mechanisms described above. For inheritance 
			purposes, and to activate profiles via <activatedProfiles/> | or the command 
			line, profiles have to have an ID that is unique. | | An encouraged best 
			practice for profile identification is to use a consistent naming convention 
			| for profiles, such as 'env-dev', 'env-test', 'env-production', 'user-jdcasey', 
			'user-brett', etc. | This will make it more intuitive to understand what 
			the set of introduced profiles is attempting | to accomplish, particularly 
			when you only have a list of profile id's for debug. | | This profile example 
			uses the JDK version to trigger activation, and provides a JDK-specific repo. 
			<profile> <id>jdk-1.4</id> <activation> <jdk>1.4</jdk> </activation> <repositories> 
			<repository> <id>jdk14</id> <name>Repository for JDK 1.4 builds</name> <url>http://www.myhost.com/maven/jdk14</url> 
			<layout>default</layout> <snapshotPolicy>always</snapshotPolicy> </repository> 
			</repositories> </profile> -->

		<!-- | Here is another profile, activated by the system property 'target-env' 
			with a value of 'dev', | which provides a specific path to the Tomcat instance. 
			To use this, your plugin configuration | might hypothetically look like: 
			| | ... | <plugin> | <groupId>org.myco.myplugins</groupId> | <artifactId>myplugin</artifactId> 
			| | <configuration> | <tomcatLocation>${tomcatPath}</tomcatLocation> | </configuration> 
			| </plugin> | ... | | NOTE: If you just wanted to inject this configuration 
			whenever someone set 'target-env' to | anything, you could just leave off 
			the <value/> inside the activation-property. | <profile> <id>env-dev</id> 
			<activation> <property> <name>target-env</name> <value>dev</value> </property> 
			</activation> <properties> <tomcatPath>/path/to/tomcat/instance</tomcatPath> 
			</properties> </profile> -->

		<profile>
			<id>jargonTest</id>
			<properties>
				<jargon.test.confirm>true</jargon.test.confirm>
				<jargon.test.data.directory>/tmp/jargontest/</jargon.test.data.directory>
				<jargon.test.irods.admin>rods</jargon.test.irods.admin>
				<jargon.test.irods.admin.password>rods</jargon.test.irods.admin.password>
				<jargon.test.irods.user>test1</jargon.test.irods.user>
				<jargon.test.irods.password>test</jargon.test.irods.password>
				<jargon.test.irods.resource>test1-resc</jargon.test.irods.resource>
				<jargon.test.irods.user2>test2</jargon.test.irods.user2>
				<jargon.test.irods.password2>test</jargon.test.irods.password2>
				<jargon.test.irods.resource2>test1-resc2</jargon.test.irods.resource2>
				<jargon.test.irods.user3>test3</jargon.test.irods.user3>
				<jargon.test.irods.password3>test</jargon.test.irods.password3>
				<jargon.test.kerberos.user />
				<jargon.test.irods.resource3>test1-resc2</jargon.test.irods.resource3>
				<jargon.test.irods.host>localhost</jargon.test.irods.host>
				<jargon.test.irods.port>1247</jargon.test.irods.port>
				<jargon.test.irods.zone>tempZone</jargon.test.irods.zone>
				<jargon.test.resource.group>testResourceGroup</jargon.test.resource.group>
				<jargon.test.user.group>jargonTestUg</jargon.test.user.group>
				<jargon.test.irods.userDN>test1DN</jargon.test.irods.userDN>
				<jargon.test.irods.scratch.subdir>jargon-scratch</jargon.test.irods.scratch.subdir>
				<jargon.test.option.exercise.remoteexecstream>true</jargon.test.option.exercise.remoteexecstream>
				<jargon.test.option.exercise.ticket>true</jargon.test.option.exercise.ticket>
				<jargon.test.option.exercise.audit>false</jargon.test.option.exercise.audit>
				<jargon.test.option.exercise.workflow>true</jargon.test.option.exercise.workflow>
				<jargon.test.option.exercise.filesystem.mount>true</jargon.test.option.exercise.filesystem.mount>
				<jargon.test.option.exercise.filesystem.mount.local>true</jargon.test.option.exercise.filesystem.mount.local>
				<test.option.mount.basedir>/tmp/basedir</test.option.mount.basedir>
				<test.option.pam>false</test.option.pam>
				<jargon.test.pam.user>pam</jargon.test.pam.user>
				<jargon.test.pam.password>pam</jargon.test.pam.password>
				<test.option.distributed.resources>false</test.option.distributed.resources>
				<test.option.registration>true</test.option.registration>
				<test.option.federated.zone>false</test.option.federated.zone>
				<test.option.kerberos>false</test.option.kerberos>
				<test.option.strictACL>true</test.option.strictACL>
				<test.rest.port>8888</test.rest.port>
				<jargon.test.federated.irods.admin>rods</jargon.test.federated.irods.admin>
				<jargon.test.federated.irods.admin.password>test</jargon.test.federated.irods.admin.password>
				<jargon.test.federated.irods.user>test1</jargon.test.federated.irods.user>
				<jargon.test.federated.irods.password>test</jargon.test.federated.irods.password>
				<jargon.test.federated.irods.resource>test1-resc</jargon.test.federated.irods.resource>
				<jargon.test.federated.irods.host>fedzone2</jargon.test.federated.irods.host>
				<jargon.test.federated.irods.port>1247</jargon.test.federated.irods.port>
				<jargon.test.federated.irods.zone>fedzone2</jargon.test.federated.irods.zone>
			</properties>
		</profile>

		
	</profiles>
  
	<activeProfiles>
		<activeProfile>jargonTest</activeProfile>
	</activeProfiles>

</settings>