Andy,
I'll bring this back to our legal, but they told me that apparently, when
a project in Apache releases, Apache has done the appropriate internal
legal review and makes certain guarantees. I do not know if that "internal
legal review" happens in practice, but for IBM that makes a big
diff
On Thu, Sep 13, 2012 at 5:25 AM, Marco Neumann wrote:
> On Thu, Sep 13, 2012 at 8:19 AM, Andy Seaborne wrote:
>
>> On 12/09/12 23:10, Marco Neumann wrote:
>>
>>> I would say yes the interesting bits are done by JTS. we used another LGPL
>>> index for geosparql.org.
>>>
>>> I think Jena deserves a
[
https://issues.apache.org/jira/browse/JENA-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454963#comment-13454963
]
Francesco Panico commented on JENA-201:
---
FusekiConfigurator.java class loads "fuseki-c
I definitely agree that the concept of RC cycles is good in principle,
but I don't know if lightweight will do for us. As I explained before,
we can only get comprehensive testing done with versions of Jena which I
can safely deliver in our main source control stream. Because we publish
milestone
[
https://issues.apache.org/jira/browse/JENA-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454932#comment-13454932
]
Simon Helsen commented on JENA-289:
---
Discussed it offline with Mark. The real problem is t
[
https://issues.apache.org/jira/browse/JENA-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454928#comment-13454928
]
Mark Buquor commented on JENA-289:
--
After further internal discussion, we've determined tha
Thanks Andy.
So the overall response times were only a bit faster as I mentioned (about
6%), but overall write activities were significantly faster as was to be
expected given the changes made there, in some cases 40%
So yes, I definitely understand that there are aspects which cannot
possibly
[
https://issues.apache.org/jira/browse/JENA-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Buquor updated JENA-289:
-
Priority: Critical (was: Major)
> Respect query timeouts in TDB implementation
> -
On Thu, Sep 13, 2012 at 8:19 AM, Andy Seaborne wrote:
> On 12/09/12 23:10, Marco Neumann wrote:
>
>> I would say yes the interesting bits are done by JTS. we used another LGPL
>> index for geosparql.org.
>>
>> I think Jena deserves a dedicated file based indexer to support the full
>> OGC geospar
On 12/09/12 23:10, Marco Neumann wrote:
I would say yes the interesting bits are done by JTS. we used another LGPL
index for geosparql.org.
I think Jena deserves a dedicated file based indexer to support the full
OGC geosparql standard but that said the task should not be underestimated.
(a ce
[
https://issues.apache.org/jira/browse/JENA-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454817#comment-13454817
]
Andy Seaborne commented on JENA-201:
This patch is really useful to have and it has help
On 12/09/12 20:49, Simon Helsen wrote:
On the testing front, we just got one of our clients to run a
scalability test (meaning they run with a large starting repository and
fire up multiple users to perform read/write activities) and they have not
observed any regressions compared to 2.7.1 and a
On 12/09/12 17:58, Rob Vesse wrote:> I plan to take a look at the Fuseki
as a WAR again at some point but am
> fairly snowed under at the moment
You are not alone ...
Also it's a non-trivial change which may also require some maven and
svn shenanigans if we want to generate both a WAR and the
Hi Rob
(a bit out of the loop at the moment, however) do you know if there is
any GeoSPARQL open source implementation around we could look at?
One useful thing to do would be go to through the GeoSPARQL spec and
make a list of the FILTERs which need to be implemented.
What is not "trivial" IMHO i
14 matches
Mail list logo
