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.

Attachment: 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

Reply via email to