You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@maven.org> on 2008/06/22 20:18:53 UTC
Testing Maven 2.x Embedding
Milos,
Do you need anything other then the standard embedder that's produced
by the build to run your automated tests?
I'm trying to hook the standard output to m2e, and I wanted to try and
do the same with the Netbeans integration so that we can get more
feedback on changes in the trunk as they happen over the course of the
releases that will start shortly.
I know you have your builds in the Sun instance of Hudson but can you
help me setup a Netbeans build in Hudson so we can run whatever
automated tests you have so that we can catch problems with embedding
faster?
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.
-- Jakob Burckhardt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Testing Maven 2.x Embedding
Posted by Jason van Zyl <ja...@maven.org>.
Milos, can you help me copy the Mevenide job from deadlock?
I can see from the output here what the CLI looks like but there are a
couple options I don't really understand:
http://deadlock.netbeans.org/hudson/job/mevenide/423/console
On 22-Jun-08, at 3:13 PM, Milos Kleint wrote:
> On Sun, Jun 22, 2008 at 8:44 PM, Jason van Zyl <ja...@maven.org>
> wrote:
>>
>> On 22-Jun-08, at 11:37 AM, Milos Kleint wrote:
>>
>>> On Sun, Jun 22, 2008 at 8:18 PM, Jason van Zyl <ja...@maven.org>
>>> wrote:
>>>>
>>>> Milos,
>>>>
>>>> Do you need anything other then the standard embedder that's
>>>> produced by
>>>> the
>>>> build to run your automated tests?
>>>
>>> I don't really have any automated tests. The wide variety of
>>> problems
>>> I've encountered so far sort of convince me that I would just spend
>>> time on them without much effect. I rely on the maven's own
>>> integration tests instead. That's what people working on maven care
>>> about anyway primarily.
>>>
>>> I'm using the -Pnetbeans profile for building the embedder bits,
>>> as I
>>> think shading is still necessary in embedded env.
>>>
>>>
>>>>
>>>> I'm trying to hook the standard output to m2e, and I wanted to
>>>> try and do
>>>> the same with the Netbeans integration so that we can get more
>>>> feedback
>>>> on
>>>> changes in the trunk as they happen over the course of the
>>>> releases that
>>>> will start shortly.
>>>
>>> what does "hook the standard output to m2e" mean?
>>>
>>
>> We have quite a few automated tests, so to feed the embedder that
>> produced
>> and wire it into m2e's automated tests as a smoke test.
>>
>>>
>>>>
>>>> I know you have your builds in the Sun instance of Hudson but can
>>>> you
>>>> help
>>>> me setup a Netbeans build in Hudson so we can run whatever
>>>> automated
>>>> tests
>>>> you have so that we can catch problems with embedding faster?
>>>
>>> it's basically a "mvn install nbm:nbm nbm:cluster" but mvn install
>>> shall be enough as well. only a few unit tests there (as I don't
>>> believe in UI testing :) - or rather I don't believe that the value
>>> added to time spent ratio is good in the long run)
>>>
>>> My testing usually involves opening and working with multiple
>>> complex
>>> projects like mevenide, glassfish or hudson to see if things keep
>>> working..
>>>
>>> If writing tests is reasonably easy at maven, I could write some
>>> here
>>> eventually, but generally I'm turned down by any complex test setup.
>>> That's where the tests belong anyway IMHO.
>>>
>>
>> We really just have tests for the actions in m2e. Testing the UI is
>> a test
>> plan and human, no way around that but where I can determine
>> something done
>> in the embedder causes easily detectable problems I'd like to know
>> about
>> them sooner rather then later.
>>
>> Given m2e and netbeans are the primary consumers at this point it
>> would be
>> good to at least keep you guys in Hudson and make sure everything is
>> working. At least at a high level.
>>
>
> Fine with me. However please note that without the manual UI testing
> you probably only figure netbeans integration doesn't compile (which
> actually can be useful as I do override implementations of a few core
> components.)
>
> From top of my head the 3.1.1 release of mevenide had a problem with
> RELEASE version resolution, I've fixed it later, updated to latest
> version just to find out that now the 3.1.3 version has a problem with
> long dependency versions (fixed now in trunk but still I need to
> perform a re-release to push it to users)
> These should have been cought by the integration or unit tests in
> maven itself. I usually only figure when people report the problem to
> me or encounter the issue myself.
>
> Milos
>
>>> greetings.
>>>
>>> Milos
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Jason
>>>>
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder, Apache Maven
>>>> jason at sonatype dot com
>>>> ----------------------------------------------------------
>>>>
>>>> A party which is not afraid of letting culture,
>>>> business, and welfare go to ruin completely can
>>>> be omnipotent for a while.
>>>>
>>>> -- Jakob Burckhardt
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>> In short, man creates for himself a new religion of a rational
>> and technical order to justify his work and to be justified in it.
>>
>> -- Jacques Ellul, The Technological Society
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
To do two things at once is to do neither.
-—Publilius Syrus, Roman slave, first century B.C.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Testing Maven 2.x Embedding
Posted by Milos Kleint <mk...@gmail.com>.
On Sun, Jun 22, 2008 at 8:44 PM, Jason van Zyl <ja...@maven.org> wrote:
>
> On 22-Jun-08, at 11:37 AM, Milos Kleint wrote:
>
>> On Sun, Jun 22, 2008 at 8:18 PM, Jason van Zyl <ja...@maven.org> wrote:
>>>
>>> Milos,
>>>
>>> Do you need anything other then the standard embedder that's produced by
>>> the
>>> build to run your automated tests?
>>
>> I don't really have any automated tests. The wide variety of problems
>> I've encountered so far sort of convince me that I would just spend
>> time on them without much effect. I rely on the maven's own
>> integration tests instead. That's what people working on maven care
>> about anyway primarily.
>>
>> I'm using the -Pnetbeans profile for building the embedder bits, as I
>> think shading is still necessary in embedded env.
>>
>>
>>>
>>> I'm trying to hook the standard output to m2e, and I wanted to try and do
>>> the same with the Netbeans integration so that we can get more feedback
>>> on
>>> changes in the trunk as they happen over the course of the releases that
>>> will start shortly.
>>
>> what does "hook the standard output to m2e" mean?
>>
>
> We have quite a few automated tests, so to feed the embedder that produced
> and wire it into m2e's automated tests as a smoke test.
>
>>
>>>
>>> I know you have your builds in the Sun instance of Hudson but can you
>>> help
>>> me setup a Netbeans build in Hudson so we can run whatever automated
>>> tests
>>> you have so that we can catch problems with embedding faster?
>>
>> it's basically a "mvn install nbm:nbm nbm:cluster" but mvn install
>> shall be enough as well. only a few unit tests there (as I don't
>> believe in UI testing :) - or rather I don't believe that the value
>> added to time spent ratio is good in the long run)
>>
>> My testing usually involves opening and working with multiple complex
>> projects like mevenide, glassfish or hudson to see if things keep
>> working..
>>
>> If writing tests is reasonably easy at maven, I could write some here
>> eventually, but generally I'm turned down by any complex test setup.
>> That's where the tests belong anyway IMHO.
>>
>
> We really just have tests for the actions in m2e. Testing the UI is a test
> plan and human, no way around that but where I can determine something done
> in the embedder causes easily detectable problems I'd like to know about
> them sooner rather then later.
>
> Given m2e and netbeans are the primary consumers at this point it would be
> good to at least keep you guys in Hudson and make sure everything is
> working. At least at a high level.
>
Fine with me. However please note that without the manual UI testing
you probably only figure netbeans integration doesn't compile (which
actually can be useful as I do override implementations of a few core
components.)
>From top of my head the 3.1.1 release of mevenide had a problem with
RELEASE version resolution, I've fixed it later, updated to latest
version just to find out that now the 3.1.3 version has a problem with
long dependency versions (fixed now in trunk but still I need to
perform a re-release to push it to users)
These should have been cought by the integration or unit tests in
maven itself. I usually only figure when people report the problem to
me or encounter the issue myself.
Milos
>> greetings.
>>
>> Milos
>>
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> jason at sonatype dot com
>>> ----------------------------------------------------------
>>>
>>> A party which is not afraid of letting culture,
>>> business, and welfare go to ruin completely can
>>> be omnipotent for a while.
>>>
>>> -- Jakob Burckhardt
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
>
> -- Jacques Ellul, The Technological Society
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Testing Maven 2.x Embedding
Posted by Jason van Zyl <ja...@maven.org>.
On 22-Jun-08, at 11:37 AM, Milos Kleint wrote:
> On Sun, Jun 22, 2008 at 8:18 PM, Jason van Zyl <ja...@maven.org>
> wrote:
>> Milos,
>>
>> Do you need anything other then the standard embedder that's
>> produced by the
>> build to run your automated tests?
>
> I don't really have any automated tests. The wide variety of problems
> I've encountered so far sort of convince me that I would just spend
> time on them without much effect. I rely on the maven's own
> integration tests instead. That's what people working on maven care
> about anyway primarily.
>
> I'm using the -Pnetbeans profile for building the embedder bits, as I
> think shading is still necessary in embedded env.
>
>
>>
>> I'm trying to hook the standard output to m2e, and I wanted to try
>> and do
>> the same with the Netbeans integration so that we can get more
>> feedback on
>> changes in the trunk as they happen over the course of the releases
>> that
>> will start shortly.
>
> what does "hook the standard output to m2e" mean?
>
We have quite a few automated tests, so to feed the embedder that
produced and wire it into m2e's automated tests as a smoke test.
>
>>
>> I know you have your builds in the Sun instance of Hudson but can
>> you help
>> me setup a Netbeans build in Hudson so we can run whatever
>> automated tests
>> you have so that we can catch problems with embedding faster?
>
> it's basically a "mvn install nbm:nbm nbm:cluster" but mvn install
> shall be enough as well. only a few unit tests there (as I don't
> believe in UI testing :) - or rather I don't believe that the value
> added to time spent ratio is good in the long run)
>
> My testing usually involves opening and working with multiple complex
> projects like mevenide, glassfish or hudson to see if things keep
> working..
>
> If writing tests is reasonably easy at maven, I could write some here
> eventually, but generally I'm turned down by any complex test setup.
> That's where the tests belong anyway IMHO.
>
We really just have tests for the actions in m2e. Testing the UI is a
test plan and human, no way around that but where I can determine
something done in the embedder causes easily detectable problems I'd
like to know about them sooner rather then later.
Given m2e and netbeans are the primary consumers at this point it
would be good to at least keep you guys in Hudson and make sure
everything is working. At least at a high level.
> greetings.
>
> Milos
>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>> A party which is not afraid of letting culture,
>> business, and welfare go to ruin completely can
>> be omnipotent for a while.
>>
>> -- Jakob Burckhardt
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Testing Maven 2.x Embedding
Posted by Milos Kleint <mk...@gmail.com>.
On Sun, Jun 22, 2008 at 8:18 PM, Jason van Zyl <ja...@maven.org> wrote:
> Milos,
>
> Do you need anything other then the standard embedder that's produced by the
> build to run your automated tests?
I don't really have any automated tests. The wide variety of problems
I've encountered so far sort of convince me that I would just spend
time on them without much effect. I rely on the maven's own
integration tests instead. That's what people working on maven care
about anyway primarily.
I'm using the -Pnetbeans profile for building the embedder bits, as I
think shading is still necessary in embedded env.
>
> I'm trying to hook the standard output to m2e, and I wanted to try and do
> the same with the Netbeans integration so that we can get more feedback on
> changes in the trunk as they happen over the course of the releases that
> will start shortly.
what does "hook the standard output to m2e" mean?
>
> I know you have your builds in the Sun instance of Hudson but can you help
> me setup a Netbeans build in Hudson so we can run whatever automated tests
> you have so that we can catch problems with embedding faster?
it's basically a "mvn install nbm:nbm nbm:cluster" but mvn install
shall be enough as well. only a few unit tests there (as I don't
believe in UI testing :) - or rather I don't believe that the value
added to time spent ratio is good in the long run)
My testing usually involves opening and working with multiple complex
projects like mevenide, glassfish or hudson to see if things keep
working..
If writing tests is reasonably easy at maven, I could write some here
eventually, but generally I'm turned down by any complex test setup.
That's where the tests belong anyway IMHO.
greetings.
Milos
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> A party which is not afraid of letting culture,
> business, and welfare go to ruin completely can
> be omnipotent for a while.
>
> -- Jakob Burckhardt
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org