GitHub user ajs6f opened a pull request:
https://github.com/apache/commons-rdf/pull/43
COMMONSRDF-49: Make AbstractRDFParser serializable
Very simple approach-- I just exposed the values of the fields internally
and made the accessors keep producing `Optional`. My understanding is
Github user ajs6f commented on the issue:
https://github.com/apache/commons-rdf/pull/43
From my POV, serializing a parser is useful for very long or very large ETL
when you may need to either pause and resume parsing (persisting the state of
the task in between) or move parsing tasks
Github user ajs6f commented on the issue:
https://github.com/apache/commons-rdf/pull/43
Well, it's hard for me to say, because I'm trying to predict the
architecture of a system I am only beginning to design. :(
@afs, @sebbASF, how about I break out a separat
GitHub user ajs6f opened a pull request:
https://github.com/apache/commons-rdf/pull/44
COMMONSRDF-70: Upgrade Jena version to 3.5.0
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ajs6f/commons-rdf COMMONSRDF-70
Alternatively
Github user ajs6f commented on the issue:
https://github.com/apache/commons-rdf/pull/44
Definitely can wait. There's no substantive API changes at stake, and
anyone who wants to use Jena 3.5.0 w/ Commons RDF should be able to override
the transitive dependency without untoward e
Github user ajs6f commented on the issue:
https://github.com/apache/commons-rdf/pull/43
My impression is that @afs objects to the current design, but I haven't
heard feedback on [my
suggestion](https://github.com/apache/commons-rdf/pull/43#issuecomment-3417
Github user ajs6f commented on the issue:
https://github.com/apache/commons-rdf/pull/44
ð
---
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h
Github user ajs6f commented on the issue:
https://github.com/apache/commons-rdf/pull/43
So the question is whether what is here now is a step forward.
I think it is, and I would want to do what is here whether or not we go
onto a builder factoring. I intentionally did not add
Github user ajs6f commented on the issue:
https://github.com/apache/commons-rdf/pull/43
I'd like to get @wikier an answer to his question. It sounds like we are
_not_ comfortable merging this for `RC2` and he should go ahead without it,
correct?
If the consensus is
Github user ajs6f commented on the issue:
https://github.com/apache/commons-rdf/pull/43
ð
---
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h
Github user ajs6f commented on the issue:
https://github.com/apache/commons-rdf/pull/43
@wikier My sense is that the right move here immediately is to merge this
PR and then open a ticket to factor config (and a builder therefor) out of
`AbstractRDFParser`. (A ticket I will be happy
GitHub user ajs6f opened a pull request:
https://github.com/apache/commons-rdf/pull/46
Add .DS_Store to .gitignore (Mac OS X system file)
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ajs6f/commons-rdf patch-1
Alternatively
: "10.12.6", arch: "x86_64", family: "mac"
NOTICE and LICENSE present, although the NOTICE has "Copyright 2015-2016",
which I think we can update...
ajs6f
> On Nov 20, 2017, at 9:46 AM, Aaron Coburn wrote:
>
> [X] +1 Release this package
Stian--
Just a quick technical question (really my own curiosity): I see you built with
`mvn clean install -T1.0C` (explicitly calling out the thread count). Is that
for reproducibility or some other reason?
ajs6f
> On Dec 6, 2017, at 7:59 AM, Stian Soiland-Reyes wrote:
>
> Go
+1 (non-binding) for release
Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T15:39:06-04:00)
Java version: 1.8.0_65, vendor: Oracle Corporation
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
Nice he
GitHub user ajs6f opened a pull request:
https://github.com/apache/commons-rdf/pull/48
Cleanup in commons-rdf-rdf4j to close PMD and FindBugs warnings
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ajs6f/commons-rdf
GitHub user ajs6f opened a pull request:
https://github.com/apache/commons-rdf/pull/49
Cleanup for FindBugs and PMD warnings in -simple and -jena
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ajs6f/commons-rdf
GitHub user ajs6f opened a pull request:
https://github.com/apache/commons-rdf/pull/50
Cleanup for PMD warnings in -rdf-api
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ajs6f/commons-rdf CleanupAPI
Alternatively you can
I have some PRs in now for some of these issues, which I mention merely as
reassurance that they will get looked at.
ajs6f
> On Dec 21, 2017, at 1:45 PM, Jörg Schaible wrote:
>
> Hi Bruno,
>
> Am Wed, 13 Dec 2017 09:53:35 + schrieb Bruno P. Kinoshita:
>
> [snip]
>
GitHub user ajs6f opened a pull request:
https://github.com/apache/commons-rdf/pull/52
Adding convenient Dataset and DatasetGraph conversions
PR for COMMONSRDF-74.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ajs6f/commons-rdf
Github user ajs6f commented on the issue:
https://github.com/apache/commons-rdf/pull/46
Is there any problem with merging this? Is there anything I can do to move
it along?
---
-
To unsubscribe, e-mail: dev
Github user ajs6f commented on the issue:
https://github.com/apache/commons-rdf/pull/48
@wikier I've got a triple of PRs here to clean up warnings, as we heard
about last release. Is there a problem with merging them? Is there something I
should do to help them merge-able? T
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/commons-rdf/pull/49#discussion_r168260775
--- Diff:
commons-rdf-simple/src/main/java/org/apache/commons/rdf/simple/experimental/AbstractRDFParser.java
---
@@ -58,8 +60,12 @@
*/
public
Github user ajs6f commented on the issue:
https://github.com/apache/commons-rdf/pull/43
Hm... if @afs and @stain are both feeling reluctant to go this way... I
would still be happy to merge it as-is and then work forward to the fluent-ish
factory design (since @ansell has given a
Github user ajs6f commented on the issue:
https://github.com/apache/commons-rdf/pull/43
Okay, I'll get to work on factoring out a (serializable) factory. Thanks
for the discussion everyone! I think the parser types will be much stronger fo
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/commons-rdf/pull/49#discussion_r168275645
--- Diff:
commons-rdf-simple/src/main/java/org/apache/commons/rdf/simple/experimental/AbstractRDFParser.java
---
@@ -58,8 +60,12 @@
*/
public
Perhaps ?
ajs6f
> On Feb 23, 2018, at 12:12 PM, Gary Gregory wrote:
>
> On Fri, Feb 23, 2018 at 10:05 AM, Gary Gregory
> wrote:
>
>>
>>
>> On Fri, Feb 23, 2018 at 10:04 AM, Gary Gregory
>> wrote:
>>
>>>
>>>
>>>
> On Mar 8, 2018, at 8:33 AM, Gilles wrote:
> Would it be useful (and interesting as part of GSoC work) to
> establish
> (1) which tools requires fixing,
> (2) prepare enhancement requests for the respective projects,
> and in the meantime, adapt the "Commons" build (with a "JDK 9"
> profile)
> (3
project will have been a success. With respect, I think you are now objecting
to a project that hasn't actually been proposed, for which success would be
releasing MR JARs. _That is not what is being proposed._
ajs6f
-
> On Mar 8, 2018, at 12:48 PM, Gary Gregory wrote:
> On Thu, Mar 8, 2018 at 10:29 AM, Gilles
> wrote:
>> Then these modules can define "module-info" files, and an actual build will
>> prove that the dependencies are as expected.
>>
> As Ralph as pointed out, you cannot generate a module-info f
> On Mar 12, 2018, at 1:13 PM, Ralph Goers wrote:
>
>
>
>> On Mar 12, 2018, at 9:27 AM, Jörg Schaible wrote:
>>
>> Hi Ralph,
>>
>> On Wed, 07 Mar 2018 11:56:32 -0700 Ralph Goers wrote:
>>>
>>> Actually, you really do need to use a multi-release jar to include a
>>> module-info class file.
> On Mar 13, 2018, at 11:20 AM, Gilles wrote:
>
>
> I didn't find it very easy to cooperate with developers who fork on GitHub
> and submit PRs. I've now found the "git" command that creates a branch from a
> PR, but it would be so much more comfortable to just switch directory and do
> "git
this happens to you, you can still rebase
and force-push the PR branch, and then Apache's mirroring will catch up and
close the PR "posthumously". Or of course you can always close it manually on
Github.
I make this mistake about once a month or so. :(
ajs6f
> On Mar 14, 2018,
For at least some cases, this wouldn't be good for security. I would prefer
that this be configurable (via HttpClientBuilder and/or system props) and not
the default.
ajs6f
> On Mar 29, 2018, at 6:20 PM, Gary Gregory wrote:
>
> Hi All:
>
> Right now, the HttpClient is of
I have asked INFRA about this (for another project) and they confirmed that
GitBox runs the mirroring Github => Apache, so that PRs can be merged at
Github. I did not ask about whether commits can also be pushed directly to
Apache.
ajs6f
> On Apr 22, 2018, at 3:03 PM, Matt Sicker
+1
ajs6f
> On May 18, 2018, at 5:50 PM, Bruno P. Kinoshita wrote:
>
> No objections from me. +1
>
> Sent from Yahoo Mail on Android
>
> On Sat, 19 May 2018 at 9:24, Gary Gregory wrote:
> Hi All:
>
> Eclipse is moving to SHA-256 to validate downloads [
the artifacts is ensured by the GPG signatures.
>
> Emmanuel Bourg
True, but there's a considerable portion of users who check the checksums and
nothing else.
ajs6f
-
To unsubscribe, e-mail: dev-unsubscr...@comm
+1. Unless there is a specific reason to incur a merge commit, it's generally
noise.
ajs6f
> On Jun 9, 2018, at 5:03 AM, Bruno P. Kinoshita
> wrote:
>
> Hi Pascal,
>
> Apache OpenNLP uses that approach whenever possible
> (http://opennlp.apache.org/using-git
this period" does seem a bit surprising, but I did
not notice it at all before Gilles' remark.
ajs6f
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
I would rather see a more complete offering with the other types in
j.u.function, i.e. Consumer, Supplier, Predicate, the various
primitive-specialized types...
ajs6f
> On Nov 24, 2018, at 6:58 AM, Pascal Schumacher
> wrote:
>
> Hi Aleksander,
>
> thanks.
>
> Imh
most of us have written them for ourselves at some point, which
makes them a good candidate for Commons), but I've found that generally I end
up with clearer code if I can use an idiom more specific to the task.
ajs6f
> On Nov 24, 2018, at 8:46 AM, Aleksander Ściborek
> wrote:
&g
Please do! This is a pretty common need and it would be nice to present a
really well-designed set of types for it.
ajs6f
> On Nov 29, 2018, at 2:41 PM, Aleksander Ściborek
> wrote:
>
> Ok, so I'm going to continue snd in the near future I will create pull
> request w
Since each Commons component is released separately, each can have its own
plan.
ajs6f
> On Fri, Nov 30, 2018, 8:46 AM Hannes H.
>> Hi,
>>
>> I am talking about Apache Commons in general and its approach to Java
>> modules which came with JDK 9 (project Jigsaw).
&g
Github user ajs6f commented on the issue:
https://github.com/apache/commons-rdf/pull/32
I suppose I incline to (2) right now. The "magic" URIs are entirely
Jena-specific, so ideally they appear as few places outside of Jena code itself
as possible. On the
GitHub user ajs6f opened a pull request:
https://github.com/apache/commons-rdf/pull/41
COMMONSRDF-65
https://issues.apache.org/jira/browse/COMMONSRDF-65
Also a small fix for problems building on Mac, and includes
https://github.com/apache/commons-rdf/pull/39/ to fix
Github user ajs6f commented on the issue:
https://github.com/apache/commons-rdf/pull/41
No, there were no relative URIs being parsed into `Path`s in my code-- that
string munging was to remove the `<` and `>` around the URI as retrieved from
the RDF. But I'm a-okay with wh
46 matches
Mail list logo
