Puja, can you please detail what options are in the indexing project (for
option 1)? As Andrew asked, are pre-computed indices part of that project?
How about the entity-centric index? And is it correct that if we go with
option 1, there is still a reasonably easy way for people interested in the
"optional" parts to include them?

Thanks,
Adina

On Thu, Oct 6, 2016 at 10:57 AM, Smith, Andrew <[email protected]>
wrote:

> Wouldn't that also take out precomputed joins?   And are we absolutely
> sure we don't want indexing? It seems important, couldn't we make geo
> optional?
>
> Sent from my T-Mobile 4G LTE device
>
> ------ Original message------
> From: Puja Valiyil
> Date: Thu, Oct 6, 2016 10:52 AM
> To: [email protected];
> Cc:
> Subject:[DISCUSS] Path forward for release
>
> Hi everyone,
> Talking with Aaron, it seems like there were two paths forward for
> refactoring in order to create a release.  To refresh everyone's memory,
> the issue was that the geo-indexing extensions to Rya pull in geotools,
> which prohibits us from releasing Rya under an Apache 2 license.  There may
> be some more particulars that I'm glossing over -- someone please chime in
> if they feel it is key to the discussion.
> The two paths forward we had were:
> 1.  Make all of the indexing project and its downstream dependencies
> optional and exclude them from a release
> -- The indexing project includes several "optional" extensions to Rya
> (advanced indexing strategies).  Prior to Rya becoming an apache project,
> these indexing extensions were optional and there was a separate profile
> for including them.  This option involves reverting back to that mindset.
> The main argument against this is that these indexing strategies/extensions
> are not in fact optional but are "core" to Rya and can't be excluded.
>
> 2.  Refactor Rya to pull geoindexing into a separate project and exclude
> that project from the release.
> - We could refactor Rya to have geoindexing be its own project and add a
> profile to include that in the build.  This would invovle moving the class
> mvm.rya.indexing.GeoIndexer and packages mem.rya.indexing.accumulo.geo and
> mvm.rya.indexing.mongodb.geo to a separate project and then removing/moving
> references to geoindexing anywhere else.  Another option is to refactor the
> GeoIndexer interface to remove the geotools dependency.
>
> I think #1 is a good immediate path for a release and that #2 is a good
> longer term path forward.  Since it's probably in our best interests as a
> community to get an apache release sooner rather than later, I'd rather us
> go with #1 since it would quicker.  I also think that most users of Rya
> would be ok with excluding the indexing project since it is not core
> functionality for Rya.  While #2 is a better long term plan, it involves
> some pretty extensive refactoring that would be difficult to do well in a
> timely manner.
>
> Any thoughts?
>



-- 
Dr. Adina Crainiceanu
Associate Professor, Computer Science Department
United States Naval Academy
410-293-6822
[email protected]
http://www.usna.edu/Users/cs/adina/

Reply via email to