Okay, I'm going to take another shot at the "profile" solution and remove tinkerpop.rya. I'll post the PR to the dev list and give let people comment on the PR. I'll look at PR over the weekend if if there aren't any issues, I'll pull it into apache master on Sunday.
--Aaron On Fri, Oct 7, 2016 at 10:42 AM Puja Valiyil <puja...@gmail.com> wrote: > I'm fine with that. > > On Fri, Oct 7, 2016 at 9:29 AM, Aaron D. Mihalik <aaron.miha...@gmail.com> > wrote: > > > Can we remove tinkerpop.rya? I thought that this was part of the query > > based reasoning, but the inference engine / rya.sail does not have a > > dependency on rinkerpop.rya. > > > > --Aaron > > > > > > On Fri, Oct 7, 2016 at 7:39 AM Puja Valiyil <puja...@gmail.com> wrote: > > > > The reasoning here is not the query based inference-- it is the external > > reasoner that runs on map reduce. > > I need to double check but I think the dependency is due to referencing a > > config Utilities class that should be in accumulo Rya not in indexer. So > > moving a single class to a different project will likely fix a lot of > this. > > > > Sent from my iPhone > > > > > On Oct 6, 2016, at 10:16 PM, Aaron D. Mihalik <aaron.miha...@gmail.com > > > > wrote: > > > > > > After reviewing the PR that David submitted, it's concerning the number > > of > > > projects that would fall into this "optional" bin. Some users probably > > > consider these "core" functions (e.g. reasoning and web): > > > > > > Here the modules that need to be removed from the build in order to > > remove > > > the geotools references: > > > > > > mapreduce > > > indexing > > > rya.indexing.pcj > > > indexingExample > > > rya.pcj.fluo > > > tinkerpop.rya > > > web.rya > > > rya.reasoning > > > rya.console > > > rya.merger > > > > > > --Aaron > > > > > >> On Thu, Oct 6, 2016 at 3:41 PM David Lotts <dlo...@gmail.com> wrote: > > >> > > >> Yes, geotools is a runtime dependency. No geotools source code is > > >> distributed. > > >> > > >> By that I mean: Geotools source code is not in our source code > > repository. > > >> Only references: imports in our *.java files and dependencies entries > in > > >> our pom.xml. Because of this maven will package geotools JARs > > (binaries) > > >> in our shaded/uber JAR and WAR files that we distribute. > > >> > > >> With option 1 or 2 as discussed, maven will exclude the geotools jars > in > > >> our JARs and WARs. Users of Rya can follow some instructions that we > > >> provide to add "-P indexing" (or similar) to their Maven build command > > >> create their own jar/war containing the optional Rya features and > > geotools > > >> binaries. > > >> > > >> Your "you should be okay." mean which of these???? > > >> A. option 1 and option 2 will work around the issue and we should > > proceed > > >> before we release, > > >> - OR - > > >> B. We are already in compliance and this is not a blocker for release > > as > > >> long as we are not redistributing geotools source code. > > >> > > >> Hopeful for interpretation B, but expecting and happy with A. > > >> > > >> david. > > >> > > >> On Thu, Oct 6, 2016 at 1:22 PM, Seetharam Venkatesh < > > vseetha...@gmail.com > > > > > >> wrote: > > >> > > >>> Quick question - geotools is a runtime dependency? Are you shipping > the > > >>> source code? If not, you should be okay. > > >>> > > >>> Sent from my iPhone, > > >>> Venkatesh > > >>> > > >>>> On Oct 6, 2016, at 7:52 AM, Puja Valiyil <puja...@gmail.com> wrote: > > >>>> > > >>>> 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? > > >> > > >
