MarkW,
There is also an entire testing framework already in the dspace-services
implementation that is responsible for properly activating the service
manager, I've used this across projects easily to to create tests for DSpace
services that run for an add-on. Of course, because its not actually
requiring a dspace instance to run the test, there no need for the
directory, but I'd really like to take advantage of the native java
database, especially in the dspace-database add-on such that we can verify
that the database is there and configured properly when we want to write add
ons that utilize it. So that's another important candidate to consider
possibly being independent of dspace-api.
I'm also thinking about "configuration" here was well, the
ConfigurationService in dspace-services currently gets its configuration
from src/test/resources and thats a configuration that only contains exactly
those properties that the service-manager utilizes. Additional modules
would drop their own files into src/test/resources to support their testing.
I say these points because I want to make sure that the dspace-api test
framework does align with the space service manager testing capabilities.
This is because, ultimately the target is to replace ConfigurationManager
with ConfigurationService and TBH, the Service was designed with this sort
of JUnit testing in mind.
This means that the Testing Framework
a.) Is not dependent on dspace-api
b.) But will need to have knowledge/logic to determine "where" to get
default configuration files from for config/dspace.cfg and
dspace/config/modules/*.cfg (something the dspace-services uses the provided
${dspace.dir} property to resolve )
c.) Should know where to find "SQL files" that it needs to load into the
native java db, and that the add-on its being executed in should be able to
add to these.
d.) Should be able to toss in other configuration details from the add-on
[addon-src]/src/config? that may not already be in [dspace-src]/dspace/*
(for instance adding to the solr configuration or creating a dir
So it sounds like three features:
1.) bootstraps a default target/testing/${dspace.dir} off the "dspace"
module found via "moduleSet" in an assembly which includes it. The module
needs to be installed or deployed to a maven repo if it isn't present in the
Maven reactor
2.) adds into the target/testing/${space.dir} any additional resources it
defines in [addon-src]/src/test/config and/or [addon-src]/src/main/config
3.) initializes an in memory native java database needed based on those
configurations and so on (current behavior).
I do agree that constructing the testing environment is best done via an
assembly executed at generate-test-resources phase as you've suggested. And
that initially.
We will need to make the [dspace-src]/dspace maven project produce an
artifact and attach it that contains
dspace/bin/
dspace/config/
dspace/solr/
dspace/etc/
…
similar to the current "release" assembly that makes our current
dspace-release-xxx.zip distribution
http://scm.dspace.org/svn/repo/dspace/trunk/pom.xml
<profile>
<id>distributions</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<inherited>false</inherited>
<executions>
<execution>
<inherited>false</inherited>
<configuration>
<descriptorRefs>
<descriptorRef>release</descriptorRef>
<descriptorRef>src-release</descriptorRef>
</descriptorRefs>
<tarLongFileMode>gnu</tarLongFileMode>
<finalName>dspace-${pom.version}</finalName>
</configuration>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.dspace.maven.plugins</groupId>
<artifactId>dspace-assembly-plugin</artifactId>
<version>1.1</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</profile>
This is what are moved out of the dspace-assembly-plugin and started working
on separately here:
http://scm.dspace.org/svn/repo/dspace/branches/dspace-async-release/dspace-release/src/assemble/release.xml
in its original form, it used fileSets to achieve a similar structure to the
joint test deployment dir. This may be an initial iteration approach until
we can do a "moduleSet" based assembly (which would be capable of getting
the dspace-parent-xxx-tests.zip artifact more generically from the reactor
(i.e. central repo, local repo or active reactor modules)
Finally, theres a chicken or egg issue here if you try to make the
trunk/dspace/pom.xml be responsible for creating its own artifact, because
the reactor ordering for dspace/pom.xml is last in the current trunk, I
would place this logic not in trunk/dspace/src/assembly but instead inside
trunk/src/assembly and call it from dspace-parent. this means that the
support for tests would be generated as the following dependency
org.dspace:dspace-parent:zip:*:tests
because that pom is always built first such that all other modules
(dspace-api etc) can use its generated artifacts afterwards.
Mark
Mark
On Thu, Jul 21, 2011 at 1:58 PM, Mark H. Wood <mw...@iupui.edu> wrote:
> 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.
>
>
> ------------------------------------------------------------------------------
> 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
>
>
--
Mark R. Diggory
@mire - www.atmire.com
2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010
Esperantolaan 4 - Heverlee 3001 - Belgium
------------------------------------------------------------------------------
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
