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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
