We need several things: o a JAR artifact containing the common test support classes (org.dspace.AbstractUnitTest, .AbstractIntegrationTest, *.Mock*) on which tests can depend. If the jar:test-jar goal is configured (and in dspace-api it is) AND tests are not disabled when preparing for deployment, then an additional JAR containing the test-scoped classes (and resources?) is built, installed, and I'd guess deployed. It will contain test classes specific to dspace-api but they could be ignored.
Or we could create an assembly containing only what we want and bind it wherever we want it. It would be nice if we could just use what Maven (conditionally) wants to build anyway, but it's not essential that we do. o a directory tree filled with the normal DSpace stuff. Right now, AbstractUnitTest builds this by copying a separate testing version of this stuff to somewhere. This will have to change if we are going to be doing this in multiple projects, and (as has been pointed out) it's hard to keep the testing tree in sync. with production and it doesn't get done. We could build a "working" [DSpace] tree when dspace-api is packaged, pack it up in an archive (using the assembly plugin), and attach it as yet another artifact, deploying it to the repo. as well, so that we have something on which to depend. Maven's dependency:unpack might be useful to unpack it and could be bound to one of the phases which prepare for the test phase. Or AbstractUnitTest could do what it does now, but from an automatically maintained archive instead of an all-too-frequently outdated duplicate tree. I'm not sure what changes would be needed in the deployment procedure, and I'm only assuming that the test-jar gets deployed. (I don't yet have a remote repository that I can pollute, blow away and recreate as needed, and I've never done a mvn deploy.) In the long term I think it might be clearer to pull the framework out into its own project and just leave the specific tests in each project, but that's for later. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart.
pgpNp2REtEOAB.pgp
Description: PGP signature
------------------------------------------------------------------------------ 5 Ways to Improve & Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/
_______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel