The classpath workarounds are awful... ugh. The dspace "api" is so tightly coupled and has so many behaviours built in to it that it makes it really difficult to maintain any kind of patch against it.
On Apr 21, 2009, at 6:12 AM, Richard Jones wrote: > Hi, > > Thanks for the tips, guys, I've now managed to sort this out, at least > for the time being. Mark - I'm not sure if I've done it in a way > which > is compatible with yours, but I will revisit it in the future, as I'm > not particularly happy with having to maintain a patch against the > DSpace core. Just to be clear: you're suggesting that my code changes > replicate the whole WorkflowManager class, with my changes added in, > and > that I just ensure this is loaded first in the classpath? > >> 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. >> > > Quite so. Unfortunately, I need something to happen at a specified > point in the workflow, and without an event being fired at that point > (there isn't), I can't do anything but hack the core file. > > Cheers, > > Richard > >>> 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 >>> >>> >> >> >> >> > > > -- > 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 ------------------------------------------------------------------------------ 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
