You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@any23.apache.org by Peter Ansell <an...@gmail.com> on 2012/06/01 01:24:41 UTC

Re: [DISCUSS] moving toward the first release

On 1 June 2012 01:39, Lewis John Mcgibbney <le...@gmail.com> wrote:
> Hi Simo,
>
> On Thu, May 31, 2012 at 2:15 PM, Simone Tripodi
> <si...@apache.org> 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