Jenkins now requires Java-8 as its base runtime environment on the
regular release channel, with its LTS channel moving to Java-8 in a
few weeks:
https://jenkins.io/blog/2017/04/10/jenkins-has-upgraded-to-java-8/
That one bit me, as there is a bug updating on older Ubuntu versions
that don't carr
Feel free to merge your changes into Tika to update the barebones
implementation I contributed there:
https://github.com/apache/tika/blob/master/tika-java7/src/main/java/org/apache/tika/filetypedetector/TikaFileTypeDetector.java
Cheers,
Peter
On 16 March 2017 at 14:46, Schalk Cronjé wrote:
> I
An example from Google of a custom Java-7 file system provider (Apache
licensed) which may also be useful is at:
https://github.com/google/jimfs
Cheers,
Peter
On 16 March 2017 at 14:12, Matt Sicker wrote:
> Ralph has mentioned in the past an idea about rewriting commons-vfs using
> java.nio.fi
On 9 February 2017 at 13:38, Stian Soiland-Reyes wrote:
> Peter Ansell raised a valid question about why in Commons RDF I made the
> RDFParser interface as an immutable factory-like builder pattern.
>
> https://commons.apache.org/proper/commons-rdf/apidocs/org/apache/commons/rdf/
omplex and fixed to a particular use case, per its
use of Future. My main comment is that I would prefer if there were
either example code on how to use an ExecutorService to implement
asynchronous parsing, or a helper utility, rather than it being
required by the core API.
Cheers,
Peter
On 9 Febru
written a more detailed discussion of why abstract tests for
> interfaces pose problems (
> https://www.linkedin.com/pulse/contract-testing-why-abstract-tests-enough-claude-warren-jr).
> I stand by my earlier assertions and offers.
>
> Claude
>
> On Sun, Jan 29, 2017 at 5:11 AM,
On 28 January 2017 at 21:08, Claude Warren wrote:
> I see that RDF Commons is listed as a set of interfaces to be implemented
> on top of various RDF implementations. I also see that there are abstract
> tests for the interfaces.
>
> I would like to suggest that RDF commons look at using Junit Co
On 28 November 2016 at 10:51, Gary Gregory wrote:
> On Sun, Nov 27, 2016 at 3:41 PM, sebb wrote:
>
>> On 27 November 2016 at 22:31, Gary Gregory wrote:
>> > On Sun, Nov 27, 2016 at 2:14 PM, sebb wrote:
>> >
>> >> On 27 November 2016 at 22:03, Gary Gregory
>> wrote:
>> >> > These annotations ar
On 28 November 2016 at 10:41, sebb wrote:
> On 27 November 2016 at 22:31, Gary Gregory wrote:
>> It is _because_ they are NOT built-in the language or JRE that we are
>> proposing they belong in [lang].
>>
>> Since we are providing the annotation with CLASS retention only
>> (initially), there is
itHub and Maven have different
>> > > Markdown flavours, link is instead:
>> > >
>> > >
>> > > https://commonsrdf.incubator.apache.org/userguide.html#
>> > Finding_an_RDF_implementation
>> > >
>> > > As noted in there, c
intermediate
> 0.4.0 under Commons? Just similar reviews would be a large help!
>
> On 16 Nov 2016 10:25 pm, "Peter Ansell" wrote:
>
>> Hi Stian,
>>
>> I personally don't think Commons RDF is ready for a 1.0.0 release. The
>> APIs have still been c
Hi Stian,
I personally don't think Commons RDF is ready for a 1.0.0 release. The
APIs have still been changing recently and many of my comments on pull
requests, both when I was an active member and recently reviewing the
still evolving RDF4J integration, have been deferred to the future and
they
Hi Gary,
There is support for java.util.ServiceLoader with the relevant
META-INF/services files and default constructors, detailed in the
userguide.md file currently, but could also be in README.md:
https://github.com/apache/incubator-commonsrdf/blob/master/src/site/markdown/userguide.md#Finding_
On 15 September 2016 at 18:34, Stian Soiland-Reyes wrote:
> On 15 Sep 2016 5:11 a.m., "Peter Ansell" wrote:
>> One of the original goals was to help with migration and
>> interoperability so if it doesn't then things would need to be
>> reworked on the Com
JSONLD-Java switched to JsonLd, after originally using uppercased
versions, to match the terminology casing used by the final
JSON-LD-API-1.0 specification:
https://www.w3.org/TR/json-ld-api/#the-application-programming-interface
The capitalisation in the project name is just kept for posterity a
On 15 September 2016 at 12:49, Stian Soiland-Reyes wrote:
> On 13 Sep 2016 5:14 a.m., "Peter Ansell" wrote:
>> Sesame-4 will not have any more releases due to the Eclipse migration,
>> so you will not have a large user-base for that. Even maintaining a
>> Sesa
Hi Stian,
Sesame-4 will not have any more releases due to the Eclipse migration,
so you will not have a large user-base for that. Even maintaining a
Sesame-2.8 module may not find many users, as users who are still
using it for the near future will likely not be migrating to Java-8
and hence won't
The ability to push Lambda's into a CSV processing library, to avoid
users having to implement a "while(hasNext())" loop
correctly/efficiently each time shouldn't underestimated. I have
written a utility method myself to do this for my projects. It uses
Jackson CSV right now but the pattern should
urable. Each operating system (and OS version) could have different
> mappings for these roots.
>
> Cheers,
>
> Mark
>
>
> On Wed, Jun 1, 2016 at 4:02 PM, Peter Ansell wrote:
>
>> On 2 June 2016 at 01:48, Mark Fortner wrote:
>> > There was some discussio
at makes commons-vfs act as an NIO2 file system
>> provider, but you might be aiming in the opposite direction.
>>
>>
>> On Wed, Jun 1, 2016 at 7:02 PM, Peter Ansell
>> wrote:
>>>
>>> On 2 June 2016 at 01:48, Mark Fortner wrote:
>>>>
>
On 2 June 2016 at 01:48, Mark Fortner wrote:
> There was some discussion during the last release about a NIO-compatible
> version of VFS. This raised a few questions in my mind.
>
>1. Is there a branch where this work should start?
>2. Are there any specific API proposals, if so where are
On 3 February 2016 at 11:30, Patrick Meyer wrote:
> The Apache commons math library already has a reputation and is well kvown.
> Any name that does not involve the words Apache and math will require a lot
> of rebranding or years of explaining to people that the TLP named X is
> really just the l
On 25 November 2015 at 09:29, Emmanuel Bourg wrote:
> Le 24/11/2015 22:06, Thomas Neidhart a écrit :
>
>> If the idea is to roll out a bugfix release that people are awaiting
>> then I do not see the point in updating the minimum java version and
>> changing the code to use new language / jdk feat
On 7 November 2015 at 03:17, Phil Steitz wrote:
> Here is an idea that might break our deadlock re backward
> compatibility, versioning and RERO:
>
> Agree that odd numbered versions have stable APIs - basically adhere
> to Commons rules - no breaks within 3.0, 3.1, ..., 3.x... or 5.0,
> 5.1... bu
On 9 November 2015 at 09:21, Thomas Neidhart wrote:
> Hi all,
>
> please review the proposed fix for this issue here:
>
> http://svn.apache.org/viewvc?view=revision&revision=1713307
Those changes look workable to me. The main issue from my reading is
that real users of serialisation with InvokerT
On 19 September 2015 at 20:32, Kristian Rosenvold wrote:
> The next release is binary compatible except for *1* method that has
> been added to a (fairly infrequently used) interface. Does that still
> mean I should burn 2.5 and go for 3.0. And would that be 3.0 or 3.0.0
> ?
If you are thinking a
On 6 May 2015 at 01:51, Jörg Schaible wrote:
> Hi Benedikt,
>
> Benedikt Ritter wrote:
>
>> 2015-05-05 14:52 GMT+02:00 Benedikt Ritter :
>>
>>> Hello Jörg,
>>>
>>> 2015-05-05 8:30 GMT+02:00 Jörg Schaible :
>>>
Hi Benedikt,
brit...@apache.org wrote:
> Repository: commons-la
On 29 April 2015 at 23:51, Mark Thomas wrote:
> On 29/04/2015 14:18, Benedikt Ritter wrote:
>> 2015-04-29 15:00 GMT+02:00 Peter Ansell :
>>
>>> Hi,
>>>
>>> All pull requests are manually merged by a committer and then pushed
>>> to git-wip-
On 29 April 2015 at 22:52, James Carman wrote:
> On Wed, Apr 29, 2015 at 7:37 AM Jörg Schaible
>>
>>
>> But then you rely on the fact, that everyone has such a setting. I've
>> already seen pull requests containing such files. It does not happen if the
>> .gitignore is local.
>>
>>
> I'm with Jörg
Hi,
All pull requests are manually merged by a committer and then pushed
to git-wip-us. The git-wip-us repository is then automatically
mirrored back to GitHub. GitHub will then automatically close the Pull
Request when they see that there is a merge commit that combines the
commits from the Pull
On 13 April 2015 at 19:21, Benedikt Ritter wrote:
> 2015-04-13 2:27 GMT+02:00 Matt Benson :
>
>> +1 to what Peter said: it's a functional interface so it is
>> lambda-compatible anyway.
>>
>
> Well, yes it would be a functional interface, but it would lack all the
> default methods defined in java
On 14 April 2015 at 01:16, Reto Gmür wrote:
> On Sat, Apr 11, 2015 at 12:39 PM, Peter Ansell
> wrote:
>
>> On 11 April 2015 at 22:11, Reto Gmür wrote:
>> > On Mon, Mar 30, 2015 at 2:07 PM, Benedikt Ritter
>> wrote:
>> >
>> >> Hello Ret
On 12 April 2015 at 21:14, Benedikt Ritter wrote:
> Hi,
>
> there is currently a discussion on github about the addition of a low level
> utility class which helps to retrieve Threads [1]. The latest proposal is to
> implement a predicate based approach for filtering threads [2]. My opinion
> i
On 12 April 2015 at 21:26, Benedikt Ritter wrote:
>
>
> Send from my mobile device
>
>> Am 12.04.2015 um 13:19 schrieb Kristian Rosenvold :
>>
>> If think later (in 2025 :-) you just make interface ThreadPredicate
>> extend java.util.function.Predicate.
>
> Well, isn't that exactly what I suggeste
On 11 April 2015 at 22:11, Reto Gmür wrote:
> On Mon, Mar 30, 2015 at 2:07 PM, Benedikt Ritter wrote:
>
>> Hello Reto,
>>
>> 2015-03-30 14:45 GMT+02:00 Reto Gmür :
>>
>> > Hi all,
>> >
>> > The clerezza commons RDF proposal that was in the sandbox and is now in
>> the
>> > clerezza-rdf-core repos
On 30 March 2015 at 23:45, Reto Gmür wrote:
> Hi all,
>
> The clerezza commons RDF proposal that was in the sandbox and is now in the
> clerezza-rdf-core repository has been changed to use
> org.apache.clerezza.commons-rdf.
>
> As you know if all goes well clerezza will be based in the result of t
Hi Phil,
In the past I have used something like "git checkout -b temp-backport
&& git rebase -i" to squash multiple backportable commits into a
single commit, and then it sometimes applies better (less conflicts in
some cases) than using cherry-pick on all of the individual commits.
However, that
On 18 February 2015 at 12:28, sebb wrote:
> On 17 February 2015 at 22:56, Peter Ansell wrote:
>> On 17 February 2015 at 21:48, sebb wrote:
>>> On 17 February 2015 at 06:13, Benedikt Ritter wrote:
>>
>>
>>
>>>> and the maven coordinates w
On 17 February 2015 at 21:48, sebb wrote:
> On 17 February 2015 at 06:13, Benedikt Ritter wrote:
>> and the maven coordinates when we break binary compatibility (= bump up the
>> major version number). We do this to avoid jar hell. This way two versions
>> of the same commons library can be in
Hi Bernard,
The Commons RDF project is not planning on including any non-trivial
implementations, to avoid bias towards any of the participating
platforms. Stian has written a trivial implementation and submitted it
to GitHub to provide a reference for our test harness, but it is never
planned to
On 15 February 2015 at 21:29, Benedikt Ritter wrote:
> We like to underline, that we have no experience with the RDF
> specification. From a technical point of view we can help to develop the
> proposed API (according to our design guide lines [3]).
Hi Benedikt,
On my personal projects I tend
On 16 February 2015 at 07:53, Reto Gmür wrote:
> My SMTP server was having some problems so the mail below was not posted.
>
> I've made some more commits today with some initial code of a Sparql backed
> implementation, but the interesting bits are still missing
>
>
> Cheers,
> Reto
>
> On Su
On 24 January 2015 at 01:12, Reto Gmür wrote:
> Hi Minto
>
> Thanks for your comments.
>
>> 1) I am glad you chose to derive from Collections. This opens up the
>> > possibility to use Java 8 streams to improve performance especially
>> in
>> > the filter() method.
>> > 2) Hmm, is
On 1 February 2015 at 07:45, Reto Gmür wrote:
> In the clerezza code and in the SVN commons proposal code along the
> following lines will works as expected.
>
> {a,b,c,d,e} is a set of 5 BlankNodes (i.e. we have 5 objects, no two of
> them are equals).
>
> g.add(a, RDF.type, EX.Sphere);
> g.add(b
On 28 January 2015 at 20:53, Andy Seaborne wrote:
> On 27/01/15 17:11, Stian Soiland-Reyes wrote:
>>
>> I agree that "local scope" should be clarified
>
>
> "local scope" is a piece of terminology used only for RDF syntax. Once away
> from syntax, there is no "scope" to a blank node.
>
> It is de
Hi Stian and Reto,
Blank nodes are hard to support within a single system. They are
fairly close to unsustainable within a general system. However, within
a system that has RDF-1.1 as its theoretical basis, the W3C spec
defines the mapping functions that are necessary to define equivalence
between
On 20 January 2015 at 05:44, Jörg Schaible wrote:
> Hi Gilles,
>
> Gilles wrote:
>
>> On Mon, 19 Jan 2015 10:50:52 -0700, Phil Steitz wrote:
>>> On 1/19/15 10:33 AM, Gilles wrote:
On Mon, 19 Jan 2015 12:15:42 -0500, Gary Gregory wrote:
> On Mon, Jan 19, 2015 at 11:40 AM, Phil Steitz
>
The Clerezza team were all notified about the effort to put a common
RDF API together on GitHub and they responded positively at that
point. The only sticking point then and now IMO is the purely academic
distinction of opening up internal labels for blank nodes versus not
opening it up at all. Ret
On 22 July 2014 22:17, Gary Gregory wrote:
> I just saw my name pop up here: Yes we will help from infra with JIRA and
> using Git is fine as long as it is hosted at Apache and not GitHub. We
> still have to use Subversion for publishing the site and the release files
> of course, this is an Apach
for it here. There
>>>> is, however, a process for accepting a software grant, which in this
>>>> case we are going to have to follow, since the initial code was
>>>> developed outside the ASF (i.e., not under the oversight of an ASF
>>>> PMC, unless
On 21 July 2014 22:14, Sergio Fernández wrote:
> Hi Emmanuel,
>
> On 21/07/14 14:05, Emmanuel Bourg wrote:
>>
>> If I understand well this is a kind of specification API? The actual
>> implementations will be done in Jena/Marmotta/OpenRDF?
>
>
> With the current scope yes, that the overall idea. B
51 matches
Mail list logo
