<project>
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compileSourceRoots>
<compileSourceRoot>{$basedir}target/classes/unit/compiler-basic-test/src/main/java</compileSourceRoot>
</compileSourceRoots>
<compilerId>javac</compilerId>
<outputDirectory>{$basedir}/target/test/unit/compiler-basic-test/target</outputDirectory>
<artifact implementation="
org.apache.maven.plugin.testing.stubs.StubArtifact"/>
</configuration>
</plugin>
</plugins>
</build>
</project>
I should have sent this eariler, but this is actually what that test file is
looking like atm.
jesse
On 3/6/06, Brett Porter <[EMAIL PROTECTED]> wrote:
>
> 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]
>
>
--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom
