Thanks for reporting! I filed a jira issue for this:
https://issues.apache.org/jira/browse/MNG-5989
/Anders
On Fri, Mar 4, 2016 at 11:19 PM, Bhowmik, Bindul
wrote:
> Hello,
>
> I ran across a few links on the documentation which should probably be
> updated. The pages either use CMS or Confluen
I think you need to specify all parameter values in test pom.xml, at
least this used to be one of annoying limitations of apache plugin
harness in the past. Personally I gave up on apache harness long time
ago. The harness I've written at Takari works much better everywhere I
used it and I am prett
Jason already applied my patches to master in svn. It just needs to be
released/voted on by someone..
manfred
> I believe there is github fork mirror here:
> https://github.com/apache/maven-plugin-testing/tree/trunk
> So you can certainly create a pull request.
>
>
> On 17 October 2013 04:36, Man
I believe there is github fork mirror here:
https://github.com/apache/maven-plugin-testing/tree/trunk
So you can certainly create a pull request.
On 17 October 2013 04:36, Manfred Moser wrote:
> Given its all in the git repo already.. do you want me to create a patch
> for whatever is in svn the
Given its all in the git repo already.. do you want me to create a patch
for whatever is in svn then? And maybe attach it to some jira issue or
something?
manfred
> Any work that gets patches applied is valid work. You don't get commit
> access if you are in the school, only a bunch of mentors wh
Any work that gets patches applied is valid work. You don't get commit
access if you are in the school, only a bunch of mentors who have commit
access to shout at if your patches are being ignored ;-)
IOW self starters wanted ;-)
On Wednesday, 16 October 2013, Manfred Moser wrote:
> Hi!
>
> I ha
Seemingly it does.. a release together with the 3.1.1 release of Maven
would be great.
manfred
> I will if it takes 60 days to create a Git repo.
>
> On Sep 19, 2013, at 4:47 PM, Olivier Lamy wrote:
>
>> Maybe can be release from svn.
>>
>> On 13 September 2013 14:05, Manfred Moser
>> wrote:
>>
I will if it takes 60 days to create a Git repo.
On Sep 19, 2013, at 4:47 PM, Olivier Lamy wrote:
> Maybe can be release from svn.
>
> On 13 September 2013 14:05, Manfred Moser wrote:
>> Hi!
>>
>> With the 3.1.1 release of Maven coming up hopefully soon I would like to
>> move forward with th
Maybe can be release from svn.
On 13 September 2013 14:05, Manfred Moser wrote:
> Hi!
>
> With the 3.1.1 release of Maven coming up hopefully soon I would like to
> move forward with the plugin testing harness using it as well. Jason fixed
> it to work with 3.0 and requested the repo to be moved
Manfred
if there is a problem is on the Apache side you should be able to make the
change
wheres the hangup
?
Martin
__
> Date: Fri, 13 Sep 2013 00:05:23 -0400
> Subject: Plugin testing release for 3.1.1
> From: manf...@simpligility.co
> Manfred
>
> if there is a problem is on the Apache side you should be able to make the
> change wheres the hangup
I am not a committer so I have no way to do anything. Maybe I should
become one..
manfred
-
To unsubscribe, e-ma
I am looking for how to run a Mahout project on Maven, or how to run a Mahout
project for clustering textual data. Can anyone help please?
Regards,
Tanveer Ahmad
From: Manfred Moser
Sent: 13 September 2013 05:05
To: Maven Developers List
Subject: Plugin
Done.
https://issues.apache.org/jira/browse/INFRA-6591
On Jul 25, 2013, at 11:50 AM, Arnaud Héritier wrote:
>>
3. And now that I'm working on this I'd like to get it out of
>> Subversion and push it over to Git, any objections? I'd prefer to do that
>> before making a branch for the
>
> >>
> >> 3. And now that I'm working on this I'd like to get it out of
> Subversion and push it over to Git, any objections? I'd prefer to do that
> before making a branch for the older version.
> >>
> >
> > No objection from me.
> >
>
> A JIRA ticket or can I just hop in IRC and ask someone fro
On Jul 25, 2013, at 5:25 AM, Olivier Lamy wrote:
> 2013/7/23 Jason van Zyl :
>> Hi,
>>
>> I updated the plugin-testing tools to work with Maven 3.1.0 to help Manfred
>> get the Android Maven Plugin's test harness working with 3.1.0. A couple
>> things:
>>
>> 1. There is an @Override for a me
2013/7/23 Jason van Zyl :
> Hi,
>
> I updated the plugin-testing tools to work with Maven 3.1.0 to help Manfred
> get the Android Maven Plugin's test harness working with 3.1.0. A couple
> things:
>
> 1. There is an @Override for a method implemented for an interface which you
> can only start d
1) No opinion.
2) No opinion.
3) HUGE +1
Thanks for your efforts! :-)
On Tue, Jul 23, 2013 at 1:54 PM, Jason van Zyl wrote:
> Hi,
>
> I updated the plugin-testing tools to work with Maven 3.1.0 to help Manfred
> get the Android Maven Plugin's test harness working with 3.1.0. A couple
> things:
No objections from me.
2011/10/19 Igor Fedorenko :
> plugin-testing support for maven 3.0 is available on
> plugin-testing-mvn-3.x branch [1] for couple of years now, while current
> trunk still works for maven 2.x only.
>
> Any objections I move 2.x support to a branch and make
> plugin-testing-m
Good question. Perhaps it hasn't been redeployed since the apache
snapshot purge, but it still exists in Nexus?
-Original Message-
From: Benjamin Bentmann [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 10, 2008 4:19 PM
To: Maven Developers List
Subject: Re: plugin-testing-ha
Dan Fabulich wrote:
What's going on here? We don't have (ulp) two artifacts called
maven-plugin-testing-harness, one in org.apache.maven (at version 2.4)
and one in org.apache.maven.plugin-testing (at version 1.3) ...?
I believe that's just a remains from the groupId change [0, 1], i.e. the
There's a lot of test code in the dependency-plugin that could be
usefull.
-Original Message-
From: Sommers, Elizabeth [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 02, 2007 9:53 AM
To: dev@maven.apache.org
Subject: Plugin testing strategy
I am using the maven-plugin-testing-harness
Check the war plugin which creates ArtifactStub on the fly.
HTH,
Stéphane
On 5/2/07, Sommers, Elizabeth <[EMAIL PROTECTED]> wrote:
I am using the maven-plugin-testing-harness for general unit-testing of my
plugins, but I find that I need something to test how I am processing
dependencies.
Thanks Kenney, I reopen it.
My understanding is that we have several artifacts to test plugin/component.
- maven-plugin-testing-harness: Mojo unit testing in test phase
(deployed on snapshot-repository)
- maven-it-plugin: Integration test plugin for integration-test phase
(not deployed yet)
- mav
Vincent Siveton wrote:
Hi Kenney and others,
Background:
I added more tests for the antlr plugin. One of them is to call "mvn
site" to generate reports. Because I was unable to play with
maven-embedder and to specify the correct classloader for the archive
and it's dependencies (doxia classes
gt;
> > Thanks
> > -Vincent
> >
> > > -Original Message-
> > > From: Brett Porter [mailto:[EMAIL PROTECTED]
> > > Sent: mardi 7 mars 2006 22:37
> > > To: Maven Developers List
> > > Subject: Re: plugin testing
> > >
&g
PROTECTED]
> > Sent: mardi 7 mars 2006 22:37
> > To: Maven Developers List
> > Subject: Re: plugin testing
> >
> > Summarising this thread...
> >
> > Terminology I mean when I mention things:
> > - unit testing, intended to test this module only, indepe
+1 to all that! Exactly my sentiment.
Thanks
-Vincent
> -Original Message-
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: mardi 7 mars 2006 22:37
> To: Maven Developers List
> Subject: Re: plugin testing
>
> Summarising this thread...
>
> Termin
Summarising this thread...
Terminology I mean when I mention things:
- unit testing, intended to test this module only, independent of its
interaction with Maven and dependencies
- integration testing, in this context, is intended to test that the
plugin works in Maven, that it's metadata is bound
27;s
> important we have a common terminology WRT plugin testing.
>
> -Vincent
>
> > -Original Message-
> > From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
> > Sent: mardi 7 mars 2006 13:14
> > To: Maven Developers List
> > Subject: Re: plugin testing
> &
g you question though... Still think that it's
important we have a common terminology WRT plugin testing.
-Vincent
> -Original Message-
> From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
> Sent: mardi 7 mars 2006 13:14
> To: Maven Developers List
> Subject: Re: plugin testin
On Mon, 6 Mar 2006, Jesse McConnell wrote:
Hi,
(It took me a while to find the code - [EMAIL PROTECTED] and the heave use of
maven internals suggested it was in the maven sandbox :))
I'm catching up to this thread, and I'm wondering what the exact goal
of this effort is.
Specifically, wheter it
Brett Porter wrote:
Jason van Zyl wrote:
This was just the first stage. I just whacked in the DOM reader because
we need some more testing code to create a local repository for the
MavenProjectBuilder. The MavenProjectBuilder should be used.
A stub of the maven project builder, or the real one
On 3/6/06, Brett Porter <[EMAIL PROTECTED]> wrote:
>
> Jason van Zyl wrote:
> > This was just the first stage. I just whacked in the DOM reader because
> > we need some more testing code to create a local repository for the
> > MavenProjectBuilder. The MavenProjectBuilder should be used.
>
> A stub
Jason van Zyl wrote:
> This was just the first stage. I just whacked in the DOM reader because
> we need some more testing code to create a local repository for the
> MavenProjectBuilder. The MavenProjectBuilder should be used.
A stub of the maven project builder, or the real one? The real one use
Brett Porter wrote:
Just some things for the record:
- I don't really like the ... 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 cons
works for things like the artifact, but MavenProject isn't a component and I
can't use a role lookup on it, that was my first direction where I used
components.xml for "stub" role-hint versions of things..
${basedir} works the same as before, I ended up pulling that part out and
putting it into th
Cool. so I was thinking we could drop all the wrapping elements to make it:
Jesse McConnell wrote:
>
>
>
> {$basedir}target/classes/unit/compiler-basic-test/src/main/java
>
> javac
>
> {$basedir}/target/test/unit/compiler-basic-test/target
>
>
maven-compiler-plugin
{$basedir}target/classes/unit/compiler-basic-test/src/main/java
javac
{$basedir}/target/test/unit/compiler-basic-test/target
I should have sent this eariler, but this is act
Just some things for the record:
- I don't really like the ... 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 s
we can now inject StubArtifacts into the mojo's :)
maven-compiler-plugin
src/main/java
javac
target/classes
org.apache.maven.artifact.Artifact
for the time being I am sticking
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
jason and I had a nice chat about this on #plexus today when I asked a
question about getting the right logger instance inside of an object built
out by lookup(ROLE)..
Here is the framework that we worked out...there are two lvls to it but in a
nutshell it is a nice approach I think, very much alo
> -Original Message-
> From: Jesse McConnell [mailto:[EMAIL PROTECTED]
> Sent: mardi 21 février 2006 00:45
> To: Maven Developers List
> Subject: Re: plugin testing
>
> ok, I fiddled around a bit today with the clean plugin as a basic test
> case...
>
> I
Thanks for this!
Jesse McConnell wrote:
> 1) so I did it once with just a normal junit test class and put the setters
> on the mojo. Very little new code had to be added to get it working and it
> was trivial to take that plugin up to about 85% coverage...the remainder
> being some workaround for
http://jira.codehaus.org/browse/MNG-2093
for the regular test case patch and then the plexified approach as well
On 2/20/06, Jesse McConnell <[EMAIL PROTECTED]> wrote:
>
> ok, I fiddled around a bit today with the clean plugin as a basic test
> case...
>
> I really don't like the idea of putting
ok, I fiddled around a bit today with the clean plugin as a basic test
case...
I really don't like the idea of putting setters on the mojo...not sure why,
but it bugs me, probably because it is really only putting them there for
testing purposes which is generally a no-no.
1) so I did it once wit
after reading up on mocks from the links that vincent posted, I am going to
take a stab at putting together a minor set of these to work with for a
couple of the plugins...just to see how it would work out. Hopefully I can
get with vincent a bit tomorrow to make sure I get it close to right the
fi
Vincent Massol wrote:
> I think what you're describing is a stub but not a mock. The advantage of a
> dynamic mock is that you don't need to code any method. It's the user of the
> mock which says what behavior it should have for the methods it calls on the
> mock.
You're right, I've always refer
L PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> > Carlos
> > > > Sanchez
> > > > Sent: samedi 18 février 2006 20:14
> > > > To: Maven Developers List
> > > > Subject: Re: plugin testing
> > > >
> > > > I thought mo
--Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
> Sanchez
> Sent: samedi 18 février 2006 21:32
> To: Maven Developers List
> Subject: Re: plugin testing
>
> On 2/18/06, Vincent Massol <[EMAIL PROTECTED]> wrote:
> &
On 2/18/06, Vincent Massol <[EMAIL PROTECTED]> wrote:
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
> > Sanchez
> > Sent: samedi 18 février 2006 20:14
> > To: Maven Developers List
> > Su
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
> Sanchez
> Sent: samedi 18 février 2006 20:14
> To: Maven Developers List
> Subject: Re: plugin testing
>
> I thought more about static mocks vs. dinamic mocks, i think
Massol <[EMAIL PROTECTED]> wrote:
>
>
> > -Original Message-
> > From: Brett Porter [mailto:[EMAIL PROTECTED]
> > Sent: vendredi 17 février 2006 23:59
> > To: Maven Developers List
> > Subject: Re: plugin testing
> >
> >
> > I think
> -Original Message-
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: vendredi 17 février 2006 23:59
> To: Maven Developers List
> Subject: Re: plugin testing
>
>
> I think this is the right separation. Unit test to get coverage, add and
> use set
I think this is the right separation. Unit test to get coverage, add and
use setters like Vincent suggested. Integration test to verify things
like the lifecycle intereactions, etc. controlled by the annotations at
the class level. We can already do both.
As Carlos mentioned, getting the objects
Hi Vincent,
Vincent Massol wrote:
Hi Jesse,
[snip]
Now, some of plugins can be completely tested by this mechanism while
others
might not actually fit too tell into this lower level testing. That is
where the integration testing comes into more of a play.
I talked to john about this and we
I agree that we need both of unit and integration tests
- unit tests are currently painful because a lot of core objects don't
have a constructor without arguments or don't have constructor and
require caling a factory method. We need to agree where to put all
that staff (I sent a mail about this
Hi Jesse,
> -Original Message-
> From: Jesse McConnell [mailto:[EMAIL PROTECTED]
> Sent: vendredi 17 février 2006 20:40
> To: Maven Developers List
> Subject: plugin testing
>
> brett asked me to look into the idea of a plugin testing framework and
> having mulled it over a bit and talked
58 matches
Mail list logo
