I thought about logging any custom-mimetype override applied, so the user will be warned about that. Maybe additionally creating a specific attribute in mimetype definition xml to configure it must override the default one instead of aborting. About multiple conflicting custom mimes from different (external) projetcs, Tika currently aborts and it is already a problem now.
So I think it needs additional discussion and should not be addressed in the next release. Will copy/paste this discussion in the jira issue. But I would like to see fixed the detection of MTS videos, but it conflicts with another existing mime glob. Any workaround for this specific case? If yes, I can open a different ticket. Em 2 de mar de 2018 18:23, "Nick Burch" <apa...@gagravarr.org> escreveu: On Fri, 2 Mar 2018, Luís Filipe Nassif wrote: > If I make no progress on TIKA-1466 until 3/9, you can start the release > process without it. But do you devs agree with the proposed change: allow > overriding of glob patterns in custom-mimetypes.xml? > What happens if you have two different custom files which both claim the same glob? We have historically been a bit stricter about built-in types overriding, in part to avoid people doing silly things by mistake, and in part to push people a bit more towards contributing fixes/enhancements for built-in types. I think the latter is less of a thing today, as we've a lot more covered as standard, so it's just the former we need to worry about. How do we help people know when they have conflicting overrides (possibly from different projects), help them sensibly merge or turn off Tika provided magic+definitions, and to alert them to when their copied + customised version probably wants updating following a tika upgrade giving a newer definition? Do a better job of those than we currently do now, then I'm very happy to +1 it :) Nick
