Re: [Dspace-tech] Fwd: OAI-PMH data provider 2.0 not persistent?

2015-05-28 Thread Ondřej Košarko
Hey Tim, No reason for not submitting a pull request and I for sure can move the code around a bit. However, I don't see a way around adding dspace-oai classes as a dependency. At the end of the day the consumer just calls org.dspace.xoai.app.XOAI.index. xmlui webapp does not have dspace-oai

Re: [Dspace-tech] Fwd: OAI-PMH data provider 2.0 not persistent?

2015-05-28 Thread Christian Scheible
Hi Ondřej, hi Tim, It would be great to see this as a pull request. I had a solution for that problem (the OAIIndexEventConsumer was part of dspace-api) but to make it good enough for a pull request it would be needed to move the xoai dependency from dspace-oai to dspace-api and additionally

Re: [Dspace-tech] Fwd: OAI-PMH data provider 2.0 not persistent?

2015-05-28 Thread Tim Donohue
I'll admit, I'm not as familiar with this area of the code, but after doing a quick scan here, I can see what you mean. As Christian mentions, we may need to consider moving the xoai dependency down a level to dspace-api. That seems to be essentially what was done for the RDFConsumer (which

[Dspace-tech] Fwd: OAI-PMH data provider 2.0 not persistent?

2015-05-27 Thread Ondřej Košarko
-- Forwarded message -- From: Ondrej Kosarko ko...@centrum.cz Date: 2015-05-27 12:05 GMT+02:00 Subject: Re: [Dspace-tech] OAI-PMH data provider 2.0 not persistent? To: Christian Scheible christian.schei...@uni-konstanz.de Cc: dspace-tech@lists.sourceforge.net

Re: [Dspace-tech] Fwd: OAI-PMH data provider 2.0 not persistent?

2015-05-27 Thread Tim Donohue
Hi Ondřej, I wonder if you'd be willing to submit a Pull Request of these changes (the new OAIIndexEventConsumer, etc)? These seem like potentially useful changes overall, and would be something we'd consider adding to DSpace. My only (small) recommendation would be to simply put the