I'm running on half a brain today (allergies), but I do want to make one
point that I feel is pretty important:
IMO we need to move away from generalized test plugins for use in the
maven core ITs ASAP. Normal object-oriented design concerns don't apply
well here, and factoring behavior into ever more abstract architecture
does not serve the goal of clean, easy-to-debug integration tests. IMO
the only infrastructure we need for integration testing maven is the
verifier; everything else should be contained within the specific
integration test that uses it.
Sure, this will lead to a profusion of plugins, and probably will cost
some time in terms of executing the integration test run, but these are
not primary concerns of the integration test project...reliability and
ease-of-debugging are. When we use a plugin for more than one
integration test, it's inevitable that the logic in that plugin will be
far more complex than is really needed to check the requirements for a
particular integration test that uses it. This complexity is not helping
us at all, and certainly the value of consolidating testing/verification
logic from multiple integration tests is not greater than the problems
caused when we have to chase bugs into these plugins...then try to fix
the issue (which may be in the method of testing as much as in the main
code in these cases) without causing collateral damage to other
integration tests.
If the only dependency for integration tests is the verifier, then
there's not much point in moving it into its own SVN structure, IMO.
-john
---
John Casey
Developer and PMC Member, Apache Maven (http://maven.apache.org)
Member, Apache Software Foundation
Blog: http://www.ejlife.net/blogs/buildchimp
Brett Porter wrote:
On 15/09/2008, at 10:22 AM, Jason van Zyl wrote:
On 15-Sep-08, at 1:40 AM, Brett Porter wrote:
Hi,
To clear up some of the confusion about snapshots in the area I'd
like to take the following steps:
What confusion?
1) the answer to the question "what's the current release of the
verifier?" (it's 1.0, but there's 1.1-SNAPSHOT and 1.2-SNAPSHOT floating
around, we should just release the latest as it works).
2) in applying some patches I found these are also used by NMaven's
trunk. It was looking for 1.0-SNAPSHOT of maven-integration-test-helper
which is now 2.1-SNAPSHOT, though it has nothing to do with the Maven
version.
3) the inheritance hierarchy of the support modules no longer matches
the directory structure.
1) create /maven-integration-testing/trunk (+tags and branches)
Those are there already, no?
As I said, I'm suggesting a separate trunk for the bits that run maven
test suites (verifier + maven-* in the support dir) vs the test suite
itself (tests + support artifacts).
2) move maven-verifier and maven-integration-test-* from the recently
separated core-integration-tests-support module into that trunk (this
being a collection of things that help write integration tests that
run Maven). Group ID org.apache.maven.itest to avoid confusion with
the previous versions, and version 1.2-SNAPSHOT to align to the verifier
You want to take maven-verifier out of shared?
Yes, see above.
3) release the above multi-module project as 1.2
4) update core-integration-testing to use the above release and align
the versions as a single multi-module project (this being a
particular version of a whole test suite).
Thoughts?
I think you should defer to John and Shane's needs as Shane just got
seriously hosed by mismatched versions and while trying to stabilize
the trunk I would prefer to get some stable baseline before any
swizzling happens. What happened was just oversight but Shane and I
sat there for hours wondering what was going on until we released I
was running the ITs from source and he was running the IT ball which
were missing 10 ITs because no one was deploying it.
Exactly, I am trying to establish a stable baseline everything can use.
Having a few released artifacts will reduce the need to build things first.
- Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
