Barriers
	Finding the version control repository for files not within the same plugin.
	e.g. org.apache.maven.archiver.MavenArchiver
	Since this is not a plugin the location is not obvious.
	I tried looking in maven/components/trunk but it is not there BUT it is in maven/tags/maven-2.0.4/maven-archiver

	Working out to do unit testing.     
		extends AbstractMojoTestCase
	is a bit vague about how this should be done.

	Working out to do integration testing
		There is NO documentation on maven-it-plugin.

Knowledge
	RE: Plugin Unit Tests?
		http://www.nabble.com/forum/ViewPost.jtp?post=1494309&framed=y
	
	Re: [m2] plugin tests?
		http://www.nabble.com/forum/ViewPost.jtp?post=817348&framed=y

	plugin-testing-harness
		http://www.nabble.com/forum/ViewPost.jtp?post=4943854&framed=y

	Re: [M203] Writing tests for Plugins (Java Mojos)
		http://www.nabble.com/forum/ViewPost.jtp?post=3998917&framed=y

	http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Harness

	Re: Example of a plugin with integration tests
		http://www.nabble.com/forum/ViewPost.jtp?post=1951599&framed=y

	Best one is the eclipse plugin and its test infrastructure

	Testing Plexus Components	
		http://plexus.codehaus.org/xfactored/ref/developer-guide/building-components/component-testing.html
	
	Testing Strategies
		http://docs.codehaus.org/display/MAVEN/Testing+Strategies?focusedCommentId=53945

	best practices - testing strategies
		http://docs.codehaus.org/display/MAVEN/best+practices+-+testing+strategies?focusedCommentId=55399

	Integration and unit test strategies with maven2
		http://adminsight.de/weblog/weblog/integration-tests-with-maven2_4.html

	Unit Tests are meant to be isolated so that the results of one unit test does not impact 
	the results of any other unit test.	Integration Tests however CAN rely on the results of 
	previous integration tests.  The maven-it-plugin ensures the ordering is correct 
	based upon dependencies. So if your integration test needs the results of a previous one, 
	setup the dependecy correctly.  As dependencies rely on installed products they need
	to be one of the the classifiers defined by Maven, you can't just depend upon a pom.
	And unforuntately since they need to be installed they pollute your maven repository.
	Recommend using the groupId of "test.<groupId>.<artifactId>"
	to avoid namespace collisions and so that the test directory can easily be deleted 
	(however need to be aware of Windows long file name limit, so may need to dump groupId!!!) 
	The artifactId of the ntegration test should include the JIRA defect id or the integration test name.

Maven IT Plugin
	Errors do not get logged to build.log for some reason.
	build.log should be in target/ so that it is cleaned.

	Use the goals.txt file so that each integration test can have different goals, rather than configure this in the plugin.

	Not using the latest installed copy but the one from the previous build which is already resolved by maven

MavenArchiver.java
	Line 85:
	List artifacts = project.getRuntimeClasspathElements();

	Which is essentially the File part of artifact.getFile(), 
	or for released versions <artifactId>-<version>.jar
	and for snapshots <artifactId>-SNAPSHOT.jar
	It does not attempt to resolve to the timestamped version, which is what the assembly does.

	line 105:
	Manifest.Attribute classpathAttr = new Manifest.Attribute( "Class-Path", classpath.toString() );

	Compare this with the way it is done in the assembly dependency section.

Assembly
	In classdoc 
		@requiresDependencyResolution test

	createArchiver delegates to this.archiverManager.getArchiver() (probably not relevant anyway)
	createArchive() is the one that processes the dependency set via processDependencySets()
	processDependencySets() uses getDependencies()
	getDependencies() uses project.getArtifact() and project.getArtifacts()

	The artifact list is obtained via 
		List artifacts = project.getRuntimeClasspathElements();
	in MavenArchiver.getManifest()
	and in AbstractJarMojo.createArchive() is
		archiver.createArchive( project, archive );
	So if JarMojo has the requiresDependencyResolution set on then it should just work.

	the outputFileMapping (defaults to ${artifactId}-${version}.${extension}) is used to
	copy the artifact to the outputDirectory. This differs from the what MavenArchiver 
	at lines 85 & 105 uses to compute the classpath which just uses the file part of 
	Artifact.getFile().
	
Directory bug:
	AbstractAssemblyMojo.createAssembly()
		the last few statements all use 
			projectHelper.attachArtifact
		and i wonder whether this should not be the responsibility of the archiver?

Artifact Resolution:
	If I deploy an artifact locally and then depend upon that locally deployed version
	then occassionally, instead of getting the timestamped version I get the -SNAPSHOT version.
	I can see this through the debugging information I had which showed getVersion to be SNAPSHOT
	I believe this is due to the timestamp resolution on windows being to the even second.
	I think the artifact resolution should always allow the timestamped version to win
	if the times are equal when compared with the -SNAPSHOT version.

	Also, even though the deployed SNAPSHOT has a timestamped version, the artifact file
	will always be -SNAPSHOT.  This means that the runtime classpath should not be using 
	this as a basis for builing the Manifest Class-Path entry (if the file is a snapshot)

DefaultRepositoryLayout:
	pathOf() line 42-45 create the path information for an artifact.
	<groupId>/<artifactId>/<baseVersion>/<artifactId>-<vesion>

	Which always resolves to the -SNAPSHOT version and not the timestamped version.