Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/133
I think we're all probably familiar with he semantics of `AutoCloseable`.
Examine the API note: for "... facilities... that support ... I/O-based and
non-I/O-based forms, try-with-resources
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/157
I think we are getting into the realm of premature optimization at this
point. My inclination is to merge this as-is, given that we have no evidence of
real performance problems.
---
If your project
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
But since that construct goes via `HttpClientCOntext`, doesn't that take us
back to methods with `HttpContext` as a parameter? Or am I misunderstanding the
suggestion?
---
If your project is s
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/157
We could have a note of that on the contributions page, if that seems
useful. It seems a little oblique to me to tell people to grep the mailing
lists for information like that.
---
If your project is
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/159
Sure, but unless you object, I don't think it can hurt to be even more
specific, with some brief phrases like "The methods in this class treat all
types of Model in the same way. For behavio
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/159
Okay, cool, in that case maybe we can put a couple of comments into
`RdfDataMgr` to indicate that it can only ever do the "vanilla" stuff, and that
if you expect action associated with a parti
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/159
This makes sense-- one question: currently `RdfDataMgr.read(Model m, etc)`
falls through to `RdfDataMgr.read(m.getGraph(), etc)`. Should it be changed to
call `Model.read`?
---
If your project is set
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/157
Yeah, I can see how some kind of "moving to phase X" signaling could be
real handy. I'm not familiar enough with the query machinery to understand
where that should live, though. I thi
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/157
Okay, but just to be clear, that is faster by the "right" amount? In other
words, if you trigger a really really long sort and immediately abort, it
more-or-less immediately aborts?
-
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/157
This looks a lot better to me. Do you want to do anything with the idea of
`Arrays.parallelSort`, or leave that for work that is future, if ever?
---
If your project is set up for it, you can reply to
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/157
No, I think you are right. It's actually pretty much a classic use case for
volatile, and the semantics of the class are not dependent on volatility, more
the correctness. I'd use it.
-
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/157
Yeah, the fact that multiple threads are not just reading but might be
_writing_ the value really does make an `AtomicBoolean` make sense here. On the
other hand, there are no compound atomic operations
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/157
Yeah, the fact that multiple threads are not just reading but might be
_writing_ the value really does make an `AtomicBoolean` make sense here.
---
If your project is set up for it, you can reply to
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/157
I have spent a lot of time thinking hard about this kind of stuff, only to
find I haven't thought as long or as hard as the folks who work on the JVMs and
compilers. {grin}
---
If your project i
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/157
The most cost a `volatile` usually incurs is a few times the time to
retrieve the value (and I shouldn't think that happens normally on x86 archs,
see [here](http://gee.cs.oswego.edu/d
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/157#discussion_r71346429
--- Diff:
jena-arq/src/main/java/org/apache/jena/atlas/data/AbortableComparator.java ---
@@ -0,0 +1,93 @@
+/*
+ * Licensed to the Apache Software
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/157#discussion_r71348900
--- Diff:
jena-arq/src/main/java/org/apache/jena/atlas/data/AbortableComparator.java ---
@@ -0,0 +1,93 @@
+/*
+ * Licensed to the Apache Software
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/157
I'm not sure what the point of the periodic cancellation checking machinery
is. It seems like it is left over from your diagnostics. It doesn't seem to
save any time, because the t
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/157#discussion_r71347034
--- Diff:
jena-arq/src/main/java/org/apache/jena/atlas/data/AbortableComparator.java ---
@@ -0,0 +1,93 @@
+/*
+ * Licensed to the Apache Software
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/157#discussion_r71170120
--- Diff:
jena-arq/src/main/java/org/apache/jena/atlas/data/SortedDataBag.java ---
@@ -69,19 +69,81 @@
protected final ThresholdPolicy policy
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/157#discussion_r71167748
--- Diff:
jena-arq/src/main/java/org/apache/jena/atlas/data/SortedDataBag.java ---
@@ -69,19 +69,81 @@
protected final ThresholdPolicy policy
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/157#discussion_r71167237
--- Diff:
jena-arq/src/main/java/org/apache/jena/atlas/data/SortedDataBag.java ---
@@ -69,19 +69,81 @@
protected final ThresholdPolicy policy
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/157#discussion_r71161082
--- Diff:
jena-arq/src/main/java/org/apache/jena/atlas/data/SortedDataBag.java ---
@@ -69,19 +69,81 @@
protected final ThresholdPolicy policy
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/157#discussion_r71160809
--- Diff:
jena-arq/src/main/java/org/apache/jena/atlas/data/SortedDataBag.java ---
@@ -69,19 +69,81 @@
protected final ThresholdPolicy policy
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
@rvesse -- Does @afs 's plan to offer methods that accept
`HttpClientBuilder` meet your concerns about supporting complex authN scenarios?
---
If your project is set up for it, you can reply to
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
Okay, so we should be able to treat 'HttpClientBuilder' as a kind of config
object. Set one up and pass it in the way you would pass in config (including
authN).
---
If your project is set
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
One question with passing in a builder is the extent to which clients will
be reusable. Perhaps that's where setting a default client or using the
custom-client-per-service feature (available now)
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
@afs Said "(It seems odd that the can't get the setting out of an
HttpClient to feed into a builder.)"
YES. It is _intensely_ annoying. It seems like a massive oversight to me,
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
@afs Yes, the addition of `HttpOp` methods as you describe is what I was
thinking of. Not too much there, but enough to let people move their own
`HttpContext`s around, which would be pretty darn handy
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/154#discussion_r70663415
--- Diff:
jena-tdb/src/main/java/org/apache/jena/tdb/transaction/TransactionManager.java
---
@@ -436,8 +469,96 @@ public void notifyAbort(Transaction
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
@paulhoule One difficulty with `HttpRequestInterceptor` is a good thing to
bring up-- in the newer HTTP Commons client APIs, clients are immutable and if
you want to add, e.g., interceptors, you need to
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
@paulhoule There is `org.apache.http.HttpRequestInterceptor`, which I think
is what HTTP Commons itself supplies for that kind of purpose. But there are
also a host of parts built into the rest of the
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
@rvesse : Basically, I think we share the same picture of the situation. I
wouldn't claim that this new API presents quite the same "ergonomics" as what
we now have. I think the heart o
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/151#discussion_r70630354
--- Diff:
jena-arq/src/main/java/org/apache/jena/sparql/engine/http/HttpQuery.java ---
@@ -298,6 +292,19 @@ public InputStream exec() throws QueryExceptionHTTP
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
Right, I think we're fine as long as Jena itself is actually the client
(e.g. as part of `SERVICE` action in a query). It was the situation in which
some app is using HTTP via `HttpOp` in which an
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/133
Would that (new API) look like a set of wrappers? Or perhaps a method on
`Model` that reflects the instance into an `AutoCloseable` subtype of `Model`?
---
If your project is set up for it, you can
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
Reading through the current HTTP Commons docs leaves me with the impression
that we do not need to close clients after use in `HttpOp`, but that we do need
to see to it that _responses_ are closed
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
[A useful description of
`HttpContext`.](https://hc.apache.org/httpcomponents-client-ga/tutorial/html/fundamentals.html#d5e223)
---
If your project is set up for it, you can reply to this email and
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/153
Okay, so the appropriateness of `finally` depends on where you are (app vs.
system code). Makes sense.
---
If your project is set up for it, you can reply to this email and have your
reply appear on
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/95
So the caching in this scenario, @afs, would be handled by
`QueryEngineHTTP`/`QueryExecutionBase`?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/153
We usually use `try-finally` for the transaction cycle, i.e.
```
try {
transactionalThing.begin(readWrite);
//do some stuff
transactionalThing.commit(); // if a write
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/153
Thanks, @afs , that definitely helps. IIUC, `ThreadTxn` looks like kind of
a "single-class" version of the mechanics in `Txn`?
---
If your project is set up for it, you can reply to this emai
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/153#discussion_r70181662
--- Diff: jena-arq/src/main/java/org/apache/jena/system/ThreadTxn.java ---
@@ -0,0 +1,148 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
I'm imagining a bag of new methods in `HttpOp` similar to what's there now,
with the additional `HttpContext` param, and the methods that are now there
would call through those new methods
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
As I understand it (for what that's worth) `HttpContext` is mostly about
the idea of a "conversation", so if you've got some kind of session going on,
or a series of request-response
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
I'm not totally clear about the style for `CloseableHttpClient`, either.
I'll poke around and see if I can get a better reading on that. And I'll start
jotting up some docs.
---
If your
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/152#discussion_r70116076
--- Diff: jena-arq/src/main/java/org/apache/jena/sparql/graph/GraphOps.java
---
@@ -29,60 +29,49 @@
import org.apache.jena.sparql.core.Quad
GitHub user ajs6f opened a pull request:
https://github.com/apache/jena/pull/151
FCREPO-576: Moving away from deprecated HttpCommons Client API
This is a bit of a shake-up in the HTTP machinery, but as per discussion
with @afs , a "big bang" discarding the use of mu
GitHub user ajs6f opened a pull request:
https://github.com/apache/jena/pull/142
Version bumps
There are two commits in this PR. The first, I think, should be entirely
straightforward. The second contains a minor version bump for `mrunit`. In
order to do this, I updated
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/139#discussion_r62355638
--- Diff:
jena-arq/src/test/java/org/apache/jena/riot/writer/TestJsonLDWriter.java ---
@@ -0,0 +1,457 @@
+/*
+ * Licensed to the Apache Software
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/139#discussion_r62354809
--- Diff: jena-arq/src/main/java/org/apache/jena/riot/out/JsonLDWriter.java
---
@@ -79,26 +130,85 @@ public void write(OutputStream out, DatasetGraph
dataset
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/95#issuecomment-213500724
On the question of conditional-GET, there has been some
[discussion](https://pony-poc.apache.org/thread.html/Zdrf49p8jphmwje) about
ETags in this connection that might be
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/95#issuecomment-213468612
:+1: @osma++
Part of the takeaway here for me is that when it comes to caching bits,
we're unlikely ever to do as well as specialist tools that have been care
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/95#issuecomment-212574529
@samaitra
`ResultSetMem` speaks to your problem of exhaustion. It caches the results
in the heap and can be "rewound" and even O(1) copied.
---
If your
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/95#issuecomment-212502652
Ooh, sorry-- didn't catch that about SELECT-only.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/95#issuecomment-212405267
Another +1 to @osma's comments. In re: serialization: it seems to me that
the need here is for "replay-ability". Certainly serialization will do that,
but
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/136#discussion_r60235133
--- Diff: jena-arq/src/main/java/org/apache/jena/riot/system/RiotLib.java
---
@@ -73,12 +78,37 @@ public static Node createIRIorBNode(String iri
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/136#discussion_r60233218
--- Diff: jena-arq/src/main/java/org/apache/jena/riot/system/RiotLib.java
---
@@ -73,12 +78,37 @@ public static Node createIRIorBNode(String iri
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/136#discussion_r60230353
--- Diff: jena-arq/src/main/java/org/apache/jena/riot/system/RiotLib.java
---
@@ -73,12 +78,37 @@ public static Node createIRIorBNode(String iri
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/136#discussion_r60229859
--- Diff: jena-arq/src/main/java/org/apache/jena/riot/system/RiotLib.java
---
@@ -73,12 +78,37 @@ public static Node createIRIorBNode(String iri
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/134#discussion_r59385695
--- Diff:
apache-jena-osgi/jena-osgi/src/main/java/org/apache/jena/osgi/Activator.java ---
@@ -0,0 +1,47 @@
+package org.apache.jena.osgi;
+
+import
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/134#discussion_r59058484
--- Diff:
apache-jena-osgi/jena-osgi/src/main/java/org/apache/jena/osgi/Activator.java ---
@@ -0,0 +1,47 @@
+package org.apache.jena.osgi;
+
+import
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/134#issuecomment-207436679
Dexx Collections has released a `0.6` with OSGi metadata, and I've updated
https://github.com/apache/jena/pull/135 to refer to it, so if we order that PR
before thi
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/134#discussion_r58941531
--- Diff:
apache-jena-osgi/jena-osgi/src/main/java/org/apache/jena/osgi/Activator.java ---
@@ -0,0 +1,47 @@
+package org.apache.jena.osgi;
+
+import
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/134#issuecomment-206902158
Marvelous! I'll circle back with them and with any luck, we'll get a
release eftsoons with the new metadata.
---
If your project is set up for it, you can rep
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/134#issuecomment-206524142
Dexx Collections has
[merged](https://github.com/andrewoma/dexx/commit/7d0f242e64679b4f3fd4a5ee0598d29852df49ce)
my PR to give OSGi metadata to their Java artifact. They
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/134#issuecomment-206462555
I've sent an [issue](https://github.com/andrewoma/dexx/issues/6) and
[PR](https://github.com/andrewoma/dexx/pull/7) to Dexx Collections to get the
OSGi metadata in
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/135#issuecomment-206452035
Oops, disregard previous comment: I misunderstood some advice from the Dexx
Collection maintainers and upgraded somehow to a Kotlin version of the library
instead of the
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/135#issuecomment-206447863
This PR would pull in Kotlin's runtime to the dependencies, because Dexx
Collections has moved to Kotlin for current versions. Obviously, that warrants
discu
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/134#issuecomment-206433254
No, it's not the _presence_ of MAINFEST.MF (which I think tends to appear
in pretty much any JAR or WAR). It's what's in it. There are specific headers
in
GitHub user ajs6f opened a pull request:
https://github.com/apache/jena/pull/135
JENA-1160: Upgrade Dexx Collections version
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ajs6f/jena JENA-1160
Alternatively you can review and
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/134#issuecomment-206409700
OSGi requires some [metadata](https://en.wikipedia.org/wiki/OSGi#Bundles)
to work, found in the `MANIFEST.MF` in `META-INF`. Most projects have that
auto-created at
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/134#issuecomment-205975853
To create the OSGi bundle for Dexx, did you use any tooling, or just insert
a manifest manually? I'd like to send them a PR (or of course, you can :) ).
---
If
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/134#issuecomment-205975604
Track the Dexx release at: https://github.com/andrewoma/dexx/issues/5 /
https://issues.apache.org/jira/browse/JENA-1160
---
If your project is set up for it, you can reply
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/134#issuecomment-205400464
I will try and contact the maintainers of Dexx Collections to see if we can
get a properly OSGI-ified release there. Also, they appear to have released a
new version 0.5
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/133#issuecomment-204807713
The semantics of `AutoCloseable#close` are "Closes this resource,
relinquishing any underlying resources." The semantics of `Model#close` are
"â¦_free_ up
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/131#discussion_r57891292
--- Diff:
jena-text/src/test/java/org/apache/jena/query/text/TestDatasetWithAnalyzingQueryParser.java
---
@@ -0,0 +1,64 @@
+/**
+ * Licensed to the
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/131#discussion_r57889145
--- Diff:
jena-text/src/test/java/org/apache/jena/query/text/TestDatasetWithAnalyzingQueryParser.java
---
@@ -0,0 +1,64 @@
+/**
+ * Licensed to the
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/128#discussion_r55197295
--- Diff:
jena-arq/src/main/java/org/apache/jena/riot/system/FactoryRDFCaching.java ---
@@ -0,0 +1,110 @@
+/*
+ * Licensed to the Apache Software
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/128#discussion_r55195827
--- Diff:
jena-arq/src/main/java/org/apache/jena/riot/system/FactoryRDFCaching.java ---
@@ -0,0 +1,110 @@
+/*
+ * Licensed to the Apache Software
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/128#discussion_r55195636
--- Diff:
jena-arq/src/main/java/org/apache/jena/riot/system/FactoryRDF.java ---
@@ -0,0 +1,56 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/123#discussion_r52173358
--- Diff:
jena-fuseki2/jena-fuseki-core/src/main/java/org/apache/jena/fuseki/build/RefCountingMap.java
---
@@ -0,0 +1,187 @@
+/**
+ * Licensed to the
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/123#discussion_r52172791
--- Diff:
jena-fuseki2/jena-fuseki-core/src/main/java/org/apache/jena/fuseki/build/DescriptionToDatasetMap.java
---
@@ -0,0 +1,48 @@
+/**
+ * Licensed
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/120#issuecomment-177313470
Sorry on both counts. `SimpleMap*` is leakage from JENA-1084. My Git-fu
failed. I thought I had kept that work separate.
---
If your project is set up for it, you can
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/123#issuecomment-174658906
Is there any understanding about the sharing of components between the
results of calls to the various forms of `Assembler::open`?
---
If your project is set up for it
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/120#issuecomment-174581614
@afs I've renamed/moved types according to proposal 1.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as wel
GitHub user ajs6f opened a pull request:
https://github.com/apache/jena/pull/124
Add Javadoc for Assembler indicating that Model values are advisory
Attempting to capture @afs's comment
[here](https://github.com/apache/jena/pull/123#issuecomment-174306928) as
advice i
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/123#issuecomment-174311885
There has been some
[discussion](http://markmail.org/message/6uab6glusw7lqpmz) about the
commonalities between `jena-text` and `jena-spatial`. Is the same problem
likely
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/123#issuecomment-174311642
Thanks for the clarification re: `Mode`. Should the Javadocs for `Mode` say
that something like that it "advises implementations of user intention, but
does not cons
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/123#issuecomment-174299109
Just as a sidenote, isn't `org.apache.jena.assembler.Mode` intended to
control whether new things are created or old things are reused during the
assembly?
---
If
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/123#discussion_r50548291
--- Diff:
jena-text/src/main/java/org/apache/jena/query/text/TextDatasetFactory.java ---
@@ -191,5 +213,50 @@ public static DatasetGraph
createSolrIndex
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/123#discussion_r50546226
--- Diff:
jena-text/src/main/java/org/apache/jena/query/text/assembler/TextIndexLuceneAssembler.java
---
@@ -61,7 +74,12 @@ public TextIndex open(Assembler a
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/123#discussion_r50542029
--- Diff:
jena-text/src/main/java/org/apache/jena/query/text/TextDatasetFactory.java ---
@@ -191,5 +213,50 @@ public static DatasetGraph
createSolrIndex
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/123#discussion_r50541229
--- Diff:
jena-text/src/main/java/org/apache/jena/query/text/assembler/TextIndexLuceneAssembler.java
---
@@ -61,7 +74,12 @@ public TextIndex open(Assembler a
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/123#discussion_r50540841
--- Diff:
jena-text/src/main/java/org/apache/jena/query/text/assembler/TextIndexLuceneAssembler.java
---
@@ -123,10 +141,35 @@ public TextIndex open(Assembler a
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/123#discussion_r50538211
--- Diff:
jena-text/src/main/java/org/apache/jena/query/text/TextIndexLucene.java ---
@@ -399,4 +404,24 @@ private Node entryToNode(String v
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/123#discussion_r50538146
--- Diff:
jena-text/src/main/java/org/apache/jena/query/text/assembler/TextIndexLuceneAssembler.java
---
@@ -47,8 +59,9 @@
text:entityMap <#end
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/123#discussion_r50537882
--- Diff:
jena-text/src/main/java/org/apache/jena/query/text/TextIndexLucene.java ---
@@ -399,4 +404,24 @@ private Node entryToNode(String v
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/120#issuecomment-172877393
I'm happy to do whatever will get this merged and move on. I chose the
prefix names and not the numerical suffix names because that is what Java does
in
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/119#issuecomment-170371507
But `getOrFill` is not new with Java 8, is it?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your
701 - 800 of 1081 matches
Mail list logo
