;> build perspective -- have an optional build profile -- and should not
> be
> >>> built and deployed by default.
> >>>
> >>> What we are currently working on is making geoindexing optional from a
> >>> build perspective. We're separating it out
t;>> built and deployed by default.
> >>>
> >>> What we are currently working on is making geoindexing optional from a
> >>> build perspective. We're separating it out from the indexing project
> so
> >>> that it can have its own, option
er.
From: Josh Elser [els...@apache.org]
Sent: Monday, October 10, 2016 10:26 AM
To: dev@rya.incubator.apache.org
Subject: Re: [DISCUSS] Path forward for release
Ok, I put some more thought into this one because it wasn't sitting
right with me. I think
that it can have its own, optional build profile. If what I said above is
>> correct, it seems like there is no way around this, other than making the
>> entire indexing project optional. But that would be like throwing the baby
>> out with the bath water.
>> ___
orrect, it
seems like there is no way around this, other than making the entire indexing
project optional. But that would be like throwing the baby out with the bath
water.
From: Josh Elser [els...@apache.org]
Sent: Monday, October 10, 2016 10:26 AM
To: dev
t to make
>> the indexes pluggable.
>>
>>
>>
>> Sent from my Verizon 4G LTE smartphone
>>
>>
>> Original message
>> From: Josh Elser
>> Date: 10/8/16 3:54 PM (GMT-05:00)
>> To: dev@rya.incubator.apache.org
>>
PM (GMT-05:00)
To: dev@rya.incubator.apache.org
Subject: Re: [DISCUSS] Path forward for release
Venkatesh is right in that the only "official" release in the ASF's eyes
is the source release. Any JARs you publish are supplementary and
technically not subject to the rules of Apache
smartphone
Original message
From: Josh Elser
Date: 10/8/16 3:54 PM (GMT-05:00)
To: dev@rya.incubator.apache.org
Subject: Re: [DISCUSS] Path forward for release
Venkatesh is right in that the only "official" release in the ASF's eyes
is the source release.
indexing in an effort to carry
out 2. Going forward it might be best to make the indexes pluggable.
Sent from my Verizon 4G LTE smartphone
Original message
From: Josh Elser
Date: 10/8/16 3:54 PM (GMT-05:00)
To: dev@rya.incubator.apache.org
Subject: Re: [DISCUSS] Path forward for
Venkatesh is right in that the only "official" release in the ASF's eyes
is the source release. Any JARs you publish are supplementary and
technically not subject to the rules of Apache releases.
The area I'm still trying to fully grok is that the source-release you
publish must also create ar
I created a pull request with #2 implemented. Any comments would be
appreciated.
https://github.com/apache/incubator-rya/pull/101
On Fri, Oct 7, 2016 at 11:06 AM, Puja Valiyil wrote:
> Hey,
> I started trying to implement #2. Give me 10 minutes and I'll push it and
> you can start from there.
Hey,
I started trying to implement #2. Give me 10 minutes and I'll push it and
you can start from there.
Sorry I should have communicated that earlier in this thread.
On Fri, Oct 7, 2016 at 11:01 AM, Aaron D. Mihalik
wrote:
> Okay, I'm going to take another shot at the "profile" solution and re
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
I'm fine with that.
On Fri, Oct 7, 2016 at 9:29 AM, Aaron D. Mihalik
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:3
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 wrote:
The reasoning here is not the query based inference-- it is the e
I second Puja's confusion. I've been going off this article [1] from
gnu.org:
"""
The LGPL and Java
...
The typical arrangement for Java is that each library an application uses
is distributed as a separate JAR (Java Archive) file. Applications use
Java's “import” functionality to access classe
I don't think I follow. The source references an lgpl Api, and we are
publishing binary that references it in nexus. Are you sure it's not an issue?
Sent from my iPhone
> On Oct 6, 2016, at 10:36 PM, Seetharam Venkatesh wrote:
>
> If it's a runtime dependency, you are fine. Apache only supp
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 proj
If it's a runtime dependency, you are fine. Apache only supports source
releases. We vote on source tar ball and not binary artifacts.
Makes sense?
Sent from my iPhone,
Venkatesh
> On Oct 6, 2016, at 12:40 PM, David Lotts wrote:
>
> Yes, geotools is a runtime dependency. No geotools source
incubator.apache.org
Subject: Re: [DISCUSS] Path forward for release
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):
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 refer
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 (binar
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 wrote:
>
> Hi everyone,
> Talking with Aaron, it seems like there were two paths forward for
> refactoring
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 devi
> From: Puja Valiyil
> > Date: Thu, Oct 6, 2016 10:52 AM
> > To: dev@rya.incubator.apache.org;
> > Cc:
> > Subject:[DISCUSS] Path forward for release
> >
> > Hi everyone,
> > Talking with Aaron, it seems like there were two paths forward for
> > refact
?
>
> Sent from my T-Mobile 4G LTE device
>
> -- Original message--
> From: Puja Valiyil
> Date: Thu, Oct 6, 2016 10:52 AM
> To: dev@rya.incubator.apache.org;
> Cc:
> Subject:[DISCUSS] Path forward for release
>
> Hi everyone,
> Talking with Aaron, it seems li
0:52 AM
To: dev@rya.incubator.apache.org;
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
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 ma
28 matches
Mail list logo
