Is this also related to anonymous read access of metadata via OAI and
3rd party tools such as SRW/SRU?
We have a 3rd party extension that uses OAI to retrieve DSpace records
but even if one removes all authorization to a repository item, the
record's metadata is still viewable via OAI and searc
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
On Oct 23, 2009, at 4:17 PM, Mark Diggory wrote:
> Doubt its the classpath unless both libraries show in your lib
> folders.
>
> You control which is used by assuring your using an identical
> groupId and Art
Doubt its the classpath unless both libraries show in your lib folders.
You control which is used by assuring your using an identical groupId and
ArtifactId. You can try [version-number] in your versioning to force a
specific dependency on a version. this may propagate into the dependency
tree.
A
Hi Folks,
Doing a spot of tidying up on my own DSpace module, I notice that my
code relies on a more recent version of the ROME library than DSpace.
I wonder if any of the maven gurus out there can tell me what the best
way to manage this is? My module's pom specifies one version and the
DSpa
Handleplugin.java is not able to handle non-numeric handles
---
Key: DS-357
URL: http://jira.dspace.org/jira/browse/DS-357
Project: DSpace 1.x
Issue Type: Bug
Components: DSpa