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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
