I don't recommend going into the dspace-api and adding the dependency there, yes that is circular and you should not do it. If you want to add Event Consumers to you build, here is the approach I prescribe.
1.) Maintain your java code changes in a maven jar project, in the same approach as dspace-xmlui-api or other jar module dependent on the dspace-api 2.) Place a "profile" for your dependent project into the [dspace-source]/dspace/pom.xml in a manner similar to the profiles there for dspace-api etc. 3.) Add the project as a dependency to [dspace-source]/dspace/pom.xml if you require it to be in the [dspace.dir]/lib, otherwise, add it as a dependency to any of the [dspace-source/modules/*/pom.xml that you require it to be present as a dependency. One caveat, the community is still taking risks with copying dspace-api classes and altering them for their own purposes. Unfortunately, without API contracts and dependency injection, this will still be a required strategy to altering the buisness logic of dspace 1.5.x. Doing so requires the class in your modules to be on the classpath prior to the dspace-api class it is replacing, in doing so you need to make sure your maven artifactID is named such that it falls before the dspace-api, for instance "01-dspace-api-custom". I wish we could get into the practice of not altering core classes directly in our deployments of dspace, unfortunately, this is a practice I feel will not go away until we achieve better API contracts such as what we are working on in DSpace 2.0. Cheers, Mark On Fri, Apr 17, 2009 at 8:23 AM, Richard Jones <[email protected]> wrote: > Hi Folks, > > I'm looking for a maven guru to give me a bit of a hand here ... > > I'm trying to write a DSpace module, which has the dspace-api as a > dependency, and is itself built into an artifact of type WAR. > Unfortunately, I have to also write a small patch for the DSpace core to > invoke a piece of functionality in my module (it needs a hook in to an > event, basically) at a point in the item workflow. I have therefore > specified my module as a dependency in the dspace-api pom, thus: > > <dependency> > <groupId>uk.co.symplectic</groupId> > <artifactId>dspace-symplectic</artifactId> > <version>SNAPSHOT</version> > <type>war</type> > </dependency> > > I've ensured that this artifact is available in the maven repository > locally (built against a published version of the dspace 1.5.1 artefact > in the main maven repo), so when dspace-api from svn builds it should be > able to pick this up. Indeed, no complaints there, it seems to find > what it's looking for, and IDEA agrees with me that the maven > configuration is correct. And yet, when I mvn clean package on the > dspace top level module, when it builds the dspace-api module, I get the > following compile error: > > [INFO] > ------------------------------------------------------------------------ > [INFO] Building DSpace Kernel :: API and Implementation > [INFO] > [INFO] Id: org.dspace:dspace-api:jar:1.5.3-SNAPSHOT > [INFO] task-segment: [generate-sources, generate-resources, > generate-test-sources, generate-test-resources] > [INFO] > ------------------------------------------------------------------------ > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:compile] > [INFO] Compiling 267 source files to > /home/richard/Workspace/dspace-1.5.x/dspace-api/target/classes > [ERROR] BUILD FAILED > [ERROR] Compilation failure > > /home/richard/Workspace/dspace-1.5.x/dspace-api/src/main/java/org/dspace/workflow/WorkflowManager.java:[74,51] > package uk.co.symplectic.publications.repo.dspace15x does not exist > > /home/richard/Workspace/dspace-1.5.x/dspace-api/src/main/java/org/dspace/workflow/WorkflowManager.java:[624,4] > cannot find symbol > symbol : class WorkflowHackTools > location: class org.dspace.workflow.WorkflowManager > > /home/richard/Workspace/dspace-1.5.x/dspace-api/src/main/java/org/dspace/workflow/WorkflowManager.java:[624,34] > cannot find symbol > symbol : class WorkflowHackTools > location: class org.dspace.workflow.WorkflowManager > > IDEA completely disagrees with the unavailability of this package, by > giving me access to the WorkflowHackTools API from within the > WorkflowManager class. > > I've a feeling this is something to do with the circular dependency of > my module on dspace-api and vice versa, but can't see what I'm doing > wrong at all. Perhaps I need to produce a jar artifact with my files in > it instead? > > Thoughts? > > Cheers, > > Richard > > -- Richard Jones Head Repository Systems Architect, Symplectic Limited > e: [email protected] t: 0845 026 4755 t: +44 (0)207 7334036 w: > http://www.symplectic.co.uk/ > > > ------------------------------------------------------------------------------ > Stay on top of everything new and different, both inside and > around Java (TM) technology - register by April 22, and save > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. > 300 plus technical and hands-on sessions. Register today. > Use priority code J9JMT32. http://p.sf.net/sfu/p > _______________________________________________ > Dspace-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-devel > -- Mark R. Diggory http://purl.org/net/mdiggory/homepage - Bio ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
