On 1 June 2012 01:39, Lewis John Mcgibbney <[email protected]> wrote: > Hi Simo, > > On Thu, May 31, 2012 at 2:15 PM, Simone Tripodi > <[email protected]> wrote: > >> apologize for the lack of participation in the last month, but I've >> been really busy in something that literally stole my life :( > > Hope that things are back to normal now. I bet you were just watching > the Giro d'Italia anyway ;0) > >> Anyway, I'm a little outdated on following what happened on JIRA - is >> there any serious pending issue that prevents the first release to be >> pushed out? > > Ok a quick run down > > ANY23-83 - Michele has committed a good bit of work here. From what I > can see there has been around 5 commits relating to this issue, > however I think that Peter has something to add? Please can you chime > in here Peter if you require anything else to be bolted on to the > issue and we can review? Thanks
The places where the formats were previously hardcoded are fixed now. It would be nice if the equivalent patch that was added to Naive (to use Rio.getParserFormatFromFileName) could be added as a backup for TikaMIMETypeDetector when it fails to find a MIME-type, as RDFFormats, which are extensible by users of the library, contain file-extension-to-mime-type mappings that could be useful for people who want to use Tika mainly with Rio as a backup. They should be able to do this now by using both the Tika and Naive detectors in sequence, but some may find it useful to have it in one detector. I am not sure what the desired scope for a single detector, so it may be irrelevant if detectors are scoped to have a single purpose. See patch at [1] for an example of how it might be done (the @Override annotations that I also added when I made up that patch might also be useful to add if someone is going to commit it to svn). [1] https://github.com/ansell/any23/commit/6da60d6b92932f08a7ca9f08a3cdf9aa74615bb2 > ANY23-95 - By the looks of it this is a trivial case of switching the > default as Michele suggests. Although it is marked as major, I'm > hoping it is relatively simple to implement. > > ANY23-75 - I think this is ready to be committed? Any objections? > > ANY23-79 - This is little more than a pain in the back side. I've > tried messing around with the maven configuration with little joy. > There seems to be some confusion whether setting file permissions can > be achieved with the app-assembler or the maven assembly plugin. I > gave up and submitted a patch which doesn't solve the problem but digs > around the correct area. Maybe you could have a look for us Simo... > you're Maven magic would be appreciated here. I think the idea is to > set permissions to execute by default. The current workaround for this bug is to use the assembly plugin to set the file attributes, as the appassembler authors don't believe it is actually a bug. Cheers, Peter
