You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brett Porter <br...@apache.org> on 2007/09/24 04:26:26 UTC
Re: ITs (was: svn commit: r578582 - in /maven/components/trunk/maven-core/src: main/java/org/apache/maven/plugin/ main/resources/META-INF/plexus/ test/java/org/apache/maven/plugin/)
On 24/09/2007, at 2:57 AM, jvanzyl@apache.org wrote:
> Author: jvanzyl
> Date: Sun Sep 23 09:57:46 2007
> New Revision: 578582
>
> URL: http://svn.apache.org/viewvc?rev=578582&view=rev
> Log:
> o reverting fix for MNG-1323, breaks trunk horribly when everything
> is clean. I ran the ITs after Piotr did but doing so with
> everything clean doesn't work. Time for Hudson.
I saw the same problem. I was looking to use the ITs anyway, so I
went ahead and made some changes:
- lined up the versions of all the artifacts so that we can release
this as a single consumable thing at some point. Chose to use 2.1-
SNAPSHOT as the version - I think we can release it along with Maven,
if it has changed (even though it works against all versions of Maven)
- turned all the support artifacts into a little repository since we
didn't actually need to build them (we were just using the poms).
- made the integration-tests bundle up as a JAR (added this to the
default build, but there is still a profile there to run the tests
themselves)
- added a module to components to (optionally) run the integration
tests against the version you just built (mvn clean install -
Pstandard,run-its)
- took some extra notes in ITProblems.txt
So I can now drop the integration testing module into the Continuum
instance and have them run regularly for both branches.
The need for a clean local repository is still a problem - I've taken
some notes and am going to dig into that a bit deeper for the moment.
I don't want to have to be downloading everything every time - so I'm
hoping to produce a little isolated repository that can be
constructed using the dependency + assembly plugin, laid out and used
without going to the central repo again, completely isolating the tests.
- Brett
--
Brett Porter - brett@apache.org
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: ITs (was: svn commit: r578582 - in /maven/components/trunk/maven-core/src: main/java/org/apache/maven/plugin/ main/resources/META-INF/plexus/ test/java/org/apache/maven/plugin/)
Posted by Brett Porter <br...@apache.org>.
On 24/09/2007, at 1:16 PM, Jason van Zyl wrote:
>> We've still had no luck getting Continuum to do this as far as I
>> know.
http://maven.zones.apache.org/continuum/buildResult.action?
buildId=24322&projectId=514
I had to work through a few issues where the ITs were highly
dependant on the state of the local repository, but it's working now.
The continuum set up is dead simple and it all builds based on the
dependency relationship so things are in the right order. I'll add it
for 2.0.x as well and turn off ci.sh once and for all. There's still
a need to have a cleaner local repository for the ITs in general, but
what's there today is better than yesterday :)
Cheers,
Brett
--
Brett Porter - brett@apache.org
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: ITs (was: svn commit: r578582 - in /maven/components/trunk/maven-core/src: main/java/org/apache/maven/plugin/ main/resources/META-INF/plexus/ test/java/org/apache/maven/plugin/)
Posted by Jason van Zyl <ja...@maven.org>.
On 23 Sep 07, at 7:54 PM 23 Sep 07, Brett Porter wrote:
>
> On 24/09/2007, at 12:38 PM, Jason van Zyl wrote:
>
>>> - turned all the support artifacts into a little repository since
>>> we didn't actually need to build them (we were just using the poms).
>>
>> They need to be installed, but I'm not sure what you mean you made
>> them into "little repository".
>
> I laid it out as an actual repository which can be installed. They
> actually need to be in the remote repo, since many of the tests
> nuke them locally first - however the old ones depended on things
> that weren't present remotely which was less than ideal - it all
> works from a clean repo without having to build the other modules
> first now.
>
> It's still not ideal - but better. I dropped some notes into the
> text file for next steps.
>
The ones required in the remote repo are there now. There are very
few that are required. The rest just need to be installed.
>>
>>> - made the integration-tests bundle up as a JAR (added this to
>>> the default build, but there is still a profile there to run the
>>> tests themselves)
>>
>> Make the bundling not default, I don't want to wait for it to
>> bundle all the tests every time if that's what it's doing.
>
> the packaging step takes < 1 second (the copying of the resources,
> which was needed anyway, is what is time consuming).
>
>>
>>> - added a module to components to (optionally) run the
>>> integration tests against the version you just built (mvn clean
>>> install -Pstandard,run-its)
>>
>> Just as long as it's in a profile and doesn't trigger by default.
>
> nope.
>
>>
>>> - took some extra notes in ITProblems.txt
>>>
>>> So I can now drop the integration testing module into the
>>> Continuum instance and have them run regularly for both branches.
>>>
>>
>> I wouldn't consider this an ideal way to run the ITs. Why not just
>> link up one project dependent on another, when one changes other
>> runs? Making a big JAR and having to deploy them when they change
>> seems rather onerous and time consuming.
>
> IMO, it's much more convenient to run these from within the main
> maven build when you are changing things in Maven (and you can
> still run them from within the IT module when you are changing
> things in there). But whoever is running them can do it as they
> prefer.
>
I don't think so. For anyone to do this and make it workable when you
change or add an IT you have to build and deploy that blob, otherwise
anyone attempting to use it will get false results. We've still had
no luck getting Continuum to do this as far as I know. It is way
faster to have a simple dependency which triggers the build and
hopefully they will be on various machines. The feedback cycle would
be far faster.
> Continuum is running these whenever any of the Maven modules
> change, or the ITs change, using the above set up (though it could
> just as easily be set up as you describe, this way uses less time
> in svn update).
And far more time over all as you have to pull down the entire IT
bundle when two bytes change in the ITs, yes?
So you have these two projects sitting side by side and you must push
that bundle to the local repository, then the m2 build pulls it back
unpacks it and runs it. So for anyone adding ITs they probably won't
use it.
When ITs don't change very often then I suppose it might be a
benefit. But instead of having one source of truth where you run them
in-situ when there is a discrepancy which is not unlikely if it's a
snapshot then it will just cause more problems. If you want to do
this I suggest releasing the ITs with a real version and we just say
when one is added you can just release them. Because someone will try
to deploy one, something will screw up and will just make for a bad
user experience. Give it a whirl, it can't hurt but my bet is that it
will be more hassle and ultimately be more inaccurate then just
linking the projects.
>
> Cheers,
> Brett
>
> ---------------------------------------------------------------------
> 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 and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: ITs (was: svn commit: r578582 - in /maven/components/trunk/maven-core/src: main/java/org/apache/maven/plugin/ main/resources/META-INF/plexus/ test/java/org/apache/maven/plugin/)
Posted by Brett Porter <br...@apache.org>.
On 24/09/2007, at 12:38 PM, Jason van Zyl wrote:
>> - turned all the support artifacts into a little repository since
>> we didn't actually need to build them (we were just using the poms).
>
> They need to be installed, but I'm not sure what you mean you made
> them into "little repository".
I laid it out as an actual repository which can be installed. They
actually need to be in the remote repo, since many of the tests nuke
them locally first - however the old ones depended on things that
weren't present remotely which was less than ideal - it all works
from a clean repo without having to build the other modules first now.
It's still not ideal - but better. I dropped some notes into the text
file for next steps.
>
>> - made the integration-tests bundle up as a JAR (added this to the
>> default build, but there is still a profile there to run the tests
>> themselves)
>
> Make the bundling not default, I don't want to wait for it to
> bundle all the tests every time if that's what it's doing.
the packaging step takes < 1 second (the copying of the resources,
which was needed anyway, is what is time consuming).
>
>> - added a module to components to (optionally) run the integration
>> tests against the version you just built (mvn clean install -
>> Pstandard,run-its)
>
> Just as long as it's in a profile and doesn't trigger by default.
nope.
>
>> - took some extra notes in ITProblems.txt
>>
>> So I can now drop the integration testing module into the
>> Continuum instance and have them run regularly for both branches.
>>
>
> I wouldn't consider this an ideal way to run the ITs. Why not just
> link up one project dependent on another, when one changes other
> runs? Making a big JAR and having to deploy them when they change
> seems rather onerous and time consuming.
IMO, it's much more convenient to run these from within the main
maven build when you are changing things in Maven (and you can still
run them from within the IT module when you are changing things in
there). But whoever is running them can do it as they prefer.
Continuum is running these whenever any of the Maven modules change,
or the ITs change, using the above set up (though it could just as
easily be set up as you describe, this way uses less time in svn
update).
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: ITs (was: svn commit: r578582 - in /maven/components/trunk/maven-core/src: main/java/org/apache/maven/plugin/ main/resources/META-INF/plexus/ test/java/org/apache/maven/plugin/)
Posted by Jason van Zyl <ja...@maven.org>.
On 23 Sep 07, at 7:26 PM 23 Sep 07, Brett Porter wrote:
>
> On 24/09/2007, at 2:57 AM, jvanzyl@apache.org wrote:
>
>> Author: jvanzyl
>> Date: Sun Sep 23 09:57:46 2007
>> New Revision: 578582
>>
>> URL: http://svn.apache.org/viewvc?rev=578582&view=rev
>> Log:
>> o reverting fix for MNG-1323, breaks trunk horribly when
>> everything is clean. I ran the ITs after Piotr did but doing so
>> with everything clean doesn't work. Time for Hudson.
>
> I saw the same problem. I was looking to use the ITs anyway, so I
> went ahead and made some changes:
> - lined up the versions of all the artifacts so that we can release
> this as a single consumable thing at some point. Chose to use 2.1-
> SNAPSHOT as the version - I think we can release it along with
> Maven, if it has changed (even though it works against all versions
> of Maven)
> - turned all the support artifacts into a little repository since
> we didn't actually need to build them (we were just using the poms).
They need to be installed, but I'm not sure what you mean you made
them into "little repository".
> - made the integration-tests bundle up as a JAR (added this to the
> default build, but there is still a profile there to run the tests
> themselves)
Make the bundling not default, I don't want to wait for it to bundle
all the tests every time if that's what it's doing.
> - added a module to components to (optionally) run the integration
> tests against the version you just built (mvn clean install -
> Pstandard,run-its)
Just as long as it's in a profile and doesn't trigger by default.
> - took some extra notes in ITProblems.txt
>
> So I can now drop the integration testing module into the Continuum
> instance and have them run regularly for both branches.
>
I wouldn't consider this an ideal way to run the ITs. Why not just
link up one project dependent on another, when one changes other
runs? Making a big JAR and having to deploy them when they change
seems rather onerous and time consuming.
> The need for a clean local repository is still a problem - I've
> taken some notes and am going to dig into that a bit deeper for the
> moment. I don't want to have to be downloading everything every
> time - so I'm hoping to produce a little isolated repository that
> can be constructed using the dependency + assembly plugin, laid out
> and used without going to the central repo again, completely
> isolating the tests.
>
> - Brett
>
> --
> Brett Porter - brett@apache.org
> Blog: http://www.devzuz.org/blogs/bporter/
>
> ---------------------------------------------------------------------
> 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 and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
svn commit: r578582 - in /maven/components/trunk/maven-core/src:
main/java/org/apache/maven/plugin/ main/resources/META-INF/plexus/ test/java/org/apache/maven/plugin/)
Posted by Piotr Tabor <pt...@newitech.com>.
Hello,
I cannot reproduce the problem. I tried with 578553 revision (the last
version before the rollback),
and all IT tests (and other tests) works in on completely clean box (I
installed it on computer that hadn't been containing Maven before).
Please give me more details about your problems. I am out of ideas what
to do to reproduce it.
Thank you,
Piotr Tabor
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: ITs
Posted by Brett Porter <br...@apache.org>.
On 05/10/2007, at 4:53 AM, Stephen Connolly wrote:
>> I am really sorry for those above. I will take a look into this
>> during
>> the weekend.
>> What do you mean by "Time for Hudson" ?
>>
>>
> I'm guessing http://hudson.dev.java.net
> The CI tool that's easy to setup
When this happened, I configured the ITs in the Continuum so we
should see such failures ahead of time now.
- Brett
--
Brett Porter - brett@apache.org
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: ITs
Posted by Stephen Connolly <st...@one-dash.com>.
Piotr Tabor wrote:
> Brett Porter pisze:
>
>> On 24/09/2007, at 2:57 AM, jvanzyl@apache.org wrote:
>>
>>
>>> Author: jvanzyl
>>> Date: Sun Sep 23 09:57:46 2007
>>> New Revision: 578582
>>>
>>> URL: http://svn.apache.org/viewvc?rev=578582&view=rev
>>> Log:
>>> o reverting fix for MNG-1323, breaks trunk horribly when everything
>>> is clean. I ran the ITs after Piotr did but doing so with everything
>>> clean doesn't work. Time for Hudson.
>>>
> I am really sorry for those above. I will take a look into this during
> the weekend.
> What do you mean by "Time for Hudson" ?
>
>
I'm guessing http://hudson.dev.java.net
The CI tool that's easy to setup
> Thank you,
> Piotr Tabor
>
> ---------------------------------------------------------------------
> 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: ITs
Posted by Piotr Tabor <pt...@newitech.com>.
Brett Porter pisze:
>
> On 24/09/2007, at 2:57 AM, jvanzyl@apache.org wrote:
>
>> Author: jvanzyl
>> Date: Sun Sep 23 09:57:46 2007
>> New Revision: 578582
>>
>> URL: http://svn.apache.org/viewvc?rev=578582&view=rev
>> Log:
>> o reverting fix for MNG-1323, breaks trunk horribly when everything
>> is clean. I ran the ITs after Piotr did but doing so with everything
>> clean doesn't work. Time for Hudson.
>
I am really sorry for those above. I will take a look into this during
the weekend.
What do you mean by "Time for Hudson" ?
Thank you,
Piotr Tabor
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org