Just some things for the record:
- I don't really like the <artifact>...</artifact> element here as it
isn't normal to a POM.
- The POM doesn't do the full inheritence thing, so it might not behave
as expected. This could be confusing
I think if the file is not really a POM, it shouldn't be construed as
one for the sake of clarity. Maybe we can just use the normal Xpp3Dom
configuration lookup, and that can be created from xpp3 dom builder from
a file with just the config element.
I assume if there are project elements to be populated that are not part
of a plugin, they would be set on the stub project housed in the stub
expression evaluator, which could be done in java code?
Also:
- I think we should be adding getters/setters and being able to
construct a normal mojo and set fields by hand (components and
expressions should still be prepopulated in the lookup).
It seems like most of this is in place, just issues of clarity and
perhaps preference.
Thanks again!
- Brett
Jesse McConnell wrote:
> we can now inject StubArtifacts into the mojo's :)
>
> <project>
> <build>
> <plugins>
> <plugin>
> <artifactId>maven-compiler-plugin</artifactId>
> <configuration>
> <compileSourceRoots>
> <compileSourceRoot>src/main/java</compileSourceRoot>
> </compileSourceRoots>
> <compilerId>javac</compilerId>
> <outputDirectory>target/classes</outputDirectory>
> <artifact>org.apache.maven.artifact.Artifact</artifact>
> </configuration>
> </plugin>
> </plugins>
> </build>
> </project>
>
> for the time being I am sticking all of the Stub* maven artifacts in the
> maven-plugin-testing-harness and they are all referenced in the
> components.xml file in the same project. I am not sure if we want them to
> ultimately reside next to the Default* implementations or not...anyone have
> thoughts on that? I could go either way on that.
>
> I am pretty however pretty happy with the way this is fleshing out :)
>
> very useful and by the time more unit tests are written we should have a
> pretty decent set of stub's for mojo's to work with.
>
> Not everything will have to be a stub either here, jason is working on the
> ArtifactRepository and aggregating some things together but I can see the
> need where we are going to need a real one or more of those since some
> plugins make use of it...the axistools plugin for one :)
>
> cheers,
> jesse
>
> On 2/23/06, Jesse McConnell <[EMAIL PROTECTED]> wrote:
>> updating this thread again
>>
>> Jason and I talked over the above idea and he took a few minutes and put
>> together the basic jist of the concept and shoved it into the mojo-sandbox
>> so I could work with it.
>>
>> mojo-sandbox/maven-plugin-testing/maven-plugin-testing-harness
>>
>> that has version 1.0-SNAPSHOT of the AbstractMojoTestCase which is what
>> the test cases can subclass from to get the ability to dynamically load the
>> mojo based on an arbitary pom.
>>
>> I modified the maven-clean-plugin again to make use of this and it turned
>> out quite well I'd say.
>>
>> /**
>> * tests the ability of the plugin to clean out a set of directories
>> *
>> * @throws Exception
>> */
>> public void testClean() throws Exception {
>>
>> CleanMojo mojo = (CleanMojo) lookupMojo ("clean", testPom );
>>
>> assertNotNull( mojo );
>>
>> mojo.execute();
>>
>> assertFalse ( FileUtils.fileExists(
>> "target/test/testDirectoryStructure/buildDirectory" ) );
>> assertFalse ( FileUtils.fileExists(
>> "target/test/testDirectoryStructure/buildOutputDirectory" ) );
>> assertFalse ( FileUtils.fileExists(
>> "target/test/testDirectoryStructure/buildTestDirectory" ) );
>> }
>>
>>
>> This method in the CleanMojoTest class coupled with this pom.xml @
>> src/test/resources/unit/clean/pom.xml execute the unit test very easily.
>>
>> <project>
>> <build>
>> <plugins>
>> <plugin>
>> <artifactId>maven-clean-plugin</artifactId>
>> <configuration>
>>
>> <directory>target/test/testDirectoryStructure/buildDirectory</directory>
>>
>> <outputDirectory>target/test/testDirectoryStructure/buildOutputDirectory</outputDirectory>
>>
>>
>> <testOutputDirectory>target/test/testDirectoryStructure/buildTestDirectory</testOutputDirectory>
>> </configuration>
>> </plugin>
>> </plugins>
>> </build>
>> </project>
>>
>> I am going to take this approach and work on testing another plugin in
>> maven now, get a couple of plugins under my belt with this and the abstract
>> base class ought to be pretty tight.
>>
>> jesse
>>
>> --
>> jesse mcconnell
>> jesseDOTmcconnellATgmailDOTcom
>
>
>
>
> --
> jesse mcconnell
> jesseDOTmcconnellATgmailDOTcom
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
