Welcome to clarin-dspace Discussions!

[kosarko]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[TomazErjavec]

Well, somebody has to start! So, I'm Tomaž Erjavec, coordinator of CLARIN.SI, which has been (mostly:) happily using CLARIN-DSpace for about 5 years now and have just recently celebrated having 200 entries (not counting new versions) in https://www.clarin.si/repository/xmlui/

And, indeed, there are some things that I am wondering about, and I'm not sure if this is what you had in mind, but let me mention one:
The weekly repository healthcheck mails are a very useful tool to see if everything is ok (esp. dead URLs, but also other stuff), but they have in them so many errors (i.e. endless java dumps) that is is then difficult to actually find the useful data in between. We (or, rather @cyplas) have been unsucessfully trying to fix this and posting issues about it for, well, years, without much effect so far. Is there any hope that this will be eventually resolved? (and I am aware this is not simple, as each error probably has a different source, but, still...). In case anybody apart from the LINDAT team has managed to solve any of the healthcheck issues, we would of course be very happy to hear from them as well!

[cyplas]

The weekly repository healthcheck mails are a very useful tool to see if everything is ok (esp. dead URLs, but also other stuff), but they have in them so many errors (i.e. endless java dumps) that is is then difficult to actually find the useful data in between. We (or, rather @cyplas) have been unsucessfully trying to fix this and posting issues about it for, well, years, without much effect so far. Is there any hope that this will be eventually resolved? (and I am aware this is not simple, as each error probably has a different source, but, still...). In case anybody apart from the LINDAT team has managed to solve any of the healthcheck issues, we would of course be very happy to hear from them as well!

My understanding and experience is that solving most of the seemingly excess things that show up in the weekly healthcheck is a good example of a high-cost low-gain task, which consequently rarely gets priority (whether I post them locally for myself in our fork or on ufal's fork). And it's not always clear to me whether the problem is the errors or the messages. To explore the latter possibility a bit: Perhaps we should consider whether certain parts should not be included in the healthcheck, or included only if the healthcheck is run explicitly with a certain parameter (e.g., -log debug), or whether we should document somewhere a list of common things that show up in the healthcheck and what they actually mean and whether to worry about them. But all this probably one makes sense at the community-wide level if different clarin-dspace installations get roughly the same kinds of excess messages and find them equally annoying. :)

[kosarko]

Hi,
first of all thanks for testing the discussions 🥇
If there's an issue that you'd really like to see solved add a comment to it from time to time. That way it will rise to the top (at least in some sort order). But I admit some issues are open for a very long time...
The tasks that healthcheck runs are configured in https://github.com/ufal/clarin-dspace/blob/554e480af4ff3c959936036d5a4e4e2cf538713d/dspace/config/modules/healthcheck.cfg so if you find no value in e.g. the LogsCheck you can remove it from the config

[cyplas]

Hi, thanks for opening this, Ondrej! :)
I'm Cyprian Laskowski, responsible for maintaining the clarin-dspace repository at CLARIN.Si.