Re: Preparing for Jena5 - API deprecations
+1. Clean it out! Adam On Mon, Jul 24, 2023, 1:36 PM Andy Seaborne wrote: > Another item for deprecation-removal. > > Model.query(Selector) and all the Selector code. > > Nowadays, JDK java can cleanly do filtering and there is SPARQL for > anything more complex. > > Andy >
Re: Suggestions for changes to code file layout
+1 to that note, and +1 to git rm. Adam On Sun, Sep 11, 2022, 7:23 PM Bruno Kinoshita wrote: > Looks good to me! +1 > > On Mon, 12 Sept 2022 at 09:18, Andy Seaborne wrote: > > > Like this? > > > > https://github.com/afs/jena/blob/reorg/archived-modules.md > > > > On 10/09/2022 13:30, Andy Seaborne wrote: > > > > > > > > > On 09/09/2022 00:17, Bruno Kinoshita wrote: > > >> Sounds good. > > >> > > >> Is there a reason for not removing the directories, instead of moving > to > > >> archive? If we have a note in the README telling users who came > > >> looking for > > >> these modules that they are now in the archive folder; we could > instead > > >> tell them to use git? Maybe point to the last commit or tag, use a > > GitHub > > >> link, etc? > > > > > > No specific reason except it's just a "git mv". > > > > > > We could have a single file that takes the information already in the > > > separate README files. > > > > > > They have date of retirement and git commit for the last code before > git > > > rm. Also text in most of them: > > > """ > > > Retired modules can be incorporated back into Jena releases if there is > > > sufficient activity to maintain the code over the long term. > > > """ > > > > > > Andy > > > > > >> > > >> Thanks > > >> Bruno > > >> > > >> On Thu, 8 Sept 2022 at 23:29, Andy Seaborne wrote: > > >> > > >>> 1/ We have a number of retired modules: > > >>> > > >>> apache-jena-osgi > > >>> jena-csv > > >>> jena-elephas > > >>> jena-fuseki1 > > >>> jena-maven-tools > > >>> jena-sdb > > >>> jena-spatial > > >>> jena-text-es > > >>> > > >>> Each has a README that explains how to retrieve the code from git. > > >>> > > >>> That's 8 of total of 29 top level modules. > > >>> > > >>> Proposal: move these in an "archive/" directory. > > >>> > > >>> > > >>> 2/ Move jena-tdb2 up to the top level from inside jena-db/ to make it > > >>> more findable. (After PR #1514 which makes > > >>> > > >>> > > >>> 3/ It is tempting to change jena-tdb/ directory to jena-tdb1/ (maven > > >>> artifact not renamed) as well for clarity. > > >>> > > >>> > > >>> Andy > > >>> > > >> > > >
Re: [Draft] Apache Jena report - 2022-04
+1, thanks Andy! Adam On Sun, Apr 3, 2022, 7:19 AM Andy Seaborne wrote: > > ## Description: > The mission of Jena is the creation and maintenance of software related > to Java framework for building Semantic Web applications > > ## Issues: > There are no issues requiring board attention. > > ## Membership Data: > Apache Jena was founded 2012-04-18 (10 years ago) > > There are currently 18 committers and 14 PMC members in this project. > The Committer-to-PMC ratio is 9:7. > > Community changes, past quarter: > - No new PMC members. Last addition was Aaron Coburn on 2019-01-22. > - No new committers. Last addition was Greg Albiston on 2019-07-08. > > ## Project Activity: > Jena 4.4.0 was released 2022-02-02. > > Key features of this release: > > * New triplestore (Apache Jena Fuseki) UI. The UI has been rewritten for >improved maintenance and style. We now have much better management of >dependencies, as witnessed by security advisories on the github >repository. > > * Improved bulk loader. The database bulk loader has fixes and >performance refinements. It has been used to load the full WikiData >dataset. This has been a community effort to test and load large scale >data in different hardware environments. > > ## Community Health: > The development community has decided to enable some github features > (issues and discussions areas) and reorganise the mailing lists. The > dev@ mailing list was primarily JIRA messages; these have been rerouted > to a specific jira@. > > We hope that having the github features will make it easier for external > feedback and contributions. The existing channels of feedback and > contribution continue - nothing has been closed down. > > The level of email on the dev@ list will fall dramatically. This will > show up in next quarter's report. > > We hope this makes it easier for people to observe the project and also > have project-wide discussions without the JIRA emails dominating the list. >
Re: Towards Jena 4.3.0
+1 indeed. Adam On Wed, Nov 17, 2021, 4:33 PM Bruno P. Kinoshita wrote: > >Does that fit with PMC members? > +1 > Thanks Andy! > Bruno > > On Wednesday, 17 November 2021, 11:09:35 pm NZDT, Andy Seaborne < > a...@apache.org> wrote: > > We're a little way from the clock tick - 3 months would be 16/Dec. > > From my point of view, it would be nice to release early to mid > December rather than the run up to Christmas. > > Does that fit with PMC members? > > Andy > > Resolved tickets for 4.3.0: > https://s.apache.org/jena-4.3.0-jira > > Jenkins: > https://ci-builds.apache.org/job/Jena/ > > and the additional CI builds on Windows and MacOS pass. > https://github.com/apache/jena/actions > > Contributions: > > Jan Martin Keil > JENA-2169: Blank node graph names in Dataset interface > > Erich Bremer > Update EnhGraph.java > > Stefan Obermeier > JENA-2195: Include jena-examples in build > > jena-site: > Michael Wechner > @den1s0v > Robin Vobruba > > Main Items: > > java.net.http > > HTTP usage provided by the JDK java.net.http package, with > challenge-based authentication provided on top by Jena. > > Rework SPARQL client APIs using HTTP code (query, update GSP). > > SPARQL APIs > > * Execution objects (QueryExecution, UpdateExecution, RDFConnection) > have a companion builders for detailed configuration. Previous factory > classes remain but builders are preferred. > > This is especially important for HTTP as there many configuration > options that may be needed (including template queries). > > https://jena.apache.org/documentation/sparql-apis/#changes > > Epic: JENA-2125 > > Internal reorg: > > https://lists.apache.org/thread.html/r02f8938a5fea60f6dd1781dabcb81862abebd19052b076fad57340db%40%3Cusers.jena.apache.org%3E > > If apps use methods that have Apache HttpClient arguments (HttpClient, > HttpContext), they will be affected. > > xloader > > TDB1 and TDB2 loader for billion+ triples on a modest machine. > > JENA-2175 > xloader > tdbloader2 renamed. tdb1.xloader > tdb2.xloader > > Retire OSGi artifacts > JENA-2165 > > jena-examples > Consolidate ARQ/TDB/ShEx/SHACL and RDFConnection examples >
Re: [DRAFT] Apache Jena report - 2021-10
+1 indeed, thanks Andy! Adam On Thu, Sep 30, 2021, 5:44 PM Bruno P. Kinoshita wrote: > +1 > Thanks! > > On Friday, 1 October 2021, 10:34:51 am NZDT, Andy Seaborne < > a...@apache.org> wrote: > > ## Description: > The mission of Jena is the creation and maintenance of software related > to Java framework for building Semantic Web applications > > ## Issues: > There are no issues requiring board attention. > > ## Membership Data: > Apache Jena was founded 2012-04-18 (9 years ago). > There are currently 18 committers and 14 PMC members in this project. > The Committer-to-PMC ratio is 9:7. > > Community changes, past quarter: > - No new PMC members. Last addition was Aaron Coburn on 2019-01-22. > - No new committers. Last addition was Greg Albiston on 2019-07-08. > > ## Project Activity: > Jena version 4.2.0 was released 2021-09-12. It fixed CVE-2021-39239, > which was discovered by the team, and affects all version 4.1.0 and > earlier. > > The release was not just about a CVE fix. The release included a new > component, a data validation engine for the ShEx language to go > alongside the SHACL engine; and also support for reading JSON-LD 1.1 > using an external 3rd party library. JSON-LD 1.1 is used by some IOT > device and service descriptions. > > During the release checking, a problem was discovered in the OSGi bundle > related to the new dependencies for JSON-LD 1.1 handling. The project > dropped the OSGi convenience binaries, and a discussion has started > about retiring them. The development community no longer has the skills, > nor interest, necessary to maintain their production. Contact with known > downstream open source projects, and a message to users@ has not > produced any concern. > > Jena has a process for retiring modules - delete in git, record the last > git commit with the code in case some interest emerges and will maintain > the module. > > ## Community Health: > Activity seems normal. Some of the figures are slightly skewed because > one PR had 48 commits which is unusual for Jena. > > The dev@ list is also the destination of JIRA email and is otherwise > quite quiet. The speed of evolution of the project is down to developer > time. > > The users@ is active and the main support channel. >
Re: [DRAFT] Apache Jena report - 2021-07
+1, thanks Andy! Adam On Fri, Jul 9, 2021, 10:43 AM Andy Seaborne wrote: > ## Description: > The mission of Jena is the creation and maintenance of software related > to Java framework for building Semantic Web applications > > ## Issues: > There are no issues requiring board attention. > > ## Membership Data: > Apache Jena was founded 2012-04-18 (9 years ago) > There are currently 18 committers and 14 PMC members in this project. > The Committer-to-PMC ratio is 9:7. > > Community changes, past quarter: > - No new PMC members. Last addition was Aaron Coburn on 2019-01-22. > - No new committers. Last addition was Greg Albiston on 2019-07-08. > > ## Project Activity: > > The project dealt with CVE-2021-33192. The project released 4.1.0 > slightly earlier than the usual cycle bu this was timely for both > addressing the CVE issue, where there isn't a simple works around in all > cases, and also tiding-up after the 4.0.0 release. 4.0.0 had some low > level changes that were not completely transparent to user applications. > > The move to requiring Java11 has been smooth. > > ## Community Health: > > Activity on mailing list and PRs have been quieter. There is no obvious > specific reason for this. Given the major version change reported last > report, "quiet" is probably a good thing with a slight reduction in open > JIRA tickets. > > -- > > The statistics: > > dev@jena.apache.org had a 25% decrease in traffic in the past quarter > (504 emails compared to 671) > > p...@jena.apache.org had a 46% decrease in traffic in the past quarter > (206 emails compared to 381) > > us...@jena.apache.org had a 26% decrease in traffic in the past quarter > (277 emails compared to 374) > > 38 issues opened in JIRA, past quarter (-39% change) > 58 issues closed in JIRA, past quarter (-3% change) > 172 commits in the past quarter (-29% change) >
Re: Problems Building Main
No, as Andy said, you must first run an 'install' to "bootstrap" the build. Then you can use other goals. Adam On Mon, May 10, 2021, 1:39 PM Merlin Bögershausen < merlin.boegershau...@rwth-aachen.de> wrote: > Hi, > On Mai 10 2021, at 6:12 pm, Andy Seaborne wrote: > > > > On 10/05/2021 16:19, Merlin Bögershausen wrote: > > > Hi, > > > for maven install (full log see attachments) it is: > > > > No attachments - the list software rejects them > > gist? > makes sence ;D see gist: > https://gist.github.com/MBoegers/81c4cfd9c029bf75f149f1201f2aa73d > > > Is this after a "mvn clean install -Pdev"? > No full install, but same result for -Pdev > > > That's solved by "mvn clean install" > >"mvn clean install -Pdev" is slightly faster and enough. > So running anything other than install is no Option? > >
Re: Java 8 or 11?
Is SDB perhaps another candidate for retirement? Adam On Wed, Jan 20, 2021, 2:21 PM Andy Seaborne wrote: > > On 01/01/2021 12:13, Andy Seaborne wrote: > > Should we switch to Java11? > > Proposal: > > > > 1/ Ask on users@ -- what we need is "new information" such as "I am > > blocked from updating Java because ...", not "I haven't got round to it". > > > > 2/ Switch to Java11 for the next release but not make so many changes > > that we can't easily go back to Java8. > > > > Andy > > The discussion on users@ > > > https://lists.apache.org/thread.html/re6bd2d266343a5dffc2b811df2ed63caea07196db42bb929a6b2fb7d%40%3Cusers.jena.apache.org%3E > > Points: > * bump to Jena4. > * request to keep a parallel 3.x branch (nice if resourced only if > resourced) > > If Jena4, then are there any things we can do which won't significant > impact the timescale - we can take longer of course but I think any > major work item that would need several additional months, and all the > risk of that slipping :-), really must be important. > > 1/ Mass removal of deprecated - a lot has been deprecated for many > versions so removing it a 4.x seems reasonable. I hope people have been > taking note but code can always return if necessary. > > 2/ Retire modules or remove code we do not want to migrate to Jena4, > especially as we can still include it again later if there is > unanticipated user demand. Again, a major version jump is a time to be > bold(er); all code has cost. > > jena-text-es is a candidate from my point of view. No one is maintaining > it and it is complicated to setup and support. > > Andy >
Re: Java 8 or 11?
+1. This will only get more pressing with time. Adam On Fri, Jan 1, 2021, 8:36 PM Bruno P. Kinoshita wrote: > I'm +1 for Java 11, and to go along with your plan. First message to > users with our intention, and asking for any known issues from their side. > > Bruno > > On Saturday, 2 January 2021, 1:13:39 am NZDT, Andy Seaborne < > a...@apache.org> wrote: > > Should we switch to Java11? > > There are the usually issues of moving to a newer Java. There seems > likely to be an emerging bimodal distribution of systems remaining with > Java8 and systems moving to Java11 and Java 17 (likely an LTS - > September 2021). > > The question is how many systems would upgrade their Jena version and > are restricted to Java8 (and why!). > > Java is evolving to better fit in the new tech landscape (e.g. better > container usage), more compact strings (significant for Jena), and > JDK-provided HTTP/2. > > Some dependences or potential dependencies are Java11: > > Titanium - for JSON-LD 1.1 (JENA-1948 - titanium-json-ld ) > > Eclipse Jetty 10 and 11 now depend on Java11. > > (the difference between Jetty 10 and Jetty 11 is that Jetty 10 uses the > package root name "javax..." whereas Jetty11 uses package route > "jakarta...") > > Proposal: > > 1/ Ask on users@ -- what we need is "new information" such as "I am > blocked from updating Java because ...", not "I haven't got round to it". > > 2/ Switch to Java11 for the next release but not make so many changes > that we can't easily go back to Java8. > > Andy >
Re: dependabot [was:Project items]
+1 If it's not useful we can turn it off. Adam On Tue, Nov 10, 2020, 12:28 PM Andy Seaborne wrote: > I'd like to add dependabot to the git repo to tell us about dependencies > updates. > > dependabot sends PRs to the project, including gathering documentation > and explanation if available so we get to review the proposed changes. > > I've a very simple setup on another project: > > https://github.com/afs/rdf-delta/blob/main/.github/dependabot.yml > > > The github documentation: > > > https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/keeping-your-dependencies-updated-automatically > > > The first time it runs we will likely get quite a few updates because we > have quite a few dependencies. > > We don't have to acceet the recommendations! > > Andy >
Re: RDF*
More later, just a quick note re:
> (ajs6f: Does JSON-LD 1.1 say anything about this?)
Nope, not a thing. If anything, the direction has been in the other
direction. E.g. 1.0 allows bnodes-as-predicates and we strongly discourage
that in 1.1-- pushing folks towards "vanilla" RDF.
Our next WG meeting is this Friday, and I am happy to raise any questions
we want raised, then or going forward.
Adam
On Mon, Apr 6, 2020, 4:10 PM Andy Seaborne wrote:
> WIP
>
> RDF* is adding triples-as-term to RDF so that you can annotate triples.
> This is not reification.
>
> Summary:
>
> * Aim to get it working for Turtle*, in-memory, SPARQL* and JSON results
> (Fuseki in other words).
> * "sometime"
> * This is not by converting to reification and back again!
> * Experimental - may change without warning.
>
> -
>
> Details of RDF*
>
>
> https://blog.liu.se/olafhartig/2019/01/10/position-statement-rdf-star-and-sparql-star/
> https://arxiv.org/pdf/1406.3399.pdf
>
> Example
> PREFIX : <http://example/>
>
> :s :p 123 .
> <<:s :p 123>> :q 678 .
>
>
> The RDF Triple term is <<:s :p 123>>.
>
> (it is lucky that early versions of SPARQL, pre 1.0, had <<>> for
> reification ... so the grammar works!)
>
> Currently working:
>Node_Triple
>Turtle* parsing
>Turtle* writing
>In-memory storage
>SPARQL syntax
>SPARQL execution with <> pattern matching.
>SPARQL text format output of result sets.
>Conversion to/from reification
>
> (it is lucky that early ideas for SPARQL, pre 1.0, had <<>> for
> reification ... so the grammar works!)
>
> including nested cases (yup: triple terms inside triple terms is legal:
> <<:s :p <<:s :p 123>> >> is legal).
>
> There are other areas impacted:
> Model API
> Result sets (JSON, XML)
> JSON-LD
> RDF/XML syntax
>
> and there is less degrees of freedom in design for compatibility reasons.
>
> Ideas:
>
> 1. API:
>
> RDF Triple terms can be in the subject position, so it is a Resource,
> even though they are really abstractly literals.
>
> Going through this list, 1.3 is my first choice at the moment.
>
> 1.1. Encoding
>
> Have special blank nodes or URI that carry the triple encoding information.
>
> Having some encoding as a fallback mechanism is probably wise. It is
> needed for RDF/XML, and may be N-triples.
>
> 1.2. Resource-Statement -- built-in
>
> To avoid a signature change, I think we can put it in Resource with
> "Resource::isTriple()" and "getTriple() -> Statement" with the goal of
> "no RDF* -> no impact".
>
> 1.3. Resource-Statement -- as(Statement.class)
>
> A case of Resource that is not a blank node nor a URI but can be used
> with RDFNode.as(Statement.class) to get the Statement. or even a blank
> node, that RDFNode.canAs(Statement.class) - sort of on the fly reification.
>
> 1.4. New RDFNode subclass.
>
> The ultimate "do it properly" - add a new kind of RDFNode - is an API
> change as the subject position changes. I don't see any compatibility
> path. Only consider when it is clear what a stable answer is.
>
> 2. Result sets
>
> I favour 2.1, together with switchable to "encoding", so that foreign,
> plain-RDF, code does work on SPARQL* results to some degree. That
> includes YASGUI.
>
> 2.1. "Do it properly"
>New term type:
> { "type": "triple" , "value": }
> and "value" is a JSON object
> {"subject": ... , "predicate": "object": }
>
> XML results is similar .. which is TriX format
>
>
>
> datatype="http://www.w3.org/2001/XMLSchema#integer;>123
>
>
> 2.2. An "Encoding" approach:
>
> { "type": "triple" , "value": "_encoding_" }
> and/or
> { "type": "uri" , "value": "encoding" }
>
>
> 3. RDF/XML
>
> Unlike Turtle* changing the syntax is impractical.
> Doing nothing is quite reasonable and wait to see what common practice
> emerges. Encoding works.
>
> 4. JSON-LD
>
> Encoding is probably the way to go.
> (ajs6f: Does JSON-LD 1.1 say anything about this?)
>
>
> Term encoding:
>
> It's going to be long! Prefixes can't be assumed to be present. It needs
> 3 components, and maybe a datatype or language. And so we need a
> separator/encoding of use of the separator.
>
> Andy
>
Re: JIRA and questions
+1. Maybe this could even be automated to a button on Jira? If not, perhaps
we can leave the template in our wiki.
Adam
On Wed, Apr 1, 2020, 7:59 AM Bruno P. Kinoshita
wrote:
> +1
>
> Sent from Yahoo Mail on Android
>
> On Wed, 1 Apr 2020 at 22:38, Andy Seaborne wrote:
> This is another not-an-issue question but sent to JIRA. It is not a bug,
> it is a question about how to use Jena. It is also unanswerable because
> of lack of detail.
>
> It is also a stackoverflow question from yesterday.
>
> This is the 3rd one in a week (one was actually about another system
> anyway) calling something a bug that are really about how to use Jena.
>
> Questions are not bugs.
> Neither are they "urgent".
> Often, the questioner does not respond and we get floating JIRA issues.
>
> They aren't going to get answered on JIRA so I think we should quickly
> close them for fear of getting swamped, referring to them to users@ e.g.
> boiler plate like:
>
> -
> Hi there,
>
> This is a question and is best sent to the Jena users mailing list.
>
> us...@jena.apache.org.
>
> You need to subscribe first, then respond to the verification email,
> then send your question:
>
> For details:
> https://jena.apache.org/help_and_support/index.html
> -
>
> Andy
>
> On 01/04/2020 10:01, David (Jira) wrote:
> > David created JENA-1876:
> > ---
> >
> > Summary: Parsing json-ld in Jena and type : rdfs:container
> does not come through as a statement
> > Key: JENA-1876
> > URL: https://issues.apache.org/jira/browse/JENA-1876
> > Project: Apache Jena
> >Issue Type: Bug
> >Components: Base
> > Reporter: David
> >
> >
> > I have a jsonld file that I am parsing using Jena. The file has @type
> @id "rdfs:label" and "rdfs:comment" and also ranges and domains. I have a
> test java program like this
> >
> > Model m = ModelFactory.createDefaultModel();
> >
> >
> >
> > {{Reader fileReader = new FileReader(fileName);
> > Model model = m.read(fileReader, null, "JSON-LD");
> > StmtIterator it = model.listStatements();
> > Set set = new HashSet<>();
> >
> > System.out.println("Labels");
> > while (it.hasNext()) {
> > Statement statement = it.next();}}
> >
> > It seems to pick up all the content but does not see the @type
> statements with rdfs:container. How do I pick up these statements using
> this parser?
> >
> > A fragment of the json-ld is \{ "@id": "aaa:bbb", "@type": [
> "rdfs:container" ], "rdfs:label": { "@language": "en", "@value": "" },
> "rdfs:comment": \{ "@language": "en", "@value": "." }, "rdfs:member": [
> \{ "@id": ":" }, \{ "@id": ":f" } ],
> >
> > When the type is rdfs:class - I get a statement coming through with
> predicate "type" and the object as the RDFClass, but when the type is
> rdfs:container - as in the above example I do not get a statement through.
> I was expecting a statement to come through with the predicate of "type"
> and a subject with localName of bbb and an object specifying the container
> class. I do not see such a statement. How to I detect in the parser that
> the presence of the rdfs:container? The presence of the container tag is
> very meaningful for our parser. We are looking at alternative ways of
> representing this sort of information in the model because of this issue.
> >
> > I notice Jena has the concept of Container : [
> https://jena.apache.org/documentation/javadoc/jena/org/apache/jena/rdf/model/Container.html].
> I can see write orientated methods that refer to this.
> >
> >
> >
> > --
> > This message was sent by Atlassian Jira
> > (v8.3.4#803005)
> >
>
>
Re: [VOTE][LAZY] Move from CMS/SVN to Hugo/Git
With the same interpretation, +1, and thanks very much to Roy for looking into this! ajs6f > On Feb 21, 2020, at 1:26 PM, Andy Seaborne wrote: > > Interpreting as a general "in principle" to move website content ... no > timeline and (obviously) subject to new information becoming available. > > +1 > > PMC - please vote and not leave to LAZY to indicate you are aware this is > work-in-progress. > >Andy > > On 19/02/2020 13:41, Roy Lenferink wrote: >> Hi Jena community, >> After last weeks proposal [1] I'd like to start a vote for moving over from >> the current Apache CMS >> (and SVN) to use Hugo and git :) >> Short recap about Hugo: Hugo is a static site generator which is already >> having more stars on >> GitHub than Jekyll. It is easy to get started with (single static binary >> without dependencies) and it is >> really doing well performance wise. >> [ ] +1 for moving over from the Apache CMS / SVN to Hugo / Git. >> [ ] 0 I don't have a strong opinion on this >> [ ] -1 for not moving over, in this case please explain why >> This vote will be open for the usual 72 hour period. Lazy consensus applies: >> if no -1 votes are being >> cast within the voting period, the vote passes. >> Best regards, >> Roy >> [1] >> https://lists.apache.org/thread.html/r1a46369ea6e9df4f0b0971934563b9e8433cb33fe42290240969bbe0%40%3Cdev.jena.apache.org%3E
Re: [] Apache Jena 3.14.0 RC 2
Sounds like nothing to worry about (wrt to my NOTICE question). ajs6f > On Jan 17, 2020, at 12:53 PM, Andy Seaborne wrote: > > Thanks for the vote. > > On 17/01/2020 15:58, ajs6f wrote: > >> I did notice: >>> Portions of this software are from Apache Xerces and were originally based >>> on the following: >>> - software copyright (c) 1999, IBM Corporation., http://www.ibm.com. >>> - software copyright (c) 1999, Sun Microsystems., http://www.sun.com. >> I haven't kept track of all of our moves around Xerces and its datatype >> code. Do we still need this, or did we excise all the Xerces-derived stuff? > > Jena has Xerces source code in it. Some of the datatype code was lifted from > Xerces. That's why NOTICE has that text, rather than a binary dependency on > Xerces. > > Nowadays, to avoid a binary dependency, Jena has the source code for all the > datatype machinery under "org.apache.jena.ext.xerces" without the XML parser. > Taken from 2.11.0. > > A binary dependency is a bit problematic using Jena as a library. > xercesImpl.jar has various ServiceLoader files. It will wire itself into the > JVM. > > So the whole application gets Jena's choice of XML parser. Not good. > And there is the recurrent matter of incorrectly repackage/shading jars. > > Extracting the datatype parts (which aren't huge and get called directly from > Jena anyway) and repackaging under "org.apache.jena.ext.xerces" means Jena > uses whatever XML parser the application chooses, including the JDK one > (which is a older fork of Xerces but then modified). No ServiceLoader. Helps > with OSGi as well. JENA-1537 lists a few issues that have come up over the > years. > >Andy > > > > >
Re: [VOTE] Apache Jena 3.14.0 RC 2
+1 binding. > + are the GPG signatures fine? > + are the checksums correct? > + is there a source archive? Yes x 3. > + can the source archive really be built? Yes. > + is there a correct LICENSE and NOTICE file in each artifact Looks good. I did notice: > Portions of this software are from Apache Xerces and were originally based on > the following: > - software copyright (c) 1999, IBM Corporation., http://www.ibm.com. > - software copyright (c) 1999, Sun Microsystems., http://www.sun.com. I haven't kept track of all of our moves around Xerces and its datatype code. Do we still need this, or did we excise all the Xerces-derived stuff? > + does the NOTICE file contain all necessary attributions? Seems to. > + have any licenses of dependencies changed due to upgrades? > if so have LICENSE and NOTICE been upgraded appropriately? Looks fine. > + does the tag/commit in the SCM contain reproducible sources? Yes. ajs6f > On Jan 16, 2020, at 12:34 PM, Andy Seaborne wrote: > > Hi, > > Here is a vote on the release of Apache Jena 3.14.0 > This is the second proposed release candidate. > > The deadline is only 72hours in case there are enough +1 votes and I can do > the final stage on Sunday - otherwise, it is likely to be mid next week. > > Changes from RC1: > > Fix for JENA-1817 > https://github.com/apache/jena/commit/08ca0b83 > > Changes for 3.14.0: > > https://s.apache.org/jena-3.14.0-jira > > Release Vote > > Everyone, not just committers, is invited to test and vote. > Please download and test the proposed release. > > Staging repository: > https://repository.apache.org/content/repositories/orgapachejena-1036 > > Proposed dist/ area: > https://dist.apache.org/repos/dist/dev/jena/ > > Keys: > https://svn.apache.org/repos/asf/jena/dist/KEYS > > Git commit (browser URL): > https://github.com/apache/jena/commit/d0abcd14 > > Git Commit Hash: > d0abcd14f82c36045a3c047941a6518f3bdb56ce > > Git Commit Tag: > jena-3.14.0 > > Please vote to approve this release: > >[ ] +1 Approve the release >[ ] 0 Don't care >[ ] -1 Don't release, because ... > > This vote will be open until at least > >Sunday, 19th January 2020 at 18:00 UTC > > If you expect to check the release but the time limit does not work > for you, please email within the schedule above with an expected time > and we can extend the vote period. > > Thanks, > > Andy > > Checking needed: > > + are the GPG signatures fine? > + are the checksums correct? > + is there a source archive? > > + can the source archive really be built? > (NB This requires a "mvn install" first time) > + is there a correct LICENSE and NOTICE file in each artifact > (both source and binary artifacts)? > + does the NOTICE file contain all necessary attributions? > + have any licenses of dependencies changed due to upgrades? > if so have LICENSE and NOTICE been upgraded appropriately? > + does the tag/commit in the SCM contain reproducible sources?
Re: Towards Jena 3.14.0
+1. A smaller bug is better than a bigger bug. ajs6f On Sun, Jan 12, 2020, 12:51 PM Andy Seaborne wrote: > One of those releases ... > > JENA-1813 came in and it's a bug. > > The proper, comprehensive fix is quite extensive, although it will > enable optimization in cases currently not handled. That is not > something I want to rush just before a release. > > There is a pragmatic fix suggested in Shawn's report. It fixes the > reported case. It (probably) isn't complete but more importantly it > shows there is a better design that does not avoid certain cases that > happen at the moment > > So my proposal is immediate fix for JENA-1813, release 3.14.0 > and fork off JENA-1815 for redesign/rework for a later release. > > No query that already works properly in 3.13.1 is affected. Some queries > that don't work will now work. > > Andy > > On 07/01/2020 13:57, Aaron Coburn wrote: > > I will have time to review any release candidates between now and Jan 20. > > > > Cheers, > > Aaron > > > > On Tue, 7 Jan 2020 at 08:37, Andy Seaborne wrote: > > > >> It's coming up to time to look at Jena 3.14.0. v3.13.1 was 2019-10-11. > >> > >> I have time between now and January 19th to do a release or to work with > >> anyone who is interested in performing a release. January 20th and after > >> is likely to be busy due to new employment. > >> > >> Andy > >> > >> == Contributions and notable JIRA > >> > >> Pavel Mikhailovskii: > >> JENA-1787: SHACL improvement > >> JENA-1786: DatasetGraphMonitor exposes unwrapped graphs > >> JENA-1785: TDB2 bug fix > >> JENA-1784: CacheSimple doesn't check keys for equality > >> > >> Ken Treimann: > >> JENA-1781: Thrift upgrade to 0.13.0 for a CVE. > >> > >> Georg Schmidt-Dumont: > >> JENA-1796: Add missing DV for XSD DateTimeStamp data type > >> > >> Adrian Wilke: > >> JENA-1792: DCat vocabulary update to DCat2 > >> > >> > >> JENA-1779: Update to Jackson 2.10.1 > >> > >> 2.10 has a design change to remove the 2.9.x attack point. > >> Hopefully, moving to 2.10 will mean the end of recurring CVE's for > Jackson. > >> > >> == JIRA > >> > >> https://s.apache.org/jena-3.14.0-jira > >> > >> 36 currently. > >> > >> > > >
Re: [DRAFT] Apache Jena - January 2020
+1. Thanks Andy! ajs6f > On Jan 8, 2020, at 10:12 AM, Andy Seaborne wrote: > > ## Description: > The mission of Jena is the creation and maintenance of software related to > Java framework for building Semantic Web applications > > ## Issues: > There are no issues requiring board attention. > > ## Membership Data: > > Apache Jena was founded 2012-04-18 (8 years ago) > There are currently 18 committers and 14 PMC members in this project. > The Committer-to-PMC ratio is 9:7. > > Community changes, past quarter: > - No new PMC members. Last addition was Aaron Coburn on 2019-01-22. > - No new committers. Last addition was Greg Albiston on 2019-07-08. > > ## Project Activity: > > Jena 3.13.1 was released on 2019-10-11. > > The project operates aspires to a releases every 3-4 months and is now > discussing the 3.14.0 this month, subject to PMC availability. > > The 3.14.0 has several contributions from new people, outside the main > committers. > > The project is also discussing reorganising its mailing lists to reduce the > volume on dev@ by moving github traffic to a separate list. The hope is that > with less low-level emails and pull request specific emails, it will > encourage discussion on the longer term direction of Jena. > > ## Community Health: > > Activity on the users@ and dev@ lists is about normal. The new people > contributing pull request is encouraging and hopefully some these people will > remain going forward. > > We expect a drop in dev@ email when the github traffic is directed to another > list. > > email: > dev@jena.apache.org same level: (566 compared to 562) > us...@jena.apache.org same label (291 emails compared to 292) > > JIRA: > 44 issues opened in JIRA, past quarter (12% increase) > 39 issues closed in JIRA, past quarter (18% increase) > > Github: > 49 PRs opened on GitHub, past quarter (36% increase) 46 PRs closed
Re: [VOTE] Split off GH PR email traffic to a new list.
+1. This would be great! Adam On Tue, Jan 7, 2020, 8:36 AM Andy Seaborne wrote: > Happy 2020 everyone. > > From the [DISCUSS] around: > > > https://lists.apache.org/thread.html/12988132a86780d1fc14c6f893099cac50875e1d04a360d6046fdc0a%40%3Cdev.jena.apache.org%3E > > here is the formal vote: > > Proposal: > This is the minimal proposal. > > > Ask INFRA for a new mailing list, "pr@", and route github repo email > currently going to dev@ to that list. > > > Please vote > > [ ] +1 Approve the proposal > [ ] 0 Don't care > [ ] -1 Don't make the change because ... > > > This vote is open to at least: > > Friday 2020-01-10 18:00 UTC. > > (for additional discussion either the [DISCUSS] thread or change > "[VOTE]" to "[]". > > Andy >
Re: Examples?
I completely agree about getting the examples all into one place. But I think I would rather fail the build when they fail to build, because I understand examples as a sort of very high-level test. If examples are not working we might want to disable some of them instead of investing a bunch of time fixing the specific problems, but wouldn't we want to know? ajs6f > On Dec 20, 2019, at 10:41 AM, Claude Warren wrote: > > I just finished an example of how to write a StreamRDF to an > RDFConnection. I placed this in the jena-examples project and update the > pom so that it tracks the jena version. > > I then noticed that the RDFConnections examples are in the jena-connections > main source tree. > > I think that all examples should go into the examples project so that > there is one place for users to go to get the example code. > > I also think that the examples project should be built after the main Jena > build (so that it does not cause the build to fail if the examples fail). > > Are there other thoughts about this? > > Claude > > -- > I like: Like Like - The likeliest place on the web > <http://like-like.xenei.com> > LinkedIn: http://www.linkedin.com/in/claudewarren
Re: [Discuss] Split the dev@ mailing list?
I'm +1 to splitting off pr@, -0 to splitting off issues@. I don't see that the gain is worth creating another list, managing more subscriptions, missing replies when they go to the wrong list, etc., but if other folks would like to try it, I'm not -1 against it. ajs6f > On Dec 13, 2019, at 10:07 AM, Andy Seaborne wrote: > > Adam - where are we on this? > > My understanding is that the difference in the discussion is around how JIRA > is handled after we direct all GH traffic to pr@. > > Either we leave JIRA emails coming to dev@ or we direct them to a new issues@. > > Even with GH not causing additional JIRA ticket entries, the dev@ list may > still be a bit busy. JIRA has it's own level of additional emails. > > The sender is "j...@apache.org"; reply-to: is "dev@". > > How "reply" works is different for different email clients: > > GMail: > > I only get the option of replying to the dev@list and that will not get put > back on the ticket. > > Thunderbird: > > I get "reply" which goes to "j...@apache.org" and will update the ticket, and > "reply list" to "dev@". > > What are you hoping for by having JIRA emails go to dev@ > > > I've just setup a personal JIRA filter subscription and now get a list of new > tickets from the past 24 hours, sent to me once a day. I use this from JIRA > cloud - I wanted to make sure it works for the Apache installation. The > "watching" controls also work so a person can track specific tickets. > >Andy > > On 10/12/2019 08:44, Andy Seaborne wrote: >> On 09/12/2019 20:51, Andy Seaborne wrote: >>> >>> >>> On 09/12/2019 16:26, ajs6f wrote: >>>> I'm not sure why I would want to use a clunky and less-functional (no >>>> reply-to to comment on PR, non-formatting-aware) email list instead of the >>>> more powerful_and_ more pleasant GH system. >>> >>> No one is asking you to. >>> It is not either-or. >>> >>> GH tools remain untouched as they are today. >>> >> PR discussion is done on GH >>> >>> > any comment on a PR creates at least three email messages in my inbox, >>> >>> One of the copies, the useful message, you get is direct from GH, not via >>> ASF (assuming you have GH notifications on) >>> >>>> 1. Turn off auto-mirroring of all PR comments (which now starts once a >>>> ticket is mentioned) from GH to Jira. >>> >>> Yes >>> >> all PR traffic to pr@ >>> >>> >2. Put PR comments on a separate pr@ list to record them. >>> >>> Yes >>> >> all PR [email] traffic to pr@ >>> >>> >>> The only difference here is whether JIRA goes to issues@. >>> Anyone can combine their email into one folder (as they can separate it >>> today). The difference is really on the archives. >> missing the other big benefit - the dev@ is more approachable for people >> dropping in and showing an interest. >>> >>> The one thing we still JIRA for because there isn't "issues" on GH >>> (and they are weak as a long term record IMO). >>> >>> Andy >>> >>> >>> >>> >>> >>>
Re: [Discuss] Split the dev@ mailing list?
> On Dec 9, 2019, at 10:01 AM, Andy Seaborne wrote: > The important point is a less-busy dev@. Well, I want the right discussion on dev@, not just less discussion. Now that I go back and look over the recent archives, it's not clear to me at all that if we drop all the duplication we are now getting because of Jira-GH-dev reflection that dev@ is actually too busy. > So can you +1 the discussion now Not yet, because it is not clear to me that this is the minimal improvement. (see below) > Whatever we do, we can fine-tune later when we see how it works in practice. > >> I wouldn't subscribe to a pr@ list. GH's native service for that kind of >> communication is much better than any email list. > (Though if you subscribe, can't you then choose not to have notifications > direct?) I'm not sure why I would want to use a clunky and less-functional (no reply-to to comment on PR, non-formatting-aware) email list instead of the more powerful _and_ more pleasant GH system. No offense meant to INFRA; they are amazing people who often accomplish more in an hour than I often do in a day, but a mailing list is no substitute for the sophisticated integration that GH has done for email notifications and PRs. > Agreed. (But that's actually separate from splitting the dev@ list.) > I checked and it does not happen in some other projects so it does look > possible. > Before I go and talk to infra, I do need to show its the PMC wanting to make > changes. That (getting traffic off Jira and thereby lowering the _duplicated_ traffic to dec@) is actually the major change that interests me. I am ready to +1 a change that reduces the duplication without doing anything else more then necessary. Are you willing to start with a smaller proposal? 1. Turn off auto-mirroring of all PR comments (which now starts once a ticket is mentioned) from GH to Jira. Perhaps it could be manually triggered per-comment by mentioning the ticket, or some other more "throttled" way, but of course we need to talk to INFRA to see what is possible. and 2. Put PR comments on a separate pr@ list to record them. I suspect that will reduce the dev@ traffic enough that we may not have to do anything else. No more PR comment ping-pong might mean no new issues@ list. > I want to get to tickets as soon as possible. At the moment we have some > ideas and next we can get some agreed general directions. > e.g. new API in addition to a ported existing one?; or changes within the > existing one? > Tickets work best for getting taking a proposal through the details. We need > the proposal first. Otherwise tickets are a record of ideas with unclear > commitment to progress. Too many tickets dilutes discussion I think our confusion is exactly over what a "proposal" is. From my POV, we already have bunch of proposals, just at different stages of detail. (see below re: concreteness) As for the issue you specifically give as an example-- I'm a bit surprised. I had understood us to be specifically talking about a new API. I am much less interested in evolving the old one radically. To be clear, I don't mean that I want to throw it away or anything insane like that, just that in the new proposal space we have no reason to worry about backward compatibility. Of course we'll want to start abstractly with the current API because it is successful and encodes a lot of hard-earnt experience. But it's a new API that we are talking about in my mind. All that having been said, I'm not able to step up with a bunch of volunteer hours right now ($job is becoming progressively less interested in semweb and less willing to allocate time for suchlike), so if the community feels that a stark new API is too ambitious, fair enough. > You (ajs6f) put forward some general ideas (Nov 21) in other Model APIs and > SPARQL - how about moving those into some thing more concrete , not necessary > complete (!), so we can see where it leads to? I don't understand what you want to see here before filing a ticket. Can you point at an example that is "more concrete, [but] not necessary complete" so I can get the sense of it? That would really help me. Adam
Re: [Discuss] Split the dev@ mailing list?
>>> For pr@, reply-to is dev@ (same as commits@) - PR discussion is done on GH >>> so the usual GH controls work for people. pr@ is more of a safe archive. GH notifications include the ability to reply via email to put a remark in the conversation. How will that work with this? IMO, that is important functionality that we can't throw away. Anything that prevents the duplication of messages is good. Right now any comment on a PR creates at least three email messages in my inbox, all of which are duplicated and of which, only one is formatted usefully. First the useful message direct from GH, then a duplicate via copying onto dev@ (I realize it's for the record-- that doesn't make it useful or any less annoying), then one or more replications from Jira. So to the extent that we get any improvement on that from splitting out lists, great. I wouldn't subscribe to a pr@ list. GH's native service for that kind of communication is much better than any email list. But if keeping a separate list allows us to keep GH traffic off the main dev@ list and out of Jira, I'm +1 to that. Duplicating all PR comments onto the Jira issues has made Jira almost unusable for me. I can't page through screen after screen of nested email and GH quotes duplicating each other. On another note, the question I was asking was about how to organize the API discussion. This proposal, while interesting in its own right, wouldn't do anything to address my concern. Filtering via [] subject components is a valuable and powerful technique, but it doesn't actually connect the thread to work proposed and it's difficult for many people. I'd rather start tickets for API ideas, but I'm willing to try something else, i.e. more list-based conversation for some further period. ajs6f
Re: changes to Apache Jena site documentation
Maybe the confusion here is between "committee" (as in PMC) and "committers", who are so-called because they have commit rights to the code (normally earned by being personally committed to the project). Here is some documentation about what an Apache PMC is and does as opposed to committer-ship: https://apache.org/foundation/how-it-works.html#roles and all of https://apache.org/foundation/how-it-works.html is pretty useful. https://www.apache.org/foundation/governance/pmcs is about PMCs specifically and: https://www.apache.org/foundation/governance/pmcs#merit is particularly relevant. ajs6f > On Dec 6, 2019, at 11:53 AM, Marco Neumann wrote: > > OK I see, I have inferred that from the Apache site [1] where it says that > the Apache Jena Committee is also called PMC . > > I have seen a number of changes over the years, even predating the move to > Apache, so yes migrating to a new system might be an option. possibly a > wiki type system. But it's not urgent from my point of view at the moment. > > Thanks for the explanation attempt. > > [1] https://projects.apache.org/committee.html?jena > > > > > > > On Fri, Dec 6, 2019 at 4:31 PM ajs6f wrote: > >> No, I didn't mention the PMC at all. >> >> Perhaps we're getting confused here because like other Apache projects, >> Jena has both a roster of committers, who have privileges to work on the >> codebase and docbase, but also a Project Management Committee or PMC (of >> which Andy is now the chair), which is ultimately responsible for the >> conduct of the Jena project to the Apache Foundation. The PMC, amongst a >> few other duties, elects new committers. Like many Apache projects, those >> lists for Jena are substantially the same (with a few small differences), >> but the only one that is relevant here is the committer roster. >> >> As for other kinds of roles, I'm not sure how much flexibility is >> available from the Apache bylaws, but I know of no other project that >> features other "official" roles-- that is, roles other than committer or >> PMC member that would be recognized by the Foundation. We've discussed >> this question before and come to the conclusion that the Jena project is >> small enough that we don't need any new roles-- that if someone is making >> contributions that should be recognized with a greater level of >> responsibility (whether or not those contributions are in the form of code >> or something else like work answering questions on the mailing lists, >> etc.), we can simply make them a committer immediately. >> >> Does that help explain? >> >> In any event, several threads over the past months (years now, I think!) >> have arisen on this list to the effect that our documentation in Apache >> INFRA's old-line CMS isn't easy to maintain or publish, so that >> alternatives are attractive. I suspect that real improvement for our >> documentation process would be better achieved by migrating to a new system. >> >> ajs6f >> >>> On Dec 6, 2019, at 11:17 AM, Marco Neumann >> wrote: >>> >>> in short yes, I would think for documentation purposes and the like a >> more >>> relaxed form of participation should be available. So you say currently >>> only members with role PMC can commit edits to the documentation on the >>> apache cms? Can roles be dynamically generated here or does each Apache >>> project has only one type of role membership on the Apache cms? >>> >>> >>> >>> On Fri, Dec 6, 2019 at 3:58 PM ajs6f wrote: >>> >>>> It is not tied into that build process, except for the Javadocs, since >>>> Javadocs are extracted from the codebase. There is no need to build the >>>> codebase to publish the site as a whole. >>>> >>>> As for assigning an account to individual users, I'm not quite sure what >>>> that would do. Currently accounts are for committers because only >>>> committers can make changes to the documentation. Are you suggesting >> that >>>> we allow any user with an account to make changes there and allow any >> Jena >>>> user who asks to have an account? Or something else? >>>> >>>> ajs6f >>>> >>>>> On Dec 6, 2019, at 10:52 AM, Marco Neumann >>>> wrote: >>>>> >>>>> assign user name and password to individual users? I'd say it doesn't >>>> need >>>>> to be tied into the build process of the Apache Jena project IIUC >>
Re: changes to Apache Jena site documentation
No, I didn't mention the PMC at all. Perhaps we're getting confused here because like other Apache projects, Jena has both a roster of committers, who have privileges to work on the codebase and docbase, but also a Project Management Committee or PMC (of which Andy is now the chair), which is ultimately responsible for the conduct of the Jena project to the Apache Foundation. The PMC, amongst a few other duties, elects new committers. Like many Apache projects, those lists for Jena are substantially the same (with a few small differences), but the only one that is relevant here is the committer roster. As for other kinds of roles, I'm not sure how much flexibility is available from the Apache bylaws, but I know of no other project that features other "official" roles-- that is, roles other than committer or PMC member that would be recognized by the Foundation. We've discussed this question before and come to the conclusion that the Jena project is small enough that we don't need any new roles-- that if someone is making contributions that should be recognized with a greater level of responsibility (whether or not those contributions are in the form of code or something else like work answering questions on the mailing lists, etc.), we can simply make them a committer immediately. Does that help explain? In any event, several threads over the past months (years now, I think!) have arisen on this list to the effect that our documentation in Apache INFRA's old-line CMS isn't easy to maintain or publish, so that alternatives are attractive. I suspect that real improvement for our documentation process would be better achieved by migrating to a new system. ajs6f > On Dec 6, 2019, at 11:17 AM, Marco Neumann wrote: > > in short yes, I would think for documentation purposes and the like a more > relaxed form of participation should be available. So you say currently > only members with role PMC can commit edits to the documentation on the > apache cms? Can roles be dynamically generated here or does each Apache > project has only one type of role membership on the Apache cms? > > > > On Fri, Dec 6, 2019 at 3:58 PM ajs6f wrote: > >> It is not tied into that build process, except for the Javadocs, since >> Javadocs are extracted from the codebase. There is no need to build the >> codebase to publish the site as a whole. >> >> As for assigning an account to individual users, I'm not quite sure what >> that would do. Currently accounts are for committers because only >> committers can make changes to the documentation. Are you suggesting that >> we allow any user with an account to make changes there and allow any Jena >> user who asks to have an account? Or something else? >> >> ajs6f >> >>> On Dec 6, 2019, at 10:52 AM, Marco Neumann >> wrote: >>> >>> assign user name and password to individual users? I'd say it doesn't >> need >>> to be tied into the build process of the Apache Jena project IIUC >>> >>> On Fri, Dec 6, 2019 at 3:41 PM ajs6f wrote: >>> >>>> Did you have suggestions for a different process? >>>> >>>> ajs6f >>>> >>>>> On Dec 6, 2019, at 8:38 AM, Marco Neumann >>>> wrote: >>>>> >>>>> Thanks Adam, >>>>> >>>>> the process sounds a bit cumbersome, but in any event the page I have >>>>> already edited is here >>>>> >>>>> >>>> >> https://cms.apache.org/jena/wc/edit/anonymous-n3xU7Y/trunk/content/documentation/javadoc/index.mdtext >>>>> >>>>> >>>>> the idea was to update the bread crumb navigation items since currently >>>> to >>>>> spatial search links to a 404 >>>>> >>>>> >>>>> >>>>> On Thu, Dec 5, 2019 at 7:49 PM ajs6f wrote: >>>>> >>>>>> Yes, a committer needs to push the change through to be committed to >> the >>>>>> documentation base, and then the site must be published. We always >>>> publish >>>>>> for a release, but we can publish at other times, too, if needed. >>>>>> >>>>>> I do not recall seeing the actual change come across dev@ (which it >>>>>> normally would). Do you have a link to the patch in the Apache CMS >>>> handy? I >>>>>> am happy to review and commit it. >>>>>> >>>>>> ajs6f >>>>>> >>>>>>> On Dec 4, 2019, at 2:58 PM, Marco Neumann >>>>>> wrote: >>>>>>> >>>>>>> I have made some changes to the documentation on the jena.apache.org >>>>>> site >>>>>>> with the anonymous username and can indeed see these changes now in >> the >>>>>>> edit view but not in the live view. Is this correct behavior, does >> this >>>>>>> change wait for some admin approval? >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>>> --- >>>>>>> Marco Neumann >>>>>>> KONA >>>>>> >>>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> --- >>>>> Marco Neumann >>>>> KONA >>>> >>>> >>> >>> -- >>> >>> >>> --- >>> Marco Neumann >>> KONA >> >> > > -- > > > --- > Marco Neumann > KONA
Re: changes to Apache Jena site documentation
It is not tied into that build process, except for the Javadocs, since Javadocs are extracted from the codebase. There is no need to build the codebase to publish the site as a whole. As for assigning an account to individual users, I'm not quite sure what that would do. Currently accounts are for committers because only committers can make changes to the documentation. Are you suggesting that we allow any user with an account to make changes there and allow any Jena user who asks to have an account? Or something else? ajs6f > On Dec 6, 2019, at 10:52 AM, Marco Neumann wrote: > > assign user name and password to individual users? I'd say it doesn't need > to be tied into the build process of the Apache Jena project IIUC > > On Fri, Dec 6, 2019 at 3:41 PM ajs6f wrote: > >> Did you have suggestions for a different process? >> >> ajs6f >> >>> On Dec 6, 2019, at 8:38 AM, Marco Neumann >> wrote: >>> >>> Thanks Adam, >>> >>> the process sounds a bit cumbersome, but in any event the page I have >>> already edited is here >>> >>> >> https://cms.apache.org/jena/wc/edit/anonymous-n3xU7Y/trunk/content/documentation/javadoc/index.mdtext >>> >>> >>> the idea was to update the bread crumb navigation items since currently >> to >>> spatial search links to a 404 >>> >>> >>> >>> On Thu, Dec 5, 2019 at 7:49 PM ajs6f wrote: >>> >>>> Yes, a committer needs to push the change through to be committed to the >>>> documentation base, and then the site must be published. We always >> publish >>>> for a release, but we can publish at other times, too, if needed. >>>> >>>> I do not recall seeing the actual change come across dev@ (which it >>>> normally would). Do you have a link to the patch in the Apache CMS >> handy? I >>>> am happy to review and commit it. >>>> >>>> ajs6f >>>> >>>>> On Dec 4, 2019, at 2:58 PM, Marco Neumann >>>> wrote: >>>>> >>>>> I have made some changes to the documentation on the jena.apache.org >>>> site >>>>> with the anonymous username and can indeed see these changes now in the >>>>> edit view but not in the live view. Is this correct behavior, does this >>>>> change wait for some admin approval? >>>>> >>>>> -- >>>>> >>>>> >>>>> --- >>>>> Marco Neumann >>>>> KONA >>>> >>>> >>> >>> -- >>> >>> >>> --- >>> Marco Neumann >>> KONA >> >> > > -- > > > --- > Marco Neumann > KONA
Re: changes to Apache Jena site documentation
Did you have suggestions for a different process? ajs6f > On Dec 6, 2019, at 8:38 AM, Marco Neumann wrote: > > Thanks Adam, > > the process sounds a bit cumbersome, but in any event the page I have > already edited is here > > https://cms.apache.org/jena/wc/edit/anonymous-n3xU7Y/trunk/content/documentation/javadoc/index.mdtext > > > the idea was to update the bread crumb navigation items since currently to > spatial search links to a 404 > > > > On Thu, Dec 5, 2019 at 7:49 PM ajs6f wrote: > >> Yes, a committer needs to push the change through to be committed to the >> documentation base, and then the site must be published. We always publish >> for a release, but we can publish at other times, too, if needed. >> >> I do not recall seeing the actual change come across dev@ (which it >> normally would). Do you have a link to the patch in the Apache CMS handy? I >> am happy to review and commit it. >> >> ajs6f >> >>> On Dec 4, 2019, at 2:58 PM, Marco Neumann >> wrote: >>> >>> I have made some changes to the documentation on the jena.apache.org >> site >>> with the anonymous username and can indeed see these changes now in the >>> edit view but not in the live view. Is this correct behavior, does this >>> change wait for some admin approval? >>> >>> -- >>> >>> >>> --- >>> Marco Neumann >>> KONA >> >> > > -- > > > --- > Marco Neumann > KONA
Re: changes to Apache Jena site documentation
Yes, a committer needs to push the change through to be committed to the documentation base, and then the site must be published. We always publish for a release, but we can publish at other times, too, if needed. I do not recall seeing the actual change come across dev@ (which it normally would). Do you have a link to the patch in the Apache CMS handy? I am happy to review and commit it. ajs6f > On Dec 4, 2019, at 2:58 PM, Marco Neumann wrote: > > I have made some changes to the documentation on the jena.apache.org site > with the anonymous username and can indeed see these changes now in the > edit view but not in the live view. Is this correct behavior, does this > change wait for some admin approval? > > -- > > > --- > Marco Neumann > KONA
Re: [API] Ideas
> On Nov 22, 2019, at 3:37 AM, Dave Reynolds wrote > I suspect the underlying point is that the second form of getProperty is > badly named and in retrospect perhaps could have been called makeProperty. Worse; here is the Javadoc for that getProperty: > Return a Property instance with the given URI in this model. This method > behaves identically to createProperty(String,String) and > exists as legacy: createProperty is now capable of, and allowed to, reuse > existing objects. It's semi-deprecated. It seems that "createProperty" is to be preferred? The underlying point is actually this very confusion; that (IMO) the profusion of methods on Model and some of the other core classes are less helpful to less-experienced users than they might seem to more-experienced users. An API with fewer and clearer methods per class, even at the cost of some verbosity, might be a good goal. To be clear, I'm not criticizing the work that brought us here. I think Jena's attention to keeping the API backwards-compatible has been one of its great strengths. I'm just calling attention to the fact that if we want to simplify, this is the time to do it, at a major version change. ajs6f ajs6f
Re: [API] Ideas
Some off-the-cuff ideas… I'd like to catch up to Java. :grin: Here are three examples (very much off the top of my head, so there may some obvious reasons that we wouldn't want to do these) to give the flavor of what I mean, assuming we are talking about a really new API. I don't think anything is too unworldly, depending on our timescale. • I'd like to see the introduction of Optional on a much larger scale to replace returning "value-or-null" in a new API. Modern JVMs in-line Optional to null-checks, so there is no real performance issue, and Optional (for my money) is no longer confusing and new, it's elegant and clear and concise. • The Streams API has already come up. IMHO it's a no-brainer to introduce it alongside iterators in selected appropriate places in the SPI and a new API. Ideally we would even feature a few good examples of pushing computation back up the line. • The Flow API (reactive streams) seems interesting in the context of SPARQL 1.2 protocol-related discussions: https://github.com/w3c/sparql-12/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aopen+protocol For example, if ideas like https://github.com/w3c/sparql-12/issues/7 or /84 go forward, we could potentially redesign RDFConnection and its underpinnings to use Flows. This is pretty speculative, of course, but there are other areas that might be interesting for this. I suspect that we could use it to do some level of decoupling of SPARQL execution (flows passing to each other), but that is well above my ability to speculate usefully on, knowing as shamefully little as I do about the actual paths through ARQ, and anyway, that's not API-related. Other stuff: I would like to look at the fairly large number of methods on classes like Resource and Model and see if we can corral and regularize them a bit. I'm not against functionality, of course, but we've built up those APIs via the "coral reef" model (accumulation) and so we have little oddities like: Statement getProperty(Resource s, Property p, String lang) and Property getProperty(String nameSpace, String localName) but Statement getRequiredProperty(Resource s, Property p) with no Property getRequiredProperty(String s, String p) That's not such a horrible state of existence, but I find that the dozens and dozens of methods on some of our core types often get a bit hard to sort through, especially with little quirks like that. We might also want to consider nomenclature. Model, for example, isn't really a great term to use any more for what most APIs would call a Graph. Of course, we've used "Graph" elsewhere. In any event, something to think about. Next.0 is the time to make changes like that, if we're going to make them. ajs6f > On Nov 21, 2019, at 12:44 PM, Andy Seaborne wrote: > > So what sort of things do people think we should look at for the main > application API(s). > >Andy
Re: [java runtime] Re: Jena next
I'm not sure how unusually slow Bruno's $work is. It's the same where I am and I know of plenty of other places in academia or government that look similar schedule-wise. To be clear, I am not arguing for Java 8 beyond Jena 3-- instead (I think) I'm agreeing with Bruno that we might want to think about 11 as a good compromise between all the good new language features becoming available and getting solid uptake. That having been said, we're at the beginning of a long journey and things may well look different by the time we've actually scoped 4. ajs6f On Tue, Nov 19, 2019, 8:38 AM Andy Seaborne wrote: > > > On 16/11/2019 23:55, Bruno P. Kinoshita wrote: > >> What perspectives do other people have on the landscape? > > My company is pretty slow in updating its stack. They have Java8 only > now (and an isolated pod with java 5 or 6 for a legacy app I think). Not > aware of any java9+ yet. > > I think for Jena 4 we could go with Java LTS os LTS-next (assuming Jena4 > may take a while to be ready)? > > Bruno > > So the real question is whether they would use a Java11 runtime - and > for security reasons updating the JVM is a good idea (tm) - even if its > running older code. > > That's what I am seeing - Java11 JVM for Java8 apps especially when > deploying a new installation. The standard IT dept recipe is for Java11 > so it just happens that way. > > Andy > > > > > Sent from Yahoo Mail on Android > > > >On Sun, 17 Nov 2019 at 10:41, Andy Seaborne wrote: > > > > On 14/11/2019 20:08, Aaron Coburn wrote: > >> I would be very interested in discussing the high level Java API and > how it > >> could be simplified. > > > > Let's take API discussion to [API] and not loose the other points. > > > >> It might also be worthwhile to look into the overall package/jar > structure. > >> This will help for both OSGi and JPMS support. > > > > Yes. The package structure is a current impedance. > > > >> Regarding the Java14/JPMS target, I assume this means that the Jena code > >> can be compiled and run on a Java14 environment and/or used on the > module > >> path in a JPMS-enabled application (and *not* that all downstream > >> applications must use one of the newer Java runtimes). That is, would > the > >> compiler target and source still be Java8? > > > > Actually, I was thinking Java14 APIs (var type inference improvements; > > Java9 has Http/2; Java12,13 Switch Expressions; java14 NVM > > MappedByteBuffer improvemnts) and language changes - so a Java14 runtime > > is required. > > > > Modules would not be required of applications, and mixed JavaOld/Java14 > > code can be run on a Java14 JVM. > > > > This is something we need to agree on first. > > > > If we going to move from Java8, we might as well jump to Java14. > > > > Jena3 remains for some overlap period. > > > > I think the Java version factor is changed by the slow demise of > > multi-application platforms (e.g. Tomcat + multiple WAR files). > > Container and microservices isolate the Java choice. > > > > Java8 EOL is September 2023 (End of free public updates by AdoptOpenJDK) > > which is the same as Java11. > > > > What perspectives do other people have on the landscape? > > > > Andy > > > >> > >> Cheers, > >> Aaron > >> > >> On Wed, 13 Nov 2019 at 14:18, Andy Seaborne wrote: > >> > >>> I'd like to start a discussion on where the project might go longer > term. > >>> > >>> This can be specific areas, overall design, about project processes, > >>> anything. > >>> > >>> If we are going to do a major change, Jena4, what preparation for that > >>> can be done? (e.g. deprecation and signalling in Jena3, before the > >>> change happens). > >>> > >>> Realistically, Jena4 means having Jena3 and Jena4 in parallel. Jena4 > >>> need not be that big - we can have Jena5 etc. > >>> > >>> I'll put some technical points in a separate email. > >>> > >>> I would put on the list: > >>> > >>> * How has the world changed? What should the project produce? > >>> * Target audience: for developers of Jena, while Jena3 is for users. > >>> * Target: Java14, JPMS. > >>> * Clear-up not easily done with perfect compatibility. > >>> * Simpler. There are APIs and packages entangled due to history. > >>> > >>> To the lurkers :-) > >>> > >>> Feedback and specific feature requests are welcome. But before you "go > >>> shopping", you may wish to factor in that every feature needs effort to > >>> do it. The better place to be is that an application can get what it > >>> needs to do, not whether the Jena system has every feature built-in. > >>> > >>>Andy > >>> > >> > > > > >
Re: Jena next (AFS)
No problem! Streams and Iterators have confused me myself, but luckily Andy and other folks helped straighten me out. Andy, you've given a nice list of potential discussions and others have as well. My meta-question is when do we want to switch to tickets for this process? I don't want to smother discussion in process, but I find it very hard to follow a multithreaded discussion over email and I much prefer breaking things out early to more specifics. Shall I start capturing (or trying to) ideas, or is it too soon? ajs6f On Tue, Nov 19, 2019, 11:49 AM Bögershausen, Merlin Michael < merlin.boegershau...@rwth-aachen.de> wrote: > Seems like I've got the wrong feeling from early messages, revisited Andys > Post missed the "additional provide" part, sorry. > > Am 19.11.2019 16:48 schrieb "A. Soroka" : > I think there may be some confusion here about Streams and Iterators. > Streams are not and were never intended to be a replacement for or > equivalent to Iterators. Iterators are a source of elements. There is no > further complexity. Streams, on the other hand, are pipelines of > computation which do not begin flowing until a terminal operation is called > and then the data flows through the pipe without further action from the > caller. > > We should not even consider replacing Iterators with Streams and I did not > hear anyone suggest it. The suggestion I heard (and which I thoroughly > support) is to offer Streams alongside Iterators for their intended > purpose; pipelining computations. > > For example, consider a dataset backed by a remote SPARQL connection. > Suppose stream() is called on a graph from this dataset, and suppose > limit() is called on that Stream. Then in the right conditions a smart > implementation could push that limit upstream to become a LIMIT in the > SPARQL being sent over the wire. That's the real value of all those methods > on Stream. They aren't merely for developer convenience. A library like our > Iter would do for that. They are there to provide opportunities to classify > and manage the computations being pipelined. > > So Stream is very useful for its purpose, but not for Iterator's purpose. > As for crossing module boundaries, I haven't seen any problems with that > and I'm not sure what the objection actually is. In fact, refusing to > expose > Streams at APIs seems to make the whole thing rather pointless. > > ajs6f > > > On Tue, Nov 19, 2019, 10:06 AM Merlin Bögershausen < > merlin.boegershau...@rwth-aachen.de> wrote: > > > Hi, > > > > To the Stream discussion: Streams should not be passed beyond module > > borders. In my personal view not even beyond scopes, because the > > exceptions thrown by an already terminated stream can be misleading. > > Every user can feel free to use the StreamSupport class whenever the > > application code uses streams. > > > > Another thing, I would like to see a graph view inside Fuseki UI, where > > the triples are visualized like in > > <https://www.w3.org/2018/09/rdf-data-viz/> > > I use such visualization whenever I explain the usage of our graph data > > model to my colleagues, whenever they have problems to develop SPARQL > > queries. Also, I feel that it would help our support team to see why > > the system performs unexpected steps. > > > > Merlin > > > > > >
Re: [] Apache Jena 3.13.0 RC 1
Yep, that did it! A clean build. ajs6f > On Sep 24, 2019, at 10:56 AM, Andy Seaborne wrote: > > ajs6f - could you put that directory in from git (I presume it's there - all > my copies of Jena have it) and see if the rest of the build runs on your mac? > > Thanks > Andy > > On 24/09/2019 15:23, ajs6f wrote: >> I'm sorry to say that I'm getting a build error on my Mac with >> ➜ jena-3.13.0 mvn -v >> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; >> 2018-02-24T14:49:05-05:00) >> Maven home: /usr/local/Cellar/maven/3.5.3/libexec >> Java version: 1.8.0_65, vendor: Oracle Corporation >> Java home: >> /Library/Java/JavaVirtualMachines/jdk1.8.0_65.jdk/Contents/Home/jre >> Default locale: en_US, platform encoding: UTF-8 >> OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac" >> in jena-shacl. I include the whole stacktrace below my sig, but the error is >> specifically >> [INFO] Running org.apache.jena.shacl.TC_SHACL >> [ERROR] Tests run: 20, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: >> 1.079 s <<< FAILURE! - in org.apache.jena.shacl.TC_SHACL >> [ERROR] initializationError(org.apache.jena.shacl.tests.std.TestShaclCoreWG) >> Time elapsed: 0.004 s <<< ERROR! >> org.apache.jena.riot.RiotNotFoundException: Not found: >> file:///private/tmp/jena/jena-3.13.0/jena-shacl/testing/std/core/targets/manifest.ttl >> at >> org.apache.jena.shacl.tests.std.TestShaclCoreWG.data(TestShaclCoreWG.java:39) >> It looks like maybe a test is running into some kind of problem because Macs >> do that thing where they alias /tmp to a different directory for each user? >> ajs6f >> ➜ jena-3.13.0 mvn install -rf :jena-shacl >> [INFO] Scanning for projects... >> [INFO] >> >> [INFO] Reactor Build Order: >> [INFO] >> [INFO] Apache Jena - SHACL >> [jar] >> [INFO] Apache Jena - RDF Connection >> [jar] >> [INFO] Apache Jena - TDB1 (Native Triple Store) >> [jar] >> [INFO] Apache Jena - Database Operation Environment >> [pom] >> [INFO] Apache Jena - DBOE Base >> [jar] >> [INFO] Apache Jena - DBOE Transactions >> [jar] >> [INFO] Apache Jena - DBOE Indexes >> [jar] >> [INFO] Apache Jena - DBOE Index test suite >> [jar] >> [INFO] Apache Jena - DBOE Transactional Datastructures >> [jar] >> [INFO] Apache Jena - DBOE Storage >> [jar] >> [INFO] Apache Jena - TDB2 >> [jar] >> [INFO] Apache Jena - Libraries POM >> [pom] >> [INFO] Apache Jena - Command line tools >> [jar] >> [INFO] Apache Jena - SPARQL Text Search >> [jar] >> [INFO] Apache Jena - SPARQL Text Search - Elasticsearch >> [jar] >> [INFO] Apache Jena - Fuseki - A SPARQL 1.1 Server >> [pom] >> [INFO] Apache Jena - Fuseki Core Engine >> [jar] >> [INFO] Apache Jena - Fuseki Data Access Control >> [jar] >> [INFO] Apache Jena - Fuseki Server >> [jar] >> [INFO] Apache Jena - Fuseki Server Jar >> [jar] >> [INFO] Apache Jena - Fuseki Webapp >> [jar] >> [INFO] Apache Jena - Fuseki WAR File >> [war] >> [INFO] Apache Jena - Fuseki Server Standalone Jar >> [jar] >> [INFO] Apache Jena - Fuseki Binary Distribution >> [pom] >> [INFO] Apache Jena - GeoSPARQL Engine >> [jar] >> [INFO] Apache Jena - Fuseki with GeoSPARQL Engine >> [jar] >> [INFO] Apache Jena - Integration Testing >> [jar] >> [INFO] Apache Jena - Distribution >> [pom] >> [INFO] Apache Jena - SDB (SQL based triple store) >> [jar] >> [INFO] A
Re: [VOTE] Apache Jena 3.13.0 RC 1
I'm sorry to say that I'm getting a build error on my Mac with ➜ jena-3.13.0 mvn -v Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T14:49:05-05:00) Maven home: /usr/local/Cellar/maven/3.5.3/libexec Java version: 1.8.0_65, vendor: Oracle Corporation Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_65.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac" in jena-shacl. I include the whole stacktrace below my sig, but the error is specifically [INFO] Running org.apache.jena.shacl.TC_SHACL [ERROR] Tests run: 20, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.079 s <<< FAILURE! - in org.apache.jena.shacl.TC_SHACL [ERROR] initializationError(org.apache.jena.shacl.tests.std.TestShaclCoreWG) Time elapsed: 0.004 s <<< ERROR! org.apache.jena.riot.RiotNotFoundException: Not found: file:///private/tmp/jena/jena-3.13.0/jena-shacl/testing/std/core/targets/manifest.ttl at org.apache.jena.shacl.tests.std.TestShaclCoreWG.data(TestShaclCoreWG.java:39) It looks like maybe a test is running into some kind of problem because Macs do that thing where they alias /tmp to a different directory for each user? ajs6f ➜ jena-3.13.0 mvn install -rf :jena-shacl [INFO] Scanning for projects... [INFO] [INFO] Reactor Build Order: [INFO] [INFO] Apache Jena - SHACL[jar] [INFO] Apache Jena - RDF Connection [jar] [INFO] Apache Jena - TDB1 (Native Triple Store) [jar] [INFO] Apache Jena - Database Operation Environment [pom] [INFO] Apache Jena - DBOE Base[jar] [INFO] Apache Jena - DBOE Transactions[jar] [INFO] Apache Jena - DBOE Indexes [jar] [INFO] Apache Jena - DBOE Index test suite[jar] [INFO] Apache Jena - DBOE Transactional Datastructures[jar] [INFO] Apache Jena - DBOE Storage [jar] [INFO] Apache Jena - TDB2 [jar] [INFO] Apache Jena - Libraries POM[pom] [INFO] Apache Jena - Command line tools [jar] [INFO] Apache Jena - SPARQL Text Search [jar] [INFO] Apache Jena - SPARQL Text Search - Elasticsearch [jar] [INFO] Apache Jena - Fuseki - A SPARQL 1.1 Server [pom] [INFO] Apache Jena - Fuseki Core Engine [jar] [INFO] Apache Jena - Fuseki Data Access Control [jar] [INFO] Apache Jena - Fuseki Server[jar] [INFO] Apache Jena - Fuseki Server Jar[jar] [INFO] Apache Jena - Fuseki Webapp[jar] [INFO] Apache Jena - Fuseki WAR File [war] [INFO] Apache Jena - Fuseki Server Standalone Jar [jar] [INFO] Apache Jena - Fuseki Binary Distribution [pom] [INFO] Apache Jena - GeoSPARQL Engine [jar] [INFO] Apache Jena - Fuseki with GeoSPARQL Engine [jar] [INFO] Apache Jena - Integration Testing [jar] [INFO] Apache Jena - Distribution [pom] [INFO] Apache Jena - SDB (SQL based triple store) [jar] [INFO] Apache Jena - Security Permissions [jar] [INFO] Apache Jena - Extras [pom] [INFO] Apache Jena - Extras - Query Builder [jar] [INFO] Apache Jena - JDBC Parent [pom] [INFO] Apache Jena - JDBC Core API[jar] [INFO] Apache Jena - JDBC Remote Endpoint Driver [jar] [INFO] Apache Jena - JDBC In-Memory Driver[jar] [INFO] Apache Jena - JDBC TDB Driver [jar] [INFO] Apache Jena - JDBC Driver Bundle [jar] [INFO] Apache Jena - Elephas [pom] [INFO] Apache Jena - Elephas - Common API [jar] [INFO] Apache Jena - Elephas - I/O[jar] [INFO] Apache Jena - Elephas - Map/Reduce [jar] [INFO] Apache Jena - Elephas - Statistics Demo App[jar] [INFO] Apache Jena - OSGi
Re: Discuss: write PREFIX not @prefix?
Ditto, but I'd be interested in hearing why you suggested it, Andy. IOW are there some benefits that aren't obvious? ajs6f > On Sep 20, 2019, at 7:17 AM, Claude Warren wrote: > > For me this falls under "if it ain't broke don't fix it" > so > -1 > > > On Fri, Sep 20, 2019 at 11:47 AM Andy Seaborne wrote: > >> The Turtle and TriG writers output "@prefix". >> >> RDF 1.1 allows PREFIX. >> >> Should we change the writers to output PREFIX? (after the next release) >> >> (we can add options but majority of users don't set options and exisintg >> code doesn't) >> >> Andy >> > > > -- > I like: Like Like - The likeliest place on the web > <http://like-like.xenei.com> > LinkedIn: http://www.linkedin.com/in/claudewarren
Re: documentation and examples
>> Adding it to the build means that the documented examples should always >> stay in step with the code it pulls from the tests and the must pass. > > Good idea to have a build step to help keep them up-to-date. I've used systems like this and they work well, but I think that we should do this after we move to a more graceful documentation build. In JENA-1755 Andy mentions Jekyll (which has come up before here) and some new features from INFRA for managing sites that should make it more automated. If this is the Jekyll in question: https://jekyllrb.com/docs/ do we have a good way to do a migration? Bruno, I seem to remember you having some experience with such a migration-- is that right? If so I would be happy to work with you to do this, if we all end up agreeing to it. ajs6f > On Sep 7, 2019, at 12:52 PM, Andy Seaborne wrote: > > > > On 05/09/2019 11:46, Claude Warren wrote: >> There were recently some comments about the lack of query builder >> documentation (https://issues.apache.org/jira/browse/JENA-1751), so taking >> that to heart I sat down to write some. Then I recalled I had seen a >> discussion on one of the other lists about generating examples for the web >> from example and test code. >> I was wondering >> a) if anybody else saw the discussion and if so do you remember where? >> b) if we should do something like that in Jena. > > Not the same thing but several module have "src-examples" so that code is > available to be linked to. It gives the opportunity of addthme to the local > IDE set so that are compiled. > > >> Adding it to the build means that the documented examples should always >> stay in step with the code it pulls from the tests and the must pass. > > Good idea to have a build step to help keep them up-to-date. > > There is the under-used jena-examples. > Maybe that could be used. > >> If there is interest I will see if I can find the other discussion. >> Claude > > Andy >
Re: CMS diff: Data Access Control for Fuseki
Hi, Pierre-- Thanks for sending in some corrections for the documentation, but you seem to have left some notes in there. I see text like > +Next to last line has an incorrect command for running fuseki with a jetty > configuration. > + > +It should read --jetty-config, not --jetty. > + > +(A link to the default jetty config shipped with fuseki would be useful. An > how-to change the main jetty options would be useful to. ) to be added to the page, which I assume you meant as notes to yourself? I'm not sure what part of this to merge. ajs6f > On Aug 7, 2019, at 6:28 AM, pierre grenon wrote: > > Clone URL (Committers only): > https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/documentation%2Ffuseki2%2Fdata-access-control.md > > pierre grenon > > Index: trunk/content/documentation/fuseki2/data-access-control.md > === > --- trunk/content/documentation/fuseki2/data-access-control.md > (revision 1864576) > +++ trunk/content/documentation/fuseki2/data-access-control.md > (working copy) > @@ -1,5 +1,10 @@ > Title: Data Access Control for Fuseki > > +Next to last line has an incorrect command for running fuseki with a jetty > configuration. > + > +It should read --jetty-config, not --jetty. > + > +(A link to the default jetty config shipped with fuseki would be useful. An > how-to change the main jetty options would be useful to. ) > Fuseki can provide access control at the level on the server, on datasets, > on endpoints and also on specific graphs within a dataset. It also > provides native https to protect data in-flight. > @@ -290,6 +295,6 @@ > For authentication configuration not covered by Fuseki configuration, > the deployed server can be run using a Jetty configuration. > > -Server command line: --jetty=jetty.xml. > +Server command line: --jetty-config=jetty.xml. > > [Documentation for > `jetty.xml`](https://www.eclipse.org/jetty/documentation/current/jetty-xml-config.html). >
Re: ApacheConNA
I am, although I'll be mostly attending the "big data" track. ajs6f > On Jul 31, 2019, at 9:04 PM, Bruno P. Kinoshita wrote: > > Just returned from the UK, no plans to travel again this year (everything is > too far away from NZ), but hope everything goes well at ApacheCon. Share your > slides and any feedback here after your presentation too if possible. > Good luck!Bruno > > On Thursday, 1 August 2019, 7:05:49 am NZST, Claude Warren > wrote: > > I will be speaking at ApacheConNA this year. Is anyone on this list > planning on attending? If so I would like to meet up. > > Claude > -- > I like: Like Like - The likeliest place on the web > <http://like-like.xenei.com> > LinkedIn: http://www.linkedin.com/in/claudewarren
Re: RDFStream to RDFConnection
+1 to a spot in jena-examples with a write-up on our site. ajs6f > On Jul 10, 2019, at 3:20 PM, Andy Seaborne wrote: > > How big is it one file? A module, even under jena-extras seems a tad heavy. > > Stepping back from the specifics, thinking this might be one of several: > > Is this more of an example of how to to do something? That could be done by > publishing the source, still with the Apache legal framework. > > We have jena-examples, package org/apache/jena/example/ and that gets into > the release source. > > Maybe that's a way without too much ceremony. > > Or more a "documentation" via the web-site > Or the cwiki? > >Andy > > On 09/07/2019 10:43, Claude Warren wrote: >> So, the question is should I go ahead and create a library of StreamRDF >> implementations in the extras section? I could see one to do serialization >> over Kafka (or other queue implementations)? >> On Mon, Jul 8, 2019 at 5:56 PM Claude Warren wrote: >>> The case I was trying to solve was reading a largish XML document and >>> converting it to an RDF graph. After a few iterations I ended up writing a >>> custom Sax parser that calls the RDFStream triple/quad methods. But I >>> wanted a way to update a Fuseki server so RDFConnection seemed like the >>> natural choice. >>> >>> In some recent work for my employer I found that I like the RDFConneciton >>> as the same code can work against a local dataset or a remote one. >>> >>> Claude >>> >>> On Mon, Jul 8, 2019 at 4:34 PM ajs6f wrote: >>> >>>> This "replay" buffer approach was the direction I first went in for TIM, >>>> until turning to MVCC (speaking of MVCC, that code is probably somewhere, >>>> since we don't squash when we merge). Looking back, one thing that helped >>>> me move on was the potential effect of very large transactions. But in a >>>> controlled situation like Claude's, that problem wouldn't arise. >>>> >>>> ajs6f >>>> >>>>> On Jul 8, 2019, at 11:07 AM, Andy Seaborne wrote: >>>>> >>>>> Claude, >>>>> >>>>> Good timing! >>>>> >>>>> This is what RDF Delta does and for updates rather than just StreamRDF >>>> additions though its not to an RDFConnection - it's to a patch service. >>>>> >>>>> With hindsight, I wonder if that woudl have been better as >>>> BufferingDatasetGraph - a DSG that keeps changes and makes the view of the >>>> buffer and underlying DatasetGraph behave correctly (find* works and has >>>> the right cardinality of results). Its a bit fiddley to get it all right >>>> but once it works it is a building block that has a lot of re-usability. >>>>> >>>>> I came across this with the SHACL work for a BufferingGraph (with >>>> prefixes) give "abort" of transactions to simple graphs which aren't >>>> transactional. >>>>> >>>>> But it occurs in Fuseki with complex dataset set ups like rules. >>>>> >>>>>Andy >>>>> >>>>> On 08/07/2019 11:09, Claude Warren wrote: >>>>>> I have written an RDFStream to RDFConnection with caching. Basically, >>>> the >>>>>> stream caches triples/quads until a limit is reached and then it writes >>>>>> them to the RDFConnection. At finish it writes any triples/quads in >>>> the >>>>>> cache to the RDFConnection. >>>>>> Internally I cache the stream in a dataset. I write triples to the >>>> default >>>>>> dataset and quads as appropriate. >>>>>> I have a couple of questions: >>>>>> 1) In this arrangement what does the "base" tell me? I currently >>>> ignore it >>>>>> and want to make sure I havn't missed something. >>>>> >>>>> The parser saw a BASE statement. >>>>> >>>>> Like PREFIX, in Turtle, it can happen mid-file (e.g. when files are >>>> concatenated). >>>>> >>>>> Its not necessary because the data stream should have resolved IRIs in >>>> it so base is used in a stream. >>>>> >>>>>> 2) I capture all the prefix calls in a PrefixMapping that is accessible >>>>>> from the RDFConnectionStream class. They are not passed into the >>>> dataset >>>>>> in any way. I didn't see any method to do so and don't really think >>>> it is >>>>>> needed. Does anyone see a problem with this? >>>>>> 3) Does anyone have a use for this class? If so I am happy to >>>> contribute >>>>>> it, though the next question becomes what module to put it in? >>>> Perhaps we >>>>>> should have an extras package for RDFStream implementations? >>>>>> Claude >>>> >>>> >>> >>> -- >>> I like: Like Like - The likeliest place on the web >>> <http://like-like.xenei.com> >>> LinkedIn: http://www.linkedin.com/in/claudewarren >>>
Re: RDFStream to RDFConnection
This "replay" buffer approach was the direction I first went in for TIM, until turning to MVCC (speaking of MVCC, that code is probably somewhere, since we don't squash when we merge). Looking back, one thing that helped me move on was the potential effect of very large transactions. But in a controlled situation like Claude's, that problem wouldn't arise. ajs6f > On Jul 8, 2019, at 11:07 AM, Andy Seaborne wrote: > > Claude, > > Good timing! > > This is what RDF Delta does and for updates rather than just StreamRDF > additions though its not to an RDFConnection - it's to a patch service. > > With hindsight, I wonder if that woudl have been better as > BufferingDatasetGraph - a DSG that keeps changes and makes the view of the > buffer and underlying DatasetGraph behave correctly (find* works and has the > right cardinality of results). Its a bit fiddley to get it all right but once > it works it is a building block that has a lot of re-usability. > > I came across this with the SHACL work for a BufferingGraph (with prefixes) > give "abort" of transactions to simple graphs which aren't transactional. > > But it occurs in Fuseki with complex dataset set ups like rules. > >Andy > > On 08/07/2019 11:09, Claude Warren wrote: >> I have written an RDFStream to RDFConnection with caching. Basically, the >> stream caches triples/quads until a limit is reached and then it writes >> them to the RDFConnection. At finish it writes any triples/quads in the >> cache to the RDFConnection. >> Internally I cache the stream in a dataset. I write triples to the default >> dataset and quads as appropriate. >> I have a couple of questions: >> 1) In this arrangement what does the "base" tell me? I currently ignore it >> and want to make sure I havn't missed something. > > The parser saw a BASE statement. > > Like PREFIX, in Turtle, it can happen mid-file (e.g. when files are > concatenated). > > Its not necessary because the data stream should have resolved IRIs in it so > base is used in a stream. > >> 2) I capture all the prefix calls in a PrefixMapping that is accessible >> from the RDFConnectionStream class. They are not passed into the dataset >> in any way. I didn't see any method to do so and don't really think it is >> needed. Does anyone see a problem with this? >> 3) Does anyone have a use for this class? If so I am happy to contribute >> it, though the next question becomes what module to put it in? Perhaps we >> should have an extras package for RDFStream implementations? >> Claude
Re: Split the dev@ mailing list?
I like the idea of breaking PR discussions off, but if we're going to continue to copy PR comments onto Jira tickets it only makes sense if we have separate pr@ and issue@ lists. Also, we would have to stop copying them onto dev@ (which I would be fine with). Ideally, I would like to see ticket _creation_ cc:ed onto dev@, so that any interested parties would be aware without having to set up notifications in Jira, but other ticket actions not cc:ed. I'm not sure if that's possible with our gear, but I'm sure INFRA can tell us. ajs6f > On May 30, 2019, at 10:42 AM, Andy Seaborne wrote: > > The dev@ list can be dominated by github discussions. > > We have feeds from github PRs and JIRA. We could split the list in one list > per feed to leave the dev@ list for people. > > While you can do this with mail client rules, searching using the archives > isn't easy. > > Suggestion: > Add email lists for: > > pr@ -- github pull request discussions. > issues@ -- JIRA > > I'm not sure how clever we can be - for example, it would be nice for dev@ to > get an email for the submission of a pull request, then not the discussion, > but I don't think that is configurable. (It is all INFRa consifuration anyway > AFAIK). > > These names are the ones I have seen other projects use. > > Thoughts? > What have you seen work for other projects? > >Andy >
Re: [] Apache Jena 3.12.0 RC 1 (GeoSPARQL)
I was able to check the sigs, checksums, and that the source distribution builds and works. Assuming that our NOTICE is up-to-date with the new contributions (it looks to be, but I didn't follow the discussion of the new geospatial component), I can vote: >> Please vote to approve this release: >> [ ] +1 Approve the release >> [ ] 0 Don't care >> [ ] -1 Don't release, because ... +1 ajs6f > On Jun 1, 2019, at 6:37 AM, Andy Seaborne wrote: > > Hi - would 2+ people from the PMC be able to check and vote please? > >Andy > > On 28/05/2019 09:48, Andy Seaborne wrote: >> Hi, >> Here is a vote on a release of Apache Jena 3.12.0. >> This is the first proposed release candidate. >> The deadline for the vote is Friday, 31th May, 2019 at 20:00 UTC >> Release changes: >> The main feature of this release is the new GeoSPARQL and Fuseki GeoSPARQL >> modules. >> The new NOTICE file for the combined binary for fuseki+geosparql is: >> https://github.com/apache/jena/blob/d4beb7d99d48e98c981d434c980f83784b519ebd/jena-fuseki2/jena-fuseki-geosparql/src/main/resources/META-INF/NOTICE >> Other JIRA: >> https://s.apache.org/jena-3.12.0-jira >> == Updates >> JENA-1711 : Upgrade Jackson dependency to 2.9.9 (CVE-2019-12086) >> Release Vote >> Everyone, not just committers, is invited to test and vote. >> Please download and test the proposed release. >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachejena-1031 >> Proposed dist/ area: >> https://dist.apache.org/repos/dist/dev/jena/ >> Keys: >> https://svn.apache.org/repos/asf/jena/dist/KEYS >> Git commit (browser URL): >> https://github.com/apache/jena/commit/d4beb7d9 >> Git Commit Hash: >> d4beb7d99d48e98c981d434c980f83784b519ebd >> Git Commit Tag: >> jena-3.12.0 >> Please vote to approve this release: >> [ ] +1 Approve the release >> [ ] 0 Don't care >> [ ] -1 Don't release, because ... >> This vote will be open until at least >> Friday, 31th May, 2019 at 20:00 UTC >> If you expect to check the release but the time limit does not work >> for you, please email within the schedule above with an expected time >> and we can extend the vote period. >> Thanks, >> Andy >> Checking needed: >> + are the GPG signatures fine? >> + are the checksums correct? >> + is there a source archive? >> + can the source archive really be built? >> (NB This requires a "mvn install" first time) >> + is there a correct LICENSE and NOTICE file in each artifact >> (both source and binary artifacts)? >> + does the NOTICE file contain all necessary attributions? >> + have any licenses of dependencies changed due to upgrades? >>if so have LICENSE and NOTICE been upgraded appropriately? >> + does the tag/commit in the SCM contain reproducible sources?
Re: [] Apache Jena 3.12.0 RC 1 (GeoSPARQL)
No, I missed something-- I didn't see that the evaluation test question was unresolved, my mistake. ajs6f > On May 28, 2019, at 9:14 AM, Andy Seaborne wrote: > > > > On 28/05/2019 13:00, Marco Neumann wrote: >> median function not going to be in this release? > > I see an outstanding request for evaluation tests on the PR. Did I miss > something? > > This release is a direct follow-on to 3.11 when we got 3.11 out close to > schedule leaving GeoSPARQL to follow as soon as it was ready. > >Andy > > >> On Tue, May 28, 2019 at 10:25 AM Andy Seaborne wrote: >>> +1 >>> >>>> Please vote to approve this release: >>>> >>>> [ ] +1 Approve the release >>>> [ ] 0 Don't care >>>> [ ] -1 Don't release, because ... >>>
Re: [VOTE] Apache Jena 3.12.0 RC 1 (GeoSPARQL)
I'm afraid not. Honestly, I didn't realize that Andy was going to start releasing so quickly. Time flies! I've got a last request for you to stop using System.out.println to log, but other than that it looks like you've responded to all the comments, so thank you! We should be able to merge very soon. ajs6f > On May 28, 2019, at 8:00 AM, Marco Neumann wrote: > > median function not going to be in this release? > > On Tue, May 28, 2019 at 10:25 AM Andy Seaborne wrote: > >> +1 >> >>> Please vote to approve this release: >>> >>> [ ] +1 Approve the release >>> [ ] 0 Don't care >>> [ ] -1 Don't release, because ... >> > > > -- > > > --- > Marco Neumann > KONA
Re: Towards Jena 3.12.0
I'm fairly open this next week and the first week of June. ajs6f > On May 19, 2019, at 8:55 AM, Andy Seaborne wrote: > > Greg's GeoSPARQL implementation is ready. It's on a branch in git and > ready to merge - legal NOTICES are done as is disabling tests under Java11 > (boo, hiss) because of the test failures due to tiny double > precision/string representation changes Java8 -> Java11. > > So we can do Jena 3.12.0 with GeoSPARQL as discussed on the "Towards Jena > 3.11.0" thread. > > This message is to ask about timing - when might people have a chance to > vote on a release? what timing works for you? I can RM this month. > >Andy > > PS I have a couple of things "in progress" : TDB2 migrated to the > jena-dboe-storage framework and redoing Fuseki request dispatch but I'm > holding back - this release is about GeoSPARQL.
Re: CMS diff: ARQ - Building Queries Programmatically
Committed, thank you A. Wilke! ajs6f > On May 5, 2019, at 9:26 AM, A. Wilke wrote: > > Clone URL (Committers only): > https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/documentation%2Fquery%2Fprogrammatic.mdtext > > A. Wilke > > Index: trunk/content/documentation/query/programmatic.mdtext > === > --- trunk/content/documentation/query/programmatic.mdtext (revision > 1858626) > +++ trunk/content/documentation/query/programmatic.mdtext (working copy) > @@ -8,6 +8,10 @@ > See the examples in the ARQ `src-examples/` directory of the ARQ > distribution, particularly `arq.examples.AlgebraExec`. > > +* [src-examples at > gitbox.apache.org](https://gitbox.apache.org/repos/asf?p=jena.git;a=tree;f=jena-arq/src-examples) > +* [src-examples at > github.com](https://github.com/apache/jena/tree/master/jena-arq/src-examples) > + > + > See also [ARQ - SPARQL Algebra](algebra.html) > > >
Re: Towards Jena 3.11.0
https://semver.org/ If, for example, we needed to make a quick release for an urgent bugfix, it would be appropriate to increment only the "micro" or "patch" number. ajs6f > On Apr 19, 2019, at 1:33 PM, Marco Neumann wrote: > > any particular reason why you add the 0 at the end? > > Jena 3.11 would be sufficient > > I have seen it in previous releases as well but there is no need to do > so. is there a build tool that requires this? > > Marco > > On Fri, Apr 19, 2019 at 5:45 PM Andy Seaborne wrote: >> >> OK - I'll prepare Jena 3.11.0. >> >> Given the national holidays around this time, be better to have the vote >> run into next week. >> >> Andy >> >> On 17/04/2019 21:29, Aaron Coburn wrote: >>> Also +1 to releasing 3.11 soon and addressing these other issues in 3.12. >>> (But either way is fine with me) >>> >>> Aaron >>> >>> On Wed, Apr 17, 2019 at 6:47 AM wrote: >>> >>>> +1 to releasing 3.11.0 as described and not loading it up any further. >>>> >>>> ajs6f >>>> >>>> On Wed, Apr 17, 2019, 6:14 AM Andy Seaborne wrote: >>>> >>>>> We seem to be trying to do too much in one release. As ever, people get >>>>> busy. >>>>> >>>>> https://s.apache.org/jena-3.11.0-jira >>>>>36 JIRA >>>>> >>>>> including fixes like JENA-1657 "Close response stream of http >>>> connections". >>>>> >>>>> While not a major problem at the moment, it can start to cause blockage >>>>> for other work. >>>>> >>>>> We could release 3.11.0 ASAP (it's 4 months since 3.10.0) and >>>>> immediately start on 3.12.0. I can RM 3.11.0 and have some time to help >>>>> with a 3.12 ... hoping to get it all done during May. >>>>> >>>>> Or we could just accept a delay to 3.11.0. >>>>> >>>>> It is the usual tension between perfect and timely with volunteer time! >>>>> >>>>> While my preference is release 3.11.0 now and start 3.12.0, either is OK >>>>> for me. >>>>> >>>>> Thoughts? >>>>> >>>>> Andy >>>>> >>>>> On 03/04/2019 21:16, Andy Seaborne wrote: >>>>>> We have three major streams outstanding. >>>>>> Have I missed anything? >>>>>> >>>>>> 1/ GeoSPARQL >>>>>> 2/ Prometheus metrics >>>>>> 3/ SurroundQueryParser >>>>>> >>>>>> == GeoSPARQL >>>>>> >>>>>> Greg - apologies for being tardy on this one. It looks in good shape. >>>>>> Did you hear from anyone after the request for feedback? >>>>>> >>>>>> This is two modules: geosparql-jena and geosparql-fuseki >>>>>> >>>>>> A suggestion for how to proceed if you have the time for 3.11.0 is that >>>>>> we include these basically as-is and remove jena-spatial from Fuseki >>>>>> which we have been signalling for a while. >>>>>> >>>>>> Suggestion: >>>>>> >>>>>>jena-geosparql >>>>>>jena-fuseki/jena-fuseki-geospatial >>>>>> >>>>>> and under org.apache.jena.geosparql and >>>> org.apache.jena.fuseki.geosparql >>>>>> >>>>>> It would have to be maven. >>>>>> >>>>>> Documentation: >>>>>> This does not have to timed with the release though desirable to have >>>>>> some instructions on the website. >>>>>> >>>>>> Looking the modules, it has its own specialised Fuseki incarnation with >>>>>> command line arguments and also internally a system wide configuration. >>>>>> maybe, later, we might want to merge the Fuseki setup but exactly how >>>>>> and whether separate is better for users due to the specialised nature >>>>>> can wait. Release should get feedback after it is incorporated - >>>>>> "release early, release often". >>>>>> >>>>>> Greg - how does that sound? >>>>>> >>>>>> PMC - having more eyes on this would be helpful. >>>>>> >>>>>> If the timing is OK, we can work on details on the ticket JENA-664 (or >>>>>> email on dev@). >>>>>> >>>>>> == JENA-1691 : Prometheus metrics >>>>>> >>>>>> This is getting there. We have the code worked out, the packaging needs >>>>>> a bit of discussion; importantly it is missing L changes due to >>>>>> BSD-binaries in the combined jars mean some L changes. >>>>>> >>>>>> == JENA-1690 : SurroundQueryParser >>>>>> >>>>>> Looks like this is ready and waiting for someone to merge it. >>>>>> >>>>>> >>>>>> With all that, it looks like some things to sort out. >>>>>> >>>>>> We can wait a bit longer for 3.11.0, or do 3.11.0 fairly soon with >>>>>> whatever is ready, including getting things in and expect to further >>>>>> refine, then advance the timing on 3.12.0. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Andy >>>>> >>>> >>> > > > > -- > > > --- > Marco Neumann > KONA
Re: Towards Jena 3.11.0
+1 to releasing 3.11.0 as described and not loading it up any further. ajs6f On Wed, Apr 17, 2019, 6:14 AM Andy Seaborne wrote: > We seem to be trying to do too much in one release. As ever, people get > busy. > > https://s.apache.org/jena-3.11.0-jira >36 JIRA > > including fixes like JENA-1657 "Close response stream of http connections". > > While not a major problem at the moment, it can start to cause blockage > for other work. > > We could release 3.11.0 ASAP (it's 4 months since 3.10.0) and > immediately start on 3.12.0. I can RM 3.11.0 and have some time to help > with a 3.12 ... hoping to get it all done during May. > > Or we could just accept a delay to 3.11.0. > > It is the usual tension between perfect and timely with volunteer time! > > While my preference is release 3.11.0 now and start 3.12.0, either is OK > for me. > > Thoughts? > > Andy > > On 03/04/2019 21:16, Andy Seaborne wrote: > > We have three major streams outstanding. > > Have I missed anything? > > > > 1/ GeoSPARQL > > 2/ Prometheus metrics > > 3/ SurroundQueryParser > > > > == GeoSPARQL > > > > Greg - apologies for being tardy on this one. It looks in good shape. > > Did you hear from anyone after the request for feedback? > > > > This is two modules: geosparql-jena and geosparql-fuseki > > > > A suggestion for how to proceed if you have the time for 3.11.0 is that > > we include these basically as-is and remove jena-spatial from Fuseki > > which we have been signalling for a while. > > > > Suggestion: > > > >jena-geosparql > >jena-fuseki/jena-fuseki-geospatial > > > > and under org.apache.jena.geosparql and org.apache.jena.fuseki.geosparql > > > > It would have to be maven. > > > > Documentation: > > This does not have to timed with the release though desirable to have > > some instructions on the website. > > > > Looking the modules, it has its own specialised Fuseki incarnation with > > command line arguments and also internally a system wide configuration. > > maybe, later, we might want to merge the Fuseki setup but exactly how > > and whether separate is better for users due to the specialised nature > > can wait. Release should get feedback after it is incorporated - > > "release early, release often". > > > > Greg - how does that sound? > > > > PMC - having more eyes on this would be helpful. > > > > If the timing is OK, we can work on details on the ticket JENA-664 (or > > email on dev@). > > > > == JENA-1691 : Prometheus metrics > > > > This is getting there. We have the code worked out, the packaging needs > > a bit of discussion; importantly it is missing L changes due to > > BSD-binaries in the combined jars mean some L changes. > > > > == JENA-1690 : SurroundQueryParser > > > > Looks like this is ready and waiting for someone to merge it. > > > > > > With all that, it looks like some things to sort out. > > > > We can wait a bit longer for 3.11.0, or do 3.11.0 fairly soon with > > whatever is ready, including getting things in and expect to further > > refine, then advance the timing on 3.12.0. > > > > Thoughts? > > > > Andy >
Re: Sonar?
> On Apr 16, 2019, at 7:18 AM, Andy Seaborne wrote: > > https://sonarcloud.io/dashboard?id=jena-db-tdb2 > > which is new code for TDB2 rewritten for jena-dboe-storage. > > Some useful points, significant amount of noise to manage. > So IMO it is informative, and best used when there is active development in > the area. Diffs in numbers can be useful, the overall assessment of old > code, rather less so and risks being a burden on that old code (where tests > are important and IMO where any time is better spent). That's enough for me to want to turn it on. I agree that it is sometimes useful, sometimes just noise, but for me, having it turned on and being able to just go look at a webpage when that seems interesting is a lot easier (and more likely to be useful) than having to remember how to run it and then running it and then going to look for the report. As for the less useful reports from old code, we can simply ignore that or (depending on how much time I have) I can try to customize the settings across the codebase to minimize the junk from older styles. It should be easy enough to just turn off any notifications so that we don't get a barrage of junk every time someone makes a commit near older code. We can turn them on if or when that seems useful. Cool? > Would we insist on it for contributions? Hoep not - I'd rather see > contributions and tests. And if we don't insist, then who cleans up? Whoa, wait what?! Are there Apache projects that do that? (Require some certain score on this kind of analysis for a contribution?) I sincerely hope not, and I'd be the first -1 here at Jena against any such suggestion. That would be literally thoughtless. It sounds like there are no -1s (maybe a bit of skepticism from Andy as to how generally useful it could be :) ), so I'll see what it would take to turn it on (guessing a ticket to INFRA) and report back. ajs6f >Andy > > On 16/04/2019 11:37, Andy Seaborne wrote: >> TBH I don't think applying it overall is much help. >> There is tradeoff on old code between cleaning it and leaving it, warts and >> all, untouched so git history is not obscured (and "smells" I glanced at >> looked like "current style"). >> I actually find the Eclipse "Show revision information" quite useful. >> It can be run as Bruno has pointed to. >> --- >> Can it be focused on one part of the code base? Pointing to an active area >> where change is already happening might be more useful. >> Andy >> On 15/04/2019 22:44, Bruno P. Kinoshita wrote: >>> I feel like we had this discussion before... but could be in a different >>> project. I ran SonarQube a few times against Jena's codebase in the past, >>> but haven't done it in a while. >>> They also offer a cloud service similar to Travis, called SonarCloud.io: >>> https://sonarcloud.io/dashboard?id=org.apache.jena%3Ajena >>> +1 from me >>> Bruno >>> >>> On Tuesday, 16 April 2019, 1:54:30 am NZST, ajs6f >>> wrote: >>> I see that Apache has Sonar code analysis services at: >>> https://builds.apache.org/analysis and I wasn't able to find Jena there. It >>> would be interesting to see what Sonar says about the codebase. Of course >>> it has to be taken with a grain of salt, but it's often useful. >>> >>> Before I investigate turning Sonar on for our codebase, any >>> thoughts/objections/information? Am I missing anything (like we already >>> have it turned on and I just didn't see it, which happens all the time)? >>> >>> ajs6f >>>
Re: GeoSPARQL process
Thanks, Greg, this is very detailed. Once the new module is in and settled and we have a release or two to learn from, I will take a closer look at the usage of this code to understand how it differs from the kind of caching that occurs elsewhere in Jena. ajs6f > On Apr 14, 2019, at 6:21 AM, Greg Albiston wrote: > > Hi, > > There are a lot of permutations that a GeoSPARQL query could take which > can generate different values that may or may not be useful later on. > The general strategy is to keep what is generated for a while and if > isn't used then drop it. I don't think any of the Cache implementations > offer this or a suitable alternative. > > The expiring-map removes entries that haven't been reused after a period > of time. The duration to retain, rate of checking and maximum size can > all be set. It is used for three purposes: > > - The Geometry Wrapper object resulting from de-serialising the Geometry > Literals. > - The transformed Geometry Wrapper object from changing the spatial > reference system. > - The result of a spatial relation between two Geometry Literals to > avoid re-testing when Query Re-writing is applied. > > Most of the GeoSPARQL functions are between two Geometry Literals, so > one could be needed in the next iteration of the query and the other > could be needed later. > > The first purpose offers the biggest impact on performance as there are > additional de-serialising of the Geometry Literal while Jena is > processing the query. Complex shages, e.g. polygons, can be very costly > to extract. > > The second purpose offers most benefit when complex shapes need > transforming. These transformations may be needed again during this > query but not the next. e.g. dataset is in SRS A. Query 1 is a > comparison with a set of values in SRS B. Query 2 then is a comparison > with a set of values in SRS C. The results from Query 1 are useless and > may never be needed again. > > The third purpose is due to GeoSPARQL allowing query re-writing where > the Geometry Literal isn't specified and instead Features and Geometries > are used, so a single query could test the same spatial relations upto > four times depending on bindings. > > The expiring-map is allowed to fill up while the query is processing and > then drops entries that aren't reused (in batches) or once the query > completes. Once it is full, new entries are quickly rejected but space > is freed up later from those entries not being re-used. A user with a > small dataset can cache everything while a large dataset can choose to > constrain it to get some benefit from caching without consuming vast > junks of memory. > > I tried using the Apache Collections 4 LRUMap and it made performance > worse once it was filled (at a guess due to "one out, one in" and > constant searching). I only found one Java implementation of a time > based cache. It seemed excessive to have the whole dependency for one > class and it wasn't as flexible as required. > > Hopefully this clarifies why the expiring-map approach was adopted. > > Thanks, > > Greg > > On 10/04/2019 16:50, ajs6f wrote: >> Just out of curiosity, Greg, what is the functionality offered by Expiring >> Map that isn't offered by Jena's already-extant oaj.atlas.lib.Cache >> implementations? Is it the ability to manually trigger expirations? >> >> ajs6f >> >>> On Apr 9, 2019, at 12:02 PM, Andy Seaborne wrote: >>> >>> [INFO] | \- io.github.galbiston:expiring-map:jar:1.0.2:compile
Sonar?
I see that Apache has Sonar code analysis services at: https://builds.apache.org/analysis and I wasn't able to find Jena there. It would be interesting to see what Sonar says about the codebase. Of course it has to be taken with a grain of salt, but it's often useful. Before I investigate turning Sonar on for our codebase, any thoughts/objections/information? Am I missing anything (like we already have it turned on and I just didn't see it, which happens all the time)? ajs6f
Re: Contribution on jena api in Greek
Oh, goodness! I didn't realize we had already committed that. Euclid-- Andy is gently pointing out that I forgot that changes to our site don't become public until we republish the site, which we always do for a release, but not always in between. So even though your change has been accepted, it won't be visible until we republish the site. Sorry for the confusion! I'll see if I can remember how to publish… (man, I have to find some time to move the "put docs into Git" thread forward). ajs6f > On Apr 10, 2019, at 4:30 PM, Andy Seaborne wrote: > > staging > > On 10/04/2019 21:00, ajs6f wrote: >> Hi, Euclid! >> Indeed, this is good news. I'm not sure I ever saw a patch from our >> documentation that links your excellent work to our page of tutorials in >> various languages: >> https://jena.apache.org/tutorials/index.html >> Would you like to add one (using the "Improve this Page" link at the upper >> right)? Or perhaps I missed it? If so, I am sorry, but could you please send >> it again? >> ajs6f >>> On Apr 3, 2019, at 5:41 PM, Andy Seaborne wrote: >>> >>> Hi Euclid, >>> >>> Good to hear that. >>> >>>Andy >>> >>> >>> On 02/04/2019 07:49, Euclid Keramopoulos wrote: >>>> Hello, >>>> I would like to add also that we will maintain the documentation. >>>> Thank you, >>>> Euclid >>>> Στις Τρί, 26 Φεβ 2019 στις 10:33 π.μ., ο/η Euclid Keramopoulos < >>>> eucl...@gmail.com> έγραψε: >>>>> Hello, >>>>> I add a short description and a link to the tutorials page. >>>>> I am looking forward for your response. >>>>> Thank you, >>>>> Euclid >>>>> >>>>> Στις Δευ, 25 Φεβ 2019 στις 10:34 π.μ., ο/η Euclid Keramopoulos < >>>>> eucl...@gmail.com> έγραψε: >>>>> >>>>>> Hello, >>>>>> Thank you very much for your response and interest for our project. >>>>>> I will discuss with Mr Velonis your proposal. >>>>>> In the meantime, I will add the link to our project. >>>>>> Thank you! >>>>>> Euclid >>>>>> >>>>>> >>>>>> >>>>>> Στις Τρί, 19 Φεβ 2019 στις 5:48 μ.μ., ο/η ajs6f >>>>>> έγραψε: >>>>>> >>>>>>> Hello, Euclid, >>>>>>> >>>>>>> First of all, thank you very much for this work! It's really great to >>>>>>> see this interest in Jena, especially in documentation. >>>>>>> >>>>>>> I'm not equipped to render a useful opinion about your work (I don't >>>>>>> read Greek), so I'll leave that to others, but I do want to ask you if >>>>>>> you >>>>>>> think you would be able to commit to maintaining this suite of >>>>>>> documentation. If so, we could potentially talk about contributing it to >>>>>>> the project, but if not (which would be very understandable) I think it >>>>>>> would be best maintained as a standalone project. >>>>>>> >>>>>>> As for a link on that page, if you look at the top right, you should see >>>>>>> a button labeled "Improve this Page". You can use the editor available >>>>>>> there to send a change to that page and include your link. I can >>>>>>> immediately commit it. Thanks! >>>>>>> >>>>>>> ajs6f >>>>>>> >>>>>>>> On Feb 14, 2019, at 7:30 AM, Euclid Keramopoulos >>>>>>> wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> We would like to contribute to Jena Api by developing educational >>>>>>> material >>>>>>>> regarding jena api in Greek. Mr George Velonis, an MSc student, worked >>>>>>>> under my supervision for his final thesis in order to produce that >>>>>>>> educational material. In the http://sw.it.teithe.gr/tutorials/jenagr/ >>>>>>> is >>>>>>>> the greek translation of most of the basic subjects regarding jena api, >>>>>>>> such as RDF API Tutorial, Ontology API, SPARQL Tutorial. >>>>>>>> >>>>>>>> Could you tell me what do you think of the produced material and if it >>>>>>> is >>>>>>>> possible to add our Greek tutorial under the “Jena tutorials in other >>>>>>>> languages” section? >>>>>>>> >>>>>>>> Yours sincerely, >>>>>>>> >>>>>>>> Euclid Keramopoulos >>>>>>>> >>>>>>>> -- >>>>>>>> Euclid Keramopoulos >>>>>>>> Associate Professor >>>>>>>> Department of Information Tecnhology >>>>>>>> Alexander Technological Educational Institute of Thessaloniki >>>>>>>> PO Box 141, GR 57400 >>>>>>>> Greece >>>>>>>> Skype: euclidkeramopoulos >>>>>>>> Tel. +302310013998 >>>>>>>> Fax. +302310798256 >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Euclid Keramopoulos >>>>>> Associate Professor >>>>>> Department of Information Tecnhology >>>>>> Alexander Technological Educational Institute of Thessaloniki >>>>>> PO Box 141, GR 57400 >>>>>> Greece >>>>>> Skype: euclidkeramopoulos >>>>>> Tel. +302310013998 >>>>>> Fax. +302310798256 >>>>>> >>>>> >>>>> >>>>> -- >>>>> Euclid Keramopoulos >>>>> Associate Professor >>>>> Department of Information Tecnhology >>>>> Alexander Technological Educational Institute of Thessaloniki >>>>> PO Box 141, GR 57400 >>>>> Greece >>>>> Skype: euclidkeramopoulos >>>>> Tel. +302310013998 >>>>> Fax. +302310798256 >>>>>
Re: Contribution on jena api in Greek
Hi, Euclid! Indeed, this is good news. I'm not sure I ever saw a patch from our documentation that links your excellent work to our page of tutorials in various languages: https://jena.apache.org/tutorials/index.html Would you like to add one (using the "Improve this Page" link at the upper right)? Or perhaps I missed it? If so, I am sorry, but could you please send it again? ajs6f > On Apr 3, 2019, at 5:41 PM, Andy Seaborne wrote: > > Hi Euclid, > > Good to hear that. > >Andy > > > On 02/04/2019 07:49, Euclid Keramopoulos wrote: >> Hello, >> I would like to add also that we will maintain the documentation. >> Thank you, >> Euclid >> Στις Τρί, 26 Φεβ 2019 στις 10:33 π.μ., ο/η Euclid Keramopoulos < >> eucl...@gmail.com> έγραψε: >>> Hello, >>> I add a short description and a link to the tutorials page. >>> I am looking forward for your response. >>> Thank you, >>> Euclid >>> >>> Στις Δευ, 25 Φεβ 2019 στις 10:34 π.μ., ο/η Euclid Keramopoulos < >>> eucl...@gmail.com> έγραψε: >>> >>>> Hello, >>>> Thank you very much for your response and interest for our project. >>>> I will discuss with Mr Velonis your proposal. >>>> In the meantime, I will add the link to our project. >>>> Thank you! >>>> Euclid >>>> >>>> >>>> >>>> Στις Τρί, 19 Φεβ 2019 στις 5:48 μ.μ., ο/η ajs6f >>>> έγραψε: >>>> >>>>> Hello, Euclid, >>>>> >>>>> First of all, thank you very much for this work! It's really great to >>>>> see this interest in Jena, especially in documentation. >>>>> >>>>> I'm not equipped to render a useful opinion about your work (I don't >>>>> read Greek), so I'll leave that to others, but I do want to ask you if you >>>>> think you would be able to commit to maintaining this suite of >>>>> documentation. If so, we could potentially talk about contributing it to >>>>> the project, but if not (which would be very understandable) I think it >>>>> would be best maintained as a standalone project. >>>>> >>>>> As for a link on that page, if you look at the top right, you should see >>>>> a button labeled "Improve this Page". You can use the editor available >>>>> there to send a change to that page and include your link. I can >>>>> immediately commit it. Thanks! >>>>> >>>>> ajs6f >>>>> >>>>>> On Feb 14, 2019, at 7:30 AM, Euclid Keramopoulos >>>>> wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> We would like to contribute to Jena Api by developing educational >>>>> material >>>>>> regarding jena api in Greek. Mr George Velonis, an MSc student, worked >>>>>> under my supervision for his final thesis in order to produce that >>>>>> educational material. In the http://sw.it.teithe.gr/tutorials/jenagr/ >>>>> is >>>>>> the greek translation of most of the basic subjects regarding jena api, >>>>>> such as RDF API Tutorial, Ontology API, SPARQL Tutorial. >>>>>> >>>>>> Could you tell me what do you think of the produced material and if it >>>>> is >>>>>> possible to add our Greek tutorial under the “Jena tutorials in other >>>>>> languages” section? >>>>>> >>>>>> Yours sincerely, >>>>>> >>>>>> Euclid Keramopoulos >>>>>> >>>>>> -- >>>>>> Euclid Keramopoulos >>>>>> Associate Professor >>>>>> Department of Information Tecnhology >>>>>> Alexander Technological Educational Institute of Thessaloniki >>>>>> PO Box 141, GR 57400 >>>>>> Greece >>>>>> Skype: euclidkeramopoulos >>>>>> Tel. +302310013998 >>>>>> Fax. +302310798256 >>>>> >>>>> >>>> >>>> -- >>>> Euclid Keramopoulos >>>> Associate Professor >>>> Department of Information Tecnhology >>>> Alexander Technological Educational Institute of Thessaloniki >>>> PO Box 141, GR 57400 >>>> Greece >>>> Skype: euclidkeramopoulos >>>> Tel. +302310013998 >>>> Fax. +302310798256 >>>> >>> >>> >>> -- >>> Euclid Keramopoulos >>> Associate Professor >>> Department of Information Tecnhology >>> Alexander Technological Educational Institute of Thessaloniki >>> PO Box 141, GR 57400 >>> Greece >>> Skype: euclidkeramopoulos >>> Tel. +302310013998 >>> Fax. +302310798256 >>>
Re: GeoSPARQL process
Just out of curiosity, Greg, what is the functionality offered by Expiring Map that isn't offered by Jena's already-extant oaj.atlas.lib.Cache implementations? Is it the ability to manually trigger expirations? ajs6f > On Apr 9, 2019, at 12:02 PM, Andy Seaborne wrote: > > [INFO] | \- io.github.galbiston:expiring-map:jar:1.0.2:compile
Re: [DRAFT] Apache Jena Report : April 2019
I don't really see in what sense Jena competes with Oracle or MySQL (top two listings) or for that matter, Google Cloud Spanner (?), ClickHouse (?), or Apache Drill. I'll admit, I'm a little annoyed by being outranked by something called "CockroachDB", but that's probably just a bit of prejudice on my part. ajs6f > On Apr 7, 2019, at 10:43 AM, Marco Neumann wrote: > > maybe somewhat related. I have noticed that the Jena project was the > biggest loser in the db-engines ranking for the year ending in April > 2019. > > https://db-engines.com/en/ranking > > https://db-engines.com/en/system/Apache+Jena+-+TDB > > Jena is now down to place 118 from 85 in April 2018. I have very > briefly discussed this with Andy Seaborne but would like to hear from > dev list members on this and the db ranking in general. > > Is there anything we can learn from this that would help us to raise > visibility and recognition of the project? Should the ranking be > ignored? > > Marco > > On Sun, Apr 7, 2019 at 1:36 PM Andy Seaborne wrote: >> >> FYI: This month we got weevils and hedgehogs. >> >> The report generator puts in default text: >> >> ## Issues: >> - TODO - list any issues that require board attention, >> or say "there are no issues requiring board attention at this time" >>- if not, the weevils will get you. >> >> >> ## Health report: >> - TODO - Please use this paragraph to elaborate on why >>the current project activity (mails, commits, bugs etc) is at its >>current level - Maybe hedgehogs took over and are now controlling >>the project? >> >> >> >> - >> >> More mundanely: >> >> - >> >> ## Description: >> >> Jena is a framework for developing Semantic Web and Linked Data >> applications in Java. It provides implementation of W3C standards for >> RDF and SPARQL. >> >> ## Issues: >> >> There are no issues requiring board attention at this time. >> >> ## Activity: >> >> The project has continued to evolve the codebase. It is still in the >> process of incorporating the significant contribution of a GeoSPARQL, >> mainly restricted by PMC members bandwidth. >> >> Elsewhere, a new contribution of metrics support for the Jena Fuseki, >> triplestore protocol engine, has been received and the project is >> working with the contributor to incorporate that. >> >> Discussion of release 3.11.0 has started. >> >> ## Health report: >> >> The project is at normal levels of activity, with JIRA and git pull >> requests getting being responded to, and the users list remains active. >> >> ## PMC changes: >> >> - Currently 14 PMC members. >> - Aaron Coburn was added to the PMC on Tue Jan 22 2019 >> >> ## Committer base changes: >> >> - Currently 17 committers. >> - No new committers added in the last 3 months >> - Last committer addition was Aaron Coburn at Mon Jun 18 2018 >> >> ## Releases: >> >> - Last release was 3.10.0 on Sun Dec 30 2018 >> >> ## JIRA activity: >> >> - 45 JIRA tickets created in the last 3 months >> - 31 JIRA tickets closed/resolved in the last 3 months >> > > > -- > > > --- > Marco Neumann > KONA
Re: [DRAFT] Apache Jena Report : April 2019
LGTM, two possible typos as shown below. ajs6f > On Apr 7, 2019, at 8:35 AM, Andy Seaborne wrote: > > > The project has continued to evolve the codebase. It is still in the process > of incorporating the significant contribution of a GeoSPARQL, mainly > restricted by PMC members bandwidth. "a GeoSPARQ" = "a GeoSPARQ implementation" or "a GeoSPARQ module"? > Elsewhere, a new contribution of metrics support for the Jena Fuseki, > triplestore protocol engine, has been received and the project is working > with the contributor to incorporate that. "for the Jena Fuseki, triplestore protocol engine" => "for the Jena Fuseki triplestore protocol engine"
Re: CMS diff: Fuseki : Main Server
Thank you Joost, committed!
ajs6f
> On Apr 5, 2019, at 7:59 PM, Joost van Ulden wrote:
>
> Clone URL (Committers only):
> https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/documentation%2Ffuseki2%2Ffuseki-main.md
>
> Joost van Ulden
>
> Index: trunk/content/documentation/fuseki2/fuseki-main.md
> ===
> --- trunk/content/documentation/fuseki2/fuseki-main.md(revision
> 1856979)
> +++ trunk/content/documentation/fuseki2/fuseki-main.md(working copy)
> @@ -1,12 +1,12 @@
> Title: Fuseki : Main Server
>
> -Fuseki main is a packaging of Fuseki as trile store without a UI for
> administration.
> +Fuseki main is a packaging of Fuseki as a triple store without a UI for
> administration.
>
>
> Fuseki can be run in the background by an application as an embedded server.
> The
> application can safely work with the dataset directly from java while having
> Fuseki
> provide SPARQL access over HTTP. An embedded server is useful for
> -adding functonality around a triple store and also for development and
> testing.
> +adding functionality around a triple store and also for development and
> testing.
>
> * [Running as a deployment or development server](#fuseki-server)
> * [Application Use](#usage)
> @@ -31,7 +31,7 @@
> The arguments are the same as the
> [full UI server command line
> program](http://jena.apache.org/documentation/fuseki2/fuseki-run.html#fuseki-standalone-server).
> -There are no special enviornment variables.
> +There are no special environment variables.
>
>
> The entry point is `org.apache.jena.fuseki.main.cmds.FusekiMainCmd` so
> @@ -95,7 +95,7 @@
> See section "[Logging](#logging)" for details.
>
> If the application wishes to use a dataset with a
> [text-index](http://jena.apache.org/documentation/query/text-query.html)
> -then the application wil also need to include jena-text in its dependencies.
> +then the application will also need to include jena-text in its dependencies.
>
> ## Logging {#logging}
>
>
Re: website to git Re: [DISCUSS] Move Jena repo to gitbox or github
Replies inline. ajs6f > On Dec 12, 2018, at 1:25 PM, Andy Seaborne wrote: > > I'd like to move the site. +1! > On 12/12/2018 15:25, ajs6f wrote: >> I'm all in favor, and in favor of moving the site to git at the same time. >> Indeed, we've discussed that latter before, but done nothing. >> Bruno-- I think you had some thoughts about the site question? I seem to >> remember that you did such a migration with another Apache project? > > Wasn't one of the issues that CMS is tied to svn for publication? Or am I > misremembering? I don't remember, which means nothing. :grin: It very well may be. See next point. > If so, then then move needs the website converting (Jekyll?). The last time we talked about this, that was an assumption (moving to a new build tool). I seem to recall that Bruno offered some experience from his work doing the same thing for another project. > If that's true we could get a git repo for the new site, work on it as and > when, then swap the live site. > > Does someone want to see this through? I would, albeit _slowly_, if I knew anything about the prospective build tool, or if someone else who does can be available for a bit of help. >Andy > >> ajs6f >>> On Dec 12, 2018, at 8:35 AM, Andy Seaborne wrote: >>> >>> >>> >>> On 11/12/2018 17:19, Chris Tomlinson wrote: >>>> Hi Andy, >>>> My GH and ASF accounts are linked. As I understand the note from D.Gruno >>>> once jena is moved to GB then we can use either GB or GH or both in our >>>> individual workflows. For me just working with GH would be my choice. >>>> I’m not sure how far away 3.10.0 is (I’ve completed all of the pending >>>> jena-text updates for 3.10.0) but maybe it makes sense if that release can >>>> be completed prior to moving from git-wip-us without running into the >>>> forced move beginning on 7 Feb 2019. >>> >>> I'd like to avoid a forced move, if nothing else, out of politeness to >>> INFRA because they asked nicely. >>> >>>> It would also be helpful to see the docs moved from SVN to GH/GB so we >>>> have a single environment. I think I saw this discussed briefly some time >>>> ago but I don’t recall a resolution. >>>> I agree that JIRA integration is key - it appears that it will continue >>>> since JIRA is used to control the migration from git-wip-us and svn. >>>> Regards, >>>> Chris >>>>> On Dec 11, 2018, at 5:37 AM, Andy Seaborne wrote: >>>>> >>>>> Committers - >>>>> >>>>> Who has the link up for pushing to GH directly? >>>>> >>>>> https://gitbox.apache.org/ -> "Link GitHub and ASF accounts" >>>>> >>>>>Andy >>>>> >>>>> On 10/12/2018 16:11, Andy Seaborne wrote: >>>>>> I confess I don't completely understand the details/changes here >>>>>> "either the ASF repository system (gitbox.apache.org) OR GitHub for your >>>>>> development and code pushes" >>>>>> unless you can mix-and-match, in case anyone does not want to forced to >>>>>> have a GH account. gitbox.apache.org says "will be granted write-access >>>>>> on both services (gitbox and github)" if you have your GH account linked >>>>>> to your Apache account (which I do). >>>>>> The other unclarity is what happens about JIRA integration. We have >>>>>> managed to get people to use JIRA so whatever we may think about it at a >>>>>> technical level, we do have as a communication path. The Q has been >>>>>> asked on the infra list but no response yet. The text about either >>>>>> service sort of hints that that if there is an integration, it works on >>>>>> both access points. >>>>>> JIRA is useful during a release to find changes since last time. >>>>>> Obviously, GH issues and labels can be used for that but we need to set >>>>>> that up. There again, a clearout of old dead stuff would not be so bad! >>>>>> We have a release sometime soon (ish, maybe, whatever) and I think my >>>>>> only issue is controlling the switchover point in time, sooner is >>>>>> better, and otherwise we do it and see what happens. >>>>>> For workflow, if we have to fix on one tailored to GH or gitbox.a.o, >>>>>> shall we go GH? If i
Re: jena/publish
Yes, it's possible to release the site without making a new code release, although I admit I don't know much about it. It's triggered using the Apache CMS system, and can be done using the same controls we use to make commits from the anonymous submissions we get on the website. ajs6f > On Feb 25, 2019, at 9:45 AM, Chris Tomlinson > wrote: > > Hi, > > I’ve committed the several pending changes (Vincent Ventresque and Sorin > Gheorghiu) to documentation/query/text-query.html. > > Is the documentation only published at release points or may it be published > now to pick current updates that apply to 3.10? > > There are pending changes in: spatial, text, fuseki1, dataset_description, > fuseji_integration, assembler, migrate_jena2_jena3, and tdb2_cmds. > > Thank you, > Chris >
Re: Contribution on jena api in Greek
Hello, Euclid, First of all, thank you very much for this work! It's really great to see this interest in Jena, especially in documentation. I'm not equipped to render a useful opinion about your work (I don't read Greek), so I'll leave that to others, but I do want to ask you if you think you would be able to commit to maintaining this suite of documentation. If so, we could potentially talk about contributing it to the project, but if not (which would be very understandable) I think it would be best maintained as a standalone project. As for a link on that page, if you look at the top right, you should see a button labeled "Improve this Page". You can use the editor available there to send a change to that page and include your link. I can immediately commit it. Thanks! ajs6f > On Feb 14, 2019, at 7:30 AM, Euclid Keramopoulos wrote: > > Hello, > > We would like to contribute to Jena Api by developing educational material > regarding jena api in Greek. Mr George Velonis, an MSc student, worked > under my supervision for his final thesis in order to produce that > educational material. In the http://sw.it.teithe.gr/tutorials/jenagr/ is > the greek translation of most of the basic subjects regarding jena api, > such as RDF API Tutorial, Ontology API, SPARQL Tutorial. > > Could you tell me what do you think of the produced material and if it is > possible to add our Greek tutorial under the “Jena tutorials in other > languages” section? > > Yours sincerely, > > Euclid Keramopoulos > > -- > Euclid Keramopoulos > Associate Professor > Department of Information Tecnhology > Alexander Technological Educational Institute of Thessaloniki > PO Box 141, GR 57400 > Greece > Skype: euclidkeramopoulos > Tel. +302310013998 > Fax. +302310798256
Re: From PR #528 - policy around SDB.
+1. The advantage of a low-use part is that it is also low-risk to improve it. ajs6f > On Feb 15, 2019, at 12:26 PM, Andy Seaborne wrote: > > PMC level > > It is good to see contributions from Grapham Trigg to SDB. > > While there is activity around SDB, I don't think the general community is > paying much attention code-level to it. > > Nowadays, I barely have an MySQL setup running, and no PostGreSQL, and don't > use SDB for real so performance validation isn't possible. > > I think we should apply PRs quite freely providing the basics of checking > process and IP are done. > > Any comments? > >Andy > > Forwarded Message > Subject: [GitHub] afs commented on issue #528: Allow direct loading of tuples > without temporary tables > Date: Fri, 15 Feb 2019 14:05:43 - > > afs commented on issue #528 > URL: https://github.com/apache/jena/pull/528#issuecomment-464061578 > > The project position on SDB is currently that it is discouraged for new > applications and that problems with the module SDB would not block a release; > it would get dropped for the release. > > On that basis, I'm inclined to be quite permissive about changes to SDB. If > someone can make something better that works for them, then merge it. > > I'm not sure how many users there are and what databases they use. > Historicially MySQL has been the most commonly used backend. >
Re: Another extra module
Agreed. Graphana is a very useful product (although I've only ever seen it deployed for IT monitoring and performance-- I don't know how much adoption it has outside of that) but a more generic solution would be best. There are also some interesting potential "metrics" that would be specific (or nearly so) to Jena. For example, what if you wanted to track the action of your inferencing machinery? ajs6f > On Feb 6, 2019, at 3:39 AM, Bruno P. Kinoshita wrote: > > Hi Claude, > > Wouldn't it be easier to actually have a module for exposing metrics, like > jena-prometheus? Or jena-metrics? JupyterHub does that > (https://github.com/jupyterhub/jupyterhub/blob/master/jupyterhub/metrics.py), > but it's as easy to implement that in Java as in Python. > That way you could display the metrics on Graphana > (https://prometheus.io/docs/visualization/grafana/), or Kibana > (https://www.elastic.co/guide/en/beats/metricbeat/master/metricbeat-module-prometheus.html), > or even plug into another monitoring system like Nagios > (https://github.com/prometheus/nagios_plugins), Zabbix > (https://www.zabbix.com/integrations/prometheus), etc. > > Having some Zeppelin module/kernel (use Python notebooks, but guess there's > something with the same name) would be interesting. Write SPARQL queries, > show how the installation of Jena Text can be done, with assembler files with > syntax highlighting. There are a few possible use cases, though I suspect it > should be possible to do these items with Python Notebooks/Zeppelin now (plus > some glue code). > CheersBruno > >On Wednesday, 6 February 2019, 8:19:54 pm NZDT, Claude Warren > wrote: > > My understanding of Graphana is that they provide charts (aka visual graphs > but just to keep the nomenclature clear I will call them charts) for data. > They are source agnostic and currently talk to a number of databases. The > idea is to allow a user/admin to create queries that would be charted by > Graphana. Very early investigation. I was just wondering if such a module > would be a good fit for the "extras". > > I also think that having adapters to make it easy to pull and display data > from Jena/Fuseki might bring an up-tick in adoption. At one time I thought > about Zeppelin as a frontend. > > Claude > > On Tue, Feb 5, 2019 at 10:25 PM ajs6f wrote: > >> This would make Graphana metrics appear as RDF in the Jena API? >> >> ajs6f >> >>> On Feb 3, 2019, at 2:40 PM, Claude Warren wrote: >>> >>> After spending some time at FOSDEM this weekend, i am going to look into >>> creating a Jena adapter for Graphana. Is this the sort of module we >> might >>> consider for inclusion as an extra module? >>> >>> Claude >> >> > > -- > I like: Like Like - The likeliest place on the web > <http://like-like.xenei.com> > LinkedIn: http://www.linkedin.com/in/claudewarren
Re: Another extra module
This would make Graphana metrics appear as RDF in the Jena API? ajs6f > On Feb 3, 2019, at 2:40 PM, Claude Warren wrote: > > After spending some time at FOSDEM this weekend, i am going to look into > creating a Jena adapter for Graphana. Is this the sort of module we might > consider for inclusion as an extra module? > > Claude
Re: CMS diff: Jena Full Text Search
I think I left this drop, and I apologize. Vincent, can you resend your patch, but this time without the unnecessary assertions (as pointed out by Andy et al.)? If not, that's okay, I can reassemble it myself from the mailing list. Thanks either way! ajs6f > On Jan 29, 2019, at 4:42 AM, Andy Seaborne wrote: > > > > On 28/01/2019 21:01, vincent ventresque wrote: >> Hi Ajs6f >> Thanks for including me in the conversation, but I have to confess I've >> never looked at java classes (I only use command line tools). >> Le 28/01/2019 à 21:05, ajs6f a écrit : >>>> On Jan 28, 2019, at 2:57 PM, Chris Tomlinson >>>> wrote: >>>> >>>> Hi Adam, >>>> >>>> I haven’t seen that error. What I’ve done in the past is to replace the >>>> jena-text doc file with the new contents in Eclipse in an SVN checkout of >>>> the jena-doc-site and then committed. >>> I can definitely do that (and will when we're happy with the patch), but >>> see below. >>> >>>> Out of curiosity when is it necessary to use the >>>> >>>> [] ja:loadClass "org.apache.jena.tdb.TDB” . >>>> >>>> and >>>> >>>> [] ja:loadClass "org.apache.jena.query.text.TextQuery” . > > It's not necessary any more. > > The ServiceLoader Jena initialization does this. > > The other initialization step should also be unnecessary: > > tdb:DatasetTDB rdfs:subClassOf ja:RDFDataset . > tdb:GraphTDBrdfs:subClassOf ja:Model . > >>>> >>>> ? I do not use them in the config when running fuseki war in tomcat. >>> I have no idea whatsoever! :grin: I wouldn't have thought them needed >>> either. >>> >>> Vincent-- any comment? >>> >>> ajs6f >>> >>> >>>> Regards, >>>> Chris >>>> >>>> >>>> >>>>> On Jan 28, 2019, at 11:11 AM, ajs6f wrote: >>>>> >>>>> Recently Vincent offered a nice patch to our text indexing documentation, >>>>> as shown below. Oddly, when I now go to merge it (a bit late, sorry!), I >>>>> get an error: "Can't locate anonymous's tree to clone". Is anyone >>>>> familiar with that? I know very little about the SVN-based CMS, so I'm >>>>> not even sure where to start looking... >>>>> >>>>> ajs6f
Re: CMS diff: Jena Full Text Search
> On Jan 28, 2019, at 2:57 PM, Chris Tomlinson > wrote: > > Hi Adam, > > I haven’t seen that error. What I’ve done in the past is to replace the > jena-text doc file with the new contents in Eclipse in an SVN checkout of the > jena-doc-site and then committed. I can definitely do that (and will when we're happy with the patch), but see below. > Out of curiosity when is it necessary to use the > > [] ja:loadClass "org.apache.jena.tdb.TDB” . > > and > >[] ja:loadClass "org.apache.jena.query.text.TextQuery” . > > ? I do not use them in the config when running fuseki war in tomcat. I have no idea whatsoever! :grin: I wouldn't have thought them needed either. Vincent-- any comment? ajs6f > Regards, > Chris > > > >> On Jan 28, 2019, at 11:11 AM, ajs6f wrote: >> >> Recently Vincent offered a nice patch to our text indexing documentation, as >> shown below. Oddly, when I now go to merge it (a bit late, sorry!), I get an >> error: "Can't locate anonymous's tree to clone". Is anyone familiar with >> that? I know very little about the SVN-based CMS, so I'm not even sure where >> to start looking... >> >> ajs6f >
Re: CMS diff: Jena Full Text Search
Recently Vincent offered a nice patch to our text indexing documentation, as shown below. Oddly, when I now go to merge it (a bit late, sorry!), I get an error: "Can't locate anonymous's tree to clone". Is anyone familiar with that? I know very little about the SVN-based CMS, so I'm not even sure where to start looking... ajs6f > On Jan 23, 2019, at 12:01 PM, vincent.ventres...@ens-lyon.fr > wrote: > > Clone URL (Committers only): > https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/documentation%2Fquery%2Ftext-query.mdtext > > vincent.ventres...@ens-lyon.fr > > Index: trunk/content/documentation/query/text-query.mdtext > === > --- trunk/content/documentation/query/text-query.mdtext (revision > 1851871) > +++ trunk/content/documentation/query/text-query.mdtext (working copy) > @@ -609,21 +609,47 @@ > index field. More complex setups, with multiple properties per entity > (URI) are possible. > > +The assembler file can be either default configuration file > (.../run/config.ttl) > +or a custom file in ...run/configuration folder. Note that you can use > several files > +simultaneously. > + > +You have to edit the file (see comments in the assembler code below): > + > +1. provide values for paths and a fixed URI for tdb:DatasetTDB > +2. modify the entity map : add the fields you want to index and desired > options (filters, tokenizers...) > + > +If your assembler file is run/config.ttl, you can index the dataset with > this command : > + > +java -cp ./fuseki-server.jar jena.textindexer --desc=run/config.ttl > + > Once configured, any data added to the text dataset is automatically > -indexed as well. > +indexed as well : > https://jena.apache.org/documentation/query/text-query.html#building-a-text-index > > +When you change the jena-text in significant ways, such as changing what > analyzer > +is used for a given property and so on, then you’ll need to rebuild the > Lucene index > +via reloading the dataset or using the textIndexer. > + > ### Text Dataset Assembler > > The following is an example of a TDB dataset with a text index. > > + Example of a TDB dataset and text index# > +# The main doc sources are: > +# - > https://jena.apache.org/documentation/fuseki2/fuseki-configuration.html > +# - https://jena.apache.org/documentation/assembler/assembler-howto.html > +# - https://jena.apache.org/documentation/assembler/assembler.ttl > +# See https://jena.apache.org/documentation/fuseki2/fuseki-layout.html > for the destination of this file. > +# > + > @prefix :<http://localhost/jena_example/#> . > @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . > @prefix rdfs:<http://www.w3.org/2000/01/rdf-schema#> . > @prefix tdb: <http://jena.hpl.hp.com/2008/tdb#> . > @prefix ja: <http://jena.hpl.hp.com/2005/11/Assembler#> . > @prefix text:<http://jena.apache.org/text#> . > +@prefix skos: <http://www.w3.org/2004/02/skos/core#> > +@prefix fuseki: <http://jena.apache.org/fuseki#> . > > -## Example of a TDB dataset and text index > ## Initialize TDB > [] ja:loadClass "org.apache.jena.tdb.TDB" . > tdb:DatasetTDB rdfs:subClassOf ja:RDFDataset . > @@ -631,39 +657,64 @@ > > ## Initialize text query > [] ja:loadClass "org.apache.jena.query.text.TextQuery" . > + > # A TextDataset is a regular dataset with a text index. > text:TextDataset rdfs:subClassOf ja:RDFDataset . > + > # Lucene index > text:TextIndexLucene rdfs:subClassOf text:TextIndex . > -# Elasticsearch index > -text:TextIndexESrdfs:subClassOf text:TextIndex . > > + > ## --- > -## This URI must be fixed - it's used to assemble the text dataset. > > :text_dataset rdf:type text:TextDataset ; > -text:dataset <#dataset> ; > +text:dataset :my_dataset ; # <-- > replace `:my_dataset` with the desired URI > text:index <#indexLucene> ; > -. > +. > > # A TDB dataset used for RDF storage > -<#dataset> rdf:type tdb:DatasetTDB ; > -tdb:location "DB" ; > -tdb:unionDefaultGraph true ; # Optional > -. > > -# Text index description > +:my_dataset rd
Re: [GenericRuleReasoner] inner workings
I have no useful general information about the reasoning framework, but I am copying this over to dev@. Discussions of how to extend Jena definitely have a place there. ajs6f > On Jan 14, 2019, at 6:40 AM, Nouwt, B. (Barry) > wrote: > > Hi all, I want to investigate the inner workings of the GenericRuleReasoner > (with the purpose of extending it in the future). In Jena's documentation I > read: > > "Jena includes a general purpose rule-based reasoner which is used to > implement both the RDFS and OWL reasoners but is also available for general > use. This reasoner supports rule-based inference over RDF graphs and provides > forward chaining, backward chaining and a hybrid execution model. To be more > exact, there are two internal rule engines one forward chaining RETE engine > and one tabled datalog engine - they can be run separately or the forward > engine can be used to prime the backward engine which in turn will be used to > answer queries." > source: https://jena.apache.org/documentation/inference/#rules > > Apart from Jena's documentation, Jena's mailing lists and its source code, > are there any resources that can better help me grasp what is happening > inside the generic rule reasoner? For example, the text above mentions the > forward chaining RETE engine and the tabled datalog engine, are there any > scientific papers that I might read to better understand their inner workings? > > Maybe this question is better suited for the > dev@jena.apache.org<mailto:dev@jena.apache.org>? > > Regards, Barry > This message may contain information that is not intended for you. If you are > not the addressee or if this message was sent to you by mistake, you are > requested to inform the sender and delete the message. TNO accepts no > liability for the content of this e-mail, for the manner in which you use it > and for damage of any kind resulting from the risks inherent to the > electronic transmission of messages.
Re: [VOTE] Apache Jena 3.10.0 RC1
[ x ] +1 Approve the release Details as previously forwarded. ajs6f > On Dec 30, 2018, at 7:06 PM, Bruno P. Kinoshita wrote: > > > [ x ] +1 Approve the release > > > Building passing fine with `mvn clean test install -Pdev` on: > > Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; > 2018-06-18T06:33:14+12:00) > Maven home: /opt/apache-maven-3.5.4 > Java version: 1.8.0_191, vendor: Oracle Corporation, runtime: > /usr/lib/jvm/java-8-openjdk-amd64/jre > Default locale: en_NZ, platform encoding: UTF-8 > OS name: "linux", version: "4.15.0-43-generic", arch: "amd64", family: "unix" > > > Also had a look at the archives in the dist area, everything looking good. > > + does everything work on Linux? > > Yes > > + are the GPG signatures fine? > + are the checksums correct? > > Both above look OK. Key matching 04C95136D236A58F, no issues found with > checksums. > > + is there a source archive? > > Yes, and contents look OK. > > + can the source archive really be built? > (NB This requires a "mvn install" first time) > > Yes, mvn clean install -Pdev worked fine, producing a 3.10.0 release. > > + is there a correct LICENSE and NOTICE file in each artifact > (both source and binary artifacts)? > > Looked at a few artefacts and everything seemed OK. > > + does the NOTICE file contain all necessary attributions? > > Looks OK. > > + have any licenses of dependencies changed due to upgrades? > if so have LICENSE and NOTICE been upgraded appropriately? > > Don't think so. All good IMO. > > + does the tag/commit in the SCM contain reproducible sources? > > Yes, built from SCM tag initially. > > Thanks for RM'ing > > Bruno > > > > > > > From: Andy Seaborne > To: "dev@jena.apache.org" > Sent: Monday, 31 December 2018 6:31 AM > Subject: [VOTE] Apache Jena 3.10.0 RC1 > > > > Hi, > > > Here is a vote on a release of Jena 3.10.0. > > This is the first proposed release candidate. > > > The deadline for the vote is Wednesday, 2 January 2019, at 21:00 UTC > > > Release changes: > > > 44 JIRA: > > > https://s.apache.org/jena-3.10.0-jira > > > == Retirements > > > Old modules retired and not in this release: > > > jena-fuseki1 > > jena-csv > > > See > > https://lists.apache.org/thread.html/edd5876b070f24091e19b5c1dd274ef46c74a0f920d419a29a59f66b@%3Cusers.jena.apache.org%3E > > > == Changes of note: > > > The project intends to replace jena-spatial in a future release with > > Greg's GeoSPARQL: > > https://github.com/galbiston/geosparql-jena > > > JENA-1621 : Lucene upgrade to 7.4 > >May need to reload Lucene indexes. > > > (e.g. the Lucene index was create originally with Lucene v5.x (prior > > Jena 3.3.0). See Lucene upgrade tool. > > https://lucene.apache.org/solr/guide/7_4/indexupgrader-tool.html > > > JENA-1623 : Fuseki security - user authentication and access control. > > JENA-1627 : HTTPs support > > > http://jena.staging.apache.org/documentation/fuseki2/data-access-control > > > == Updates > > > Only plugins. JENA-1624 > > > surefire : 2.21.0 -> 2.22.1 (+ SUREFIRE-1588) > > compiler : 3.7.0 -> 3.8.0 > > shade: 3.1.0 -> 3.2.0 > > > Release Vote > > > Everyone, not just committers, is invited to test and vote. > > Please download and test the proposed release. > > > Staging repository: > > https://repository.apache.org/content/repositories/orgapachejena-1028 > > > Proposed dist/ area: > >https://dist.apache.org/repos/dist/dev/jena/ > > > Keys: > >https://svn.apache.org/repos/asf/jena/dist/KEYS > > > Git commit (browser URL): > >https://github.com/apache/jena/commit/ab482e34 > > > Git Commit Hash: > > ab482e34584350af717db1a8d698aa3949e51871 > > > Git Commit Tag: > > jena-3.10.0 > > > Please vote to approve this release: > > >[ ] +1 Approve the release > >[ ] 0 Don't care > >[ ] -1 Don't release, because ... > > > This vote will be open to at least > > >Wednesday, 2 January 2019, at 20:00 UTC > > > If you expect to check the release but the time limit does not work > > for you, please email within the schedule above with an expected time > > and we can extend the vote
Re: [] Apache Jena 3.10.0 RC1
Yes, sorry, I've been distracted by issues at $work [1]. ajs6f [1] https://www.cnn.com/politics/live-news/government-shutdown-january-2019/index.html > On Jan 2, 2019, at 4:11 PM, Andy Seaborne wrote: > > ajs6f - does this answer your question enough to vote +1 now? > >Andy > > On 01/01/2019 12:48, Andy Seaborne wrote: >>> >>> ➜ source /usr/bin/shasum5.18 -a 512 -c >>> jena-3.10.0-source-release.zip.sha512 >>> shasum: jena-3.10.0-source-release.zip.sha512: no properly formatted SHA1 >>> checksum lines found >>> >>> because it only contains the checksum itself: >>> >>> d0b5e47616c847d76e77f214b0c346ece34950eb0a8e0e74bfe41888cc85d63aef8149543bc84711c3c2e2442cb5151dd5a66013ccc0805c5b3ec245d6463204 >>> >>> >>> and not also the filename to which it applies, e.g. : >>> >>> 7dafe7aa28cb85a6da9f6f2b109372ec0d097d4f07d8cb5882dde814b55cdb60512ab9bc09c2593118aaf3fbbc1f65f1d3b921faca7bddefd3f6bf9d7f332998 >>> apache-jena-3.10.0.tar.gz >>> >>> Is that a blocker for release? I'm not sure how precise the rules are about >>> the format of checksums. Do we just need to include them or to include them >>> in a certain format? >> Not a blocker. >> 3.9.0 is the same. >> The SHA512 checksum for the source-release is now made by maven during >> "-Papache release:" (It wasn't for 3.8.0, it was for 3.9.0.) The Apache >> parent has the process for this; it's not special to Jena. I'd prefer we >> used the Apache parent way. >> If you look at the SHA1 for the maven artifacts uploaded to central for >> 3.9.0 they are the same checksum only format: >> http://central.maven.org/maven2/org/apache/jena/jena-arq/3.9.0/jena-arq-3.9.0.jar.sha1 >> ==> >> b44ea2da8bdaf61e77272070f96ee2e29a70bfe3 >> The file name is not part of the checksum - you can edit the checksum file >> if you want: >> (cat foo.sha512 ; echo " foo") > S2 >> sha512sum -c S2 >> The 512 checksums for the binaries are added afterwards because the build >> process does not create them. It only processes source-release. >> https://cwiki.apache.org/confluence/display/JENA/Release+Process#ReleaseProcess-Fixupchecksums >> Andy
Re: [VOTE] Apache Jena 3.10.0 RC1
See question about checksums below. > + does everything work on OS X? Seems to. > + are the GPG signatures fine? Yes. > + are the checksums correct? Hm, yes for the binaries, but for sources, my edition of shasum doesn't recognize the file: ➜ source /usr/bin/shasum5.18 -a 512 -c jena-3.10.0-source-release.zip.sha512 shasum: jena-3.10.0-source-release.zip.sha512: no properly formatted SHA1 checksum lines found because it only contains the checksum itself: d0b5e47616c847d76e77f214b0c346ece34950eb0a8e0e74bfe41888cc85d63aef8149543bc84711c3c2e2442cb5151dd5a66013ccc0805c5b3ec245d6463204 and not also the filename to which it applies, e.g. : 7dafe7aa28cb85a6da9f6f2b109372ec0d097d4f07d8cb5882dde814b55cdb60512ab9bc09c2593118aaf3fbbc1f65f1d3b921faca7bddefd3f6bf9d7f332998 apache-jena-3.10.0.tar.gz Is that a blocker for release? I'm not sure how precise the rules are about the format of checksums. Do we just need to include them or to include them in a certain format? > + is there a source archive? Yes, built fine for me using Maven 3.5.3: Maven home: /usr/local/Cellar/maven/3.5.3/libexec Java version: 1.8.0_65, vendor: Oracle Corporation Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac" > + can the source archive really be built? > (NB This requires a "mvn install" first time) Yes. > + is there a correct LICENSE and NOTICE file in each artifact > (both source and binary artifacts)? Yes. > + does the NOTICE file contain all necessary attributions? I don't really know how to certify the NOTICE. It's correct to the best of my knowledge? > + does the tag/commit in the SCM contain reproducible sources? Yes. ajs6f > On Dec 30, 2018, at 12:31 PM, Andy Seaborne wrote: > > Hi, > > Here is a vote on a release of Jena 3.10.0. > This is the first proposed release candidate. > > The deadline for the vote is Wednesday, 2 January 2019, at 21:00 UTC > > Release changes: > > 44 JIRA: > > https://s.apache.org/jena-3.10.0-jira > > == Retirements > > Old modules retired and not in this release: > > jena-fuseki1 > jena-csv > > See > https://lists.apache.org/thread.html/edd5876b070f24091e19b5c1dd274ef46c74a0f920d419a29a59f66b@%3Cusers.jena.apache.org%3E > > == Changes of note: > > The project intends to replace jena-spatial in a future release with Greg's > GeoSPARQL: > https://github.com/galbiston/geosparql-jena > > JENA-1621 : Lucene upgrade to 7.4 > May need to reload Lucene indexes. > > (e.g. the Lucene index was create originally with Lucene v5.x (prior Jena > 3.3.0). See Lucene upgrade tool. > https://lucene.apache.org/solr/guide/7_4/indexupgrader-tool.html > > JENA-1623 : Fuseki security - user authentication and access control. > JENA-1627 : HTTPs support > > http://jena.staging.apache.org/documentation/fuseki2/data-access-control > > == Updates > > Only plugins. JENA-1624 > > surefire : 2.21.0 -> 2.22.1 (+ SUREFIRE-1588) > compiler : 3.7.0 -> 3.8.0 > shade: 3.1.0 -> 3.2.0 > > Release Vote > > Everyone, not just committers, is invited to test and vote. > Please download and test the proposed release. > > Staging repository: > https://repository.apache.org/content/repositories/orgapachejena-1028 > > Proposed dist/ area: >https://dist.apache.org/repos/dist/dev/jena/ > > Keys: >https://svn.apache.org/repos/asf/jena/dist/KEYS > > Git commit (browser URL): >https://github.com/apache/jena/commit/ab482e34 > > Git Commit Hash: > ab482e34584350af717db1a8d698aa3949e51871 > > Git Commit Tag: > jena-3.10.0 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > This vote will be open to at least > > Wednesday, 2 January 2019, at 20:00 UTC > > If you expect to check the release but the time limit does not work > for you, please email within the schedule above with an expected time > and we can extend the vote period. > > Thanks, > > Andy > > Checking needed: > > + does everything work on Linux? > + does everything work on MS Windows? > + does everything work on OS X? > + are the GPG signatures fine? > + are the checksums correct? > + is there a source archive? > > + can the source archive really be built? > (NB This requires a "mvn install" first time) > + is there a correct LICENSE and NOTICE file in each artifact > (both source and binary artifacts)? > + does the NOTICE file contain all necessary attributions? > + have any licenses of dependencies changed due to upgrades? > if so have LICENSE and NOTICE been upgraded appropriately? > + does the tag/commit in the SCM contain reproducible sources?
Re: [DRAFT] Apache Jena - January 2019
LGTM-- one possible typo: "standards based" => "standards-based". At least, that's how I've usually seen it. ajs6f > On Dec 30, 2018, at 10:51 AM, Andy Seaborne wrote: > > Draft board report for the January board meeting: > > --- > > > > ## Description: > > Jena is a framework for developing Semantic Web and Linked Data > applications in Java. It provides implementation of W3C standards for > RDF and SPARQL. > > ## Issues: > > There are no issues requiring board attention at this time. > > ## Activity: > > The project is currently voting on the 3.10.0 in line with the 3-4 month > cycle as and when volunteer time is available. > > The git repo was migrated seamlessly to gitbox - excellent process by INFRA. > > The project has received a significant contribution of a GeoSPARQL ending and > the team is migrating from the custom spatial query solution to the Open > Geospatial Consortium standards based one. > > The project is also retiring some unused modules that do not receive > attention and have had very little in the way of user questions over the last > few years. > > ## Health report: > > The project is at normal levels of activity, with JIRA and git pull requests > getting being responded to, and the users list remains active. There are also > many questions asked and answered on stackoverflow where answers come from a > wider community. > > ## PMC changes: > > - Currently 13 PMC members. > - No new PMC members added in the last 3 months > - Last PMC addition was Chris Tomlinson on Sun Apr 29 2018 > > ## Committer base changes: > > - Currently 17 committers. > - No new committers added in the last 3 months > - Last committer addition was Aaron Coburn at Mon Jun 18 2018 > > ## Releases: > > - Last release was Jena 3.9.0 on Fri Sep 28 2018 > > ## JIRA activity: > > - 44 JIRA tickets created in the last 3 months > - 58 JIRA tickets closed/resolved in the last 3 months >
Re: Draft: Retiring Jena modules.
Basically LGTM, but it might be nice to mention the specific GeoSPARQL impl under consideration. ajs6f > On Dec 13, 2018, at 6:53 AM, Andy Seaborne wrote: > > Draft for users@ > -- > > Hi Jena users, > > The project team is looking at retiring some lesser used modules. > > In the next release, modules: > > jena-fuseki1 > jena-csv > > will not be part of the release and there won't be maven artifacts. There > haven't been any changes to these modules and the code will be available from > git history. > > Beyond that we are looking at the status of: > > jena-spatial - to be replaced by a GeoSPARQL implemenetation > jena-sdb > jena-maven-tools - moving command line schemagen to jena-cmds. > > We're looking for feedback so please let us know if you use these modules > from a recent version of Jena. > >Andy >on behalf of the Jena dev team.
Re: [DISCUSS] Move Jena repo to gitbox or github
I have released Jena, at least once (I think maybe twice and I've forgotten!). It is _easy_. A lot is already scripted or automated in Maven. Honestly, the worst part is dealing with our SVN-based site, because it's big enough that one often has to break up large commits. It's really easy, and even fun. :grin: ajs6f > On Dec 12, 2018, at 3:26 PM, Bruno P. Kinoshita > wrote: > > I only released Apache Commons components. Would Jena be too > different/complex? > > I have GitHub 2FA, ASF gpg keys (4096), Maven settings.xml set up for ASF > maven repo. So if the process is not too hard for a beginner, I can volunteer > to either sidekick and review/learn the process, or to RM 3.10.0. > > I haven't done much Jena development, so maybe I can help running releases > and website migration & issues for now :) (also want to discuss Fuseki JS web > layer later, as backbone.js isn't being used much lately, and we could try > something simpler perhaps). > > > Cheers > Bruno > > > > From: Andy Seaborne > To: dev@jena.apache.org > Sent: Thursday, 13 December 2018 7:29 AM > Subject: Re: [DISCUSS] Move Jena repo to gitbox or github > > > > > > On 12/12/2018 15:53, Chris Tomlinson wrote: >> Hi Andy, >> >>> On Dec 12, 2018, at 7:35 AM, Andy Seaborne wrote: >>> >>> >>> >>> On 11/12/2018 17:19, Chris Tomlinson wrote: >>>> Hi Andy, >>>> My GH and ASF accounts are linked. As I understand the note from D.Gruno >>>> once jena is moved to GB then we can use either GB or GH or both in our >>>> individual workflows. For me just working with GH would be my choice. >>>> I’m not sure how far away 3.10.0 is (I’ve completed all of the pending >>>> jena-text updates for 3.10.0) but maybe it makes sense if that release can >>>> be completed prior to moving from git-wip-us without running into the >>>> forced move beginning on 7 Feb 2019. >>> >>> I'd like to avoid a forced move, if nothing else, out of politeness to >>> INFRA because they asked nicely. >> >> I certainly agree that we’d be better served by orchestrating a voluntary >> move. How far away is 3.10.0? > > Ssh! but I _hope_ end of Dec. Ish. Maybe slip into Jan. > > I'm not so worried about the git repo changes affecting things very > much. It happens automatically and at a point in time. Might/should > work to just edit .git/config > > > Andy > >> >> Regards, >> Chris >>
Re: [VOTE] Move the code repo to gitbox.apache.org
+1 Approve the move ajs6f > On Dec 12, 2018, at 1:21 PM, Chris Tomlinson > wrote: > > +1 To move code repo from git-wip-us to gitbox as soon as possible > > Chris > >> On Dec 12, 2018, at 12:17 PM, Andy Seaborne wrote: >> >> As per: email: >> https://lists.apache.org/thread.html/5762798313a642dc90076e3562c83457571d92758d0d73e6010af0d0@%3Cdev.jena.apache.org%3E >> >> this is a vote to move the code repo from git-wip-us.apache.org to the >> gitbox.apache.org service, which includes direct write access on github. >> >> If the vote passes, the INFRA ticket for the move would happen to take place >> as soon as possible. >> >> Please vote to approve this change >> >> [X] +1 Approve the move >> [ ] 0 Don't care >> [ ] -1 Don't move, because ... >> >> Andy >
Re: [DISCUSS] Move Jena repo to gitbox or github
I'm all in favor, and in favor of moving the site to git at the same time. Indeed, we've discussed that latter before, but done nothing. Bruno-- I think you had some thoughts about the site question? I seem to remember that you did such a migration with another Apache project? ajs6f > On Dec 12, 2018, at 8:35 AM, Andy Seaborne wrote: > > > > On 11/12/2018 17:19, Chris Tomlinson wrote: >> Hi Andy, >> My GH and ASF accounts are linked. As I understand the note from D.Gruno >> once jena is moved to GB then we can use either GB or GH or both in our >> individual workflows. For me just working with GH would be my choice. >> I’m not sure how far away 3.10.0 is (I’ve completed all of the pending >> jena-text updates for 3.10.0) but maybe it makes sense if that release can >> be completed prior to moving from git-wip-us without running into the forced >> move beginning on 7 Feb 2019. > > I'd like to avoid a forced move, if nothing else, out of politeness to INFRA > because they asked nicely. > >> It would also be helpful to see the docs moved from SVN to GH/GB so we have >> a single environment. I think I saw this discussed briefly some time ago but >> I don’t recall a resolution. >> I agree that JIRA integration is key - it appears that it will continue >> since JIRA is used to control the migration from git-wip-us and svn. >> Regards, >> Chris >>> On Dec 11, 2018, at 5:37 AM, Andy Seaborne wrote: >>> >>> Committers - >>> >>> Who has the link up for pushing to GH directly? >>> >>> https://gitbox.apache.org/ -> "Link GitHub and ASF accounts" >>> >>>Andy >>> >>> On 10/12/2018 16:11, Andy Seaborne wrote: >>>> I confess I don't completely understand the details/changes here >>>> "either the ASF repository system (gitbox.apache.org) OR GitHub for your >>>> development and code pushes" >>>> unless you can mix-and-match, in case anyone does not want to forced to >>>> have a GH account. gitbox.apache.org says "will be granted write-access on >>>> both services (gitbox and github)" if you have your GH account linked to >>>> your Apache account (which I do). >>>> The other unclarity is what happens about JIRA integration. We have >>>> managed to get people to use JIRA so whatever we may think about it at a >>>> technical level, we do have as a communication path. The Q has been asked >>>> on the infra list but no response yet. The text about either service sort >>>> of hints that that if there is an integration, it works on both access >>>> points. >>>> JIRA is useful during a release to find changes since last time. >>>> Obviously, GH issues and labels can be used for that but we need to set >>>> that up. There again, a clearout of old dead stuff would not be so bad! >>>> We have a release sometime soon (ish, maybe, whatever) and I think my only >>>> issue is controlling the switchover point in time, sooner is better, and >>>> otherwise we do it and see what happens. >>>> For workflow, if we have to fix on one tailored to GH or gitbox.a.o, shall >>>> we go GH? If it's both, we can start being more GH on our own timescales. >>>> Thoughts? >>>> Let's discuss for a few days and if nothing arises, run the vote. >>>> Andy >>>> But please, not go back to SVN :-) >>>> On 09/12/2018 20:47, Andy Seaborne wrote: >>>>> >>>>> [IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE >>>>>DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS] >>>>> >>>>> Hello Apache projects, >>>>> I am writing to you because you may have git repositories on the >>>>> git-wip-us server, which is slated to be decommissioned in the coming >>>>> months. All repositories will be moved to the new gitbox service which >>>>> includes direct write access on github as well as the standard ASF >>>>> commit access via gitbox.apache.org. >>>>> >>>>> ## Why this move? ## >>>>> The move comes as a result of retiring the git-wip service, as the >>>>> hardware it runs on is longing for retirement. In lieu of this, we >>>>> have decided to consolidate the two services (git-wip and gitbox), to >>>>> ease the management of our repository systems and future-proof the >>>>> underlying hardw
Re: [DISCUSS] Move Jena repo to gitbox or github
I've linked my account (many months ago). It changed nothing at all, not in Github, not elsewhere. I think we need to make the move for the project as a whole before that happens. (At a conference, but will try to reply to the larger migration question today-- TL;DR: I'm in favor.) ajs6f > On Dec 11, 2018, at 6:37 AM, Andy Seaborne wrote: > > Committers - > > Who has the link up for pushing to GH directly? > > https://gitbox.apache.org/ -> "Link GitHub and ASF accounts" > >Andy > > On 10/12/2018 16:11, Andy Seaborne wrote: >> I confess I don't completely understand the details/changes here >> "either the ASF repository system (gitbox.apache.org) OR GitHub for your >> development and code pushes" >> unless you can mix-and-match, in case anyone does not want to forced to have >> a GH account. gitbox.apache.org says "will be granted write-access on both >> services (gitbox and github)" if you have your GH account linked to your >> Apache account (which I do). >> The other unclarity is what happens about JIRA integration. We have managed >> to get people to use JIRA so whatever we may think about it at a technical >> level, we do have as a communication path. The Q has been asked on the >> infra list but no response yet. The text about either service sort of hints >> that that if there is an integration, it works on both access points. >> JIRA is useful during a release to find changes since last time. Obviously, >> GH issues and labels can be used for that but we need to set that up. There >> again, a clearout of old dead stuff would not be so bad! >> We have a release sometime soon (ish, maybe, whatever) and I think my only >> issue is controlling the switchover point in time, sooner is better, and >> otherwise we do it and see what happens. >> For workflow, if we have to fix on one tailored to GH or gitbox.a.o, shall >> we go GH? If it's both, we can start being more GH on our own timescales. >> Thoughts? >> Let's discuss for a few days and if nothing arises, run the vote. >> Andy >> But please, not go back to SVN :-) >> On 09/12/2018 20:47, Andy Seaborne wrote: >>> >>> [IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE >>>DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS] >>> >>> Hello Apache projects, >>> I am writing to you because you may have git repositories on the >>> git-wip-us server, which is slated to be decommissioned in the coming >>> months. All repositories will be moved to the new gitbox service which >>> includes direct write access on github as well as the standard ASF >>> commit access via gitbox.apache.org. >>> >>> ## Why this move? ## >>> The move comes as a result of retiring the git-wip service, as the >>> hardware it runs on is longing for retirement. In lieu of this, we >>> have decided to consolidate the two services (git-wip and gitbox), to >>> ease the management of our repository systems and future-proof the >>> underlying hardware. The move is fully automated, and ideally, nothing >>> will change in your workflow other than added features and access to >>> GitHub. >>> >>> ## Timeframe for relocation ## >>> Initially, we are asking that projects voluntarily request to move >>> their repositories to gitbox, hence this email. The voluntary >>> timeframe is between now and January 9th 2019, during which projects >>> are free to either move over to gitbox or stay put on git-wip. After >>> this phase, we will be requiring the remaining projects to move within >>> one month, after which we will move the remaining projects over. >>> >>> To have your project moved in this initial phase, you will need: >>> >>> - Consensus in the project (documented via the mailing list) >>> - File a JIRA ticket with INFRA to voluntarily move your project repos >>> over to gitbox (as stated, this is highly automated and will take >>> between a minute and an hour, depending on the size and number of >>> your repositories) >>> >>> To sum up the preliminary timeline; >>> >>> - December 9th 2018 -January 9th 2019: Voluntary (coordinated) >>> relocation >>> - January 9th -February 6th: Mandated (coordinated) relocation >>> - February 7th: All remaining repositories are mass migrated. >>> >>> This timeline may change to accommodate various scenarios. >>> >>> ## Using GitHub with ASF repositories #
[GitHub] jena pull request #501: JENA-1643: Use transactional dataset in clear().
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/501#discussion_r237830232
--- Diff: jena-tdb/src/main/java/org/apache/jena/tdb/store/GraphTDB.java ---
@@ -171,7 +171,10 @@ protected final int graphBaseSize() {
@Override
public void clear() {
-getDatasetGraphTDB().deleteAny(getGraphName(), Node.ANY, Node.ANY,
Node.ANY) ;
+// Logically, this is "super.clear()" except the default
implementation
+// is a loop that materializes nodes. We want to call the dataset
directly
+// so that nodes don't get materialized, just deleted from indexes.
--- End diff --
@afs Just for my education, what do you mean by "materialized" here?
---
Re: Toward Jena 3.10.0
This all makes sense to me. We've had a few nice contributions from various non-committer folks; perhaps we could mention them to give some credit? I'd like to give a straight Jira link but that kind of search is beyond my -fu. Here are some examples: https://issues.apache.org/jira/browse/JENA-1642 https://issues.apache.org/jira/browse/JENA-1606 ajs6f > On Nov 29, 2018, at 11:44 AM, Andy Seaborne wrote: > > Jena 3.1.0 would be around the end of the year. I'd like to make use of > Greg's GeoSPARQL project the "headline" item for the release and to retire > jena-spatial in 3.10.0 as an indication of this. > > Because retirement is a new process for the project, I'm sending this first > 3.10.0 message quite early to give us discussion time. > > == Retirements > > We have talked about this before but not actually done anything. See separate > thread for discussion on retirement process and for the first modules: > > jena-spatial > jena-fuseki1 > jena-csv > > == Headlines > > JENA-664 : GeoSPARQL support > > I'd like to make use of Greg's GeoSPARQL project the "headline" item for the > release and to retire jena-spatial in 3.10.0 as an indication of this. > > JENA-1621 : Lucene upgrade to 7.4 > May need to reload lucene indexes. > (e.g. the lucene index was create originally with Lucene v5.x (prior Jena > 3.3.0). See Lucene upgrade tool. > https://lucene.apache.org/solr/guide/7_4/indexupgrader-tool.html > > JENA-1623 : Fuseki security > JENA-1627 : HTTP support > https://issues.apache.org/jira/browse/JENA-1623 > http://jena.staging.apache.org/documentation/fuseki2/data-access-control > > == JIRA: > > 31 currently. > > https://s.apache.org/jena-3.10.0-jira > > == Updates > > Only plugins. JENA-1624 > > surefire : 2.21.0 -> 2.22.1 (+ SUREFIRE-1588) > compiler : 3.7.0 -> 3.8.0 > shade: 3.1.0 -> 3.2.0 > > Andy
Re: Module retirement
Sorry for the noise, but I just realized that I said the opposite of what I meant to! >> My only concern is that we should do it before people have a chance to fork should have read, > My only concern is that we should do it AFTER people have a chance to fork ajs6f > On Nov 29, 2018, at 11:48 AM, ajs6f wrote: > > I'd prefer (2). It's clean and it _uses_ VC instead of working around it. > > My only concern is that we should do it before people have a chance to fork, > because they'll want to do that as late as possible. But we can ameliorate > that by just making a couple of loud announcements first. We might want also > to make a point of pointing at replacements, even if they seem obvious to us. > > ajs6f > >> On Nov 29, 2018, at 11:45 AM, Andy Seaborne wrote: >> >> Let's retire some modules: >> >> jena-spatial [+] >> jena-fuseki1 >> jena-csv >> >> by not including them in the next release; they should all work but there >> isn't a way to signal "deprecation" other than by talking about it (which >> we've done) and doing it. >> >> There are several ways to go about this. >> >> 1/ have an area "archived/" with the modules moved there. >> This leaves them in the source-release and browsable in git. >> >> 2/ Delete from git. Maybe leave a file somewhere to record the commit ids. >> >> 3/ A new separate git-repo for "jena-misc" >> https://git-wip-us.apache.org/repos/asf/jena-misc.asf >> (or use gitbox and put it on github mirroed back to ASF.) >> >> and maybe some others. >> >> I think (1) is not definite enough. >> >> Thoughts/suggestions/... >> >> Andy >> >> [+] >> jena-spatial :: this is in jena-fuseki-webapp >> [INFO] +- org.apache.jena:jena-spatial:jar:3.10.0-SNAPSHOT:compile >> [INFO] | +- org.apache.lucene:lucene-spatial:jar:7.4.0:compile >> [INFO] | +- org.apache.lucene:lucene-spatial-extras:jar:7.4.0:compile >> [INFO] | | +- org.apache.lucene:lucene-spatial3d:jar:7.4.0:compile >> [INFO] | | \- io.sgr:s2-geometry-library-java:jar:1.0.0:compile >> [INFO] | \- org.locationtech.spatial4j:spatial4j:jar:0.6:compile >
Re: Module retirement
I'd prefer (2). It's clean and it _uses_ VC instead of working around it. My only concern is that we should do it before people have a chance to fork, because they'll want to do that as late as possible. But we can ameliorate that by just making a couple of loud announcements first. We might want also to make a point of pointing at replacements, even if they seem obvious to us. ajs6f > On Nov 29, 2018, at 11:45 AM, Andy Seaborne wrote: > > Let's retire some modules: > > jena-spatial [+] > jena-fuseki1 > jena-csv > > by not including them in the next release; they should all work but there > isn't a way to signal "deprecation" other than by talking about it (which > we've done) and doing it. > > There are several ways to go about this. > > 1/ have an area "archived/" with the modules moved there. > This leaves them in the source-release and browsable in git. > > 2/ Delete from git. Maybe leave a file somewhere to record the commit ids. > > 3/ A new separate git-repo for "jena-misc" > https://git-wip-us.apache.org/repos/asf/jena-misc.asf > (or use gitbox and put it on github mirroed back to ASF.) > > and maybe some others. > > I think (1) is not definite enough. > > Thoughts/suggestions/... > >Andy > > [+] > jena-spatial :: this is in jena-fuseki-webapp > [INFO] +- org.apache.jena:jena-spatial:jar:3.10.0-SNAPSHOT:compile > [INFO] | +- org.apache.lucene:lucene-spatial:jar:7.4.0:compile > [INFO] | +- org.apache.lucene:lucene-spatial-extras:jar:7.4.0:compile > [INFO] | | +- org.apache.lucene:lucene-spatial3d:jar:7.4.0:compile > [INFO] | | \- io.sgr:s2-geometry-library-java:jar:1.0.0:compile > [INFO] | \- org.locationtech.spatial4j:spatial4j:jar:0.6:compile
[GitHub] jena issue #498: JENA-1639: Model.getList and Statement.getList
Github user ajs6f commented on the issue: https://github.com/apache/jena/pull/498 Ah, I _always_ get `ModelCon` and `ModelCom` (impl) confused. Cool! ---
[GitHub] jena issue #498: JENA-1639: Model.getList and Statement.getList
Github user ajs6f commented on the issue: https://github.com/apache/jena/pull/498 I'm probably confused, but where is `Model::getList` being added? I just see a change to `createList` and `getList` is only added to `ModelCon`. ---
[GitHub] jena issue #488: Merged Lucene upgrade. This resolves JENA-1621
Github user ajs6f commented on the issue: https://github.com/apache/jena/pull/488 I've seen that happen when I've forgotten to rebase over master before merging, but I don't know if that's what's happening here... ---
Re: CMS diff: TDB Command-line Utilities
Thanks Aaron! Committed with https://svn.apache.org/viewvc?view=revision=1844256 ajs6f > On Oct 18, 2018, at 3:31 PM, Aaron Kesler wrote: > > Clone URL (Committers only): > https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/documentation%2Ftdb%2Fcommands.mdtext > > Aaron Kesler > > Index: trunk/content/documentation/tdb/commands.mdtext > === > --- trunk/content/documentation/tdb/commands.mdtext (revision 1844191) > +++ trunk/content/documentation/tdb/commands.mdtext (working copy) > @@ -113,6 +113,8 @@ > > ### `tdbloader` > > +> tdbloader --loc /path/for/database input.trig > + > Bulk loader and index builder. Performs bulk load operations more > efficiently than simply reading RDF into a TDB-back model. > >
Re: Can't build tdb2
Just for a data point, I just ran a full `mvn clean install` from current master in 512MB heap. Of course, TDB1 (and I assume 2 as well) can use significant amounts of off-heap memory. ajs6f > On Oct 14, 2018, at 10:02 AM, Claude Warren wrote: > > I did have Eclipse running but shut it down and executed "mvn clean install > -Pdev" but get the problems mentioned above. > > Is there a minimal memory required for compilation? This is an old system > so perhaps I am hitting that. > > On Sun, Oct 14, 2018 at 1:48 PM Andy Seaborne wrote: > >> On 14/10/18 10:13, Claude Warren wrote: >>> OK. I have maven produce a classpath file for me so I know what >>> classpath it is using. >> >> How are you running tests and your IDE? >> I use the mavenr nature of projects, not the old command line "generate >> .classpath" etc. >> >> For a new version, in Eclipse you must do Alt-F5 (Maven update) for >> everything; it is also good to do maven and also it is cleaner to do a >> maven build locally beforehand. This puls down the non-java POMS which >> get out of step is the parent is not open in Eclipse. >> >> No producing .classpaths etc m2e does it automatically. >> >> On 14/10/18 10:13, Claude Warren wrote: >>> So does the TDB2 system somehow build a new classpath? >> >> No. >> >>> Does the test system create a new classpath? >> >> No. >> >>> Is there some way the original classpath >>> could have been modified before the test was called? >> >> I don't see how it could. >> >> "mvn clean install -Pdev" works for me locally. >> >> Andy >> >> >> >> >> On 14/10/18 10:13, Claude Warren wrote: >>> OK. I have maven produce a classpath file for me so I know what >> classpath >>> it is using. >>> I created a shell script to execute a single junit test outside of maven. >>> Using org.junit.runner.JUnitCore I am executing >>> org.apache.jena.tdb2.assembler.TestTDBAssembler >>> >>> I get: >>> .E.E.E.E.E.E.org.apache.jena.dboe.base.file.AlreadyLocked: Failed to get >> a >>> lock: >>> >> file='/home/claude/apache/jena/jena-db/jena-tdb2/target/tdb-testing/DB/tdb.lock': >>> Lock already heldat >>> >> org.apache.jena.dboe.base.file.ProcessFileLock.lockOperation(ProcessFileLock.java:187) >>> at >>> >> org.apache.jena.dboe.base.file.ProcessFileLock.lockEx(ProcessFileLock.java:125) >>> at >>> >> org.apache.jena.tdb2.sys.DatabaseConnection.buildForCache(DatabaseConnection.java:88) >>> at >>> >> org.apache.jena.tdb2.sys.DatabaseConnection.lambda$0(DatabaseConnection.java:76) >>> at >>> >> java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660) >>> at >>> >> org.apache.jena.tdb2.sys.DatabaseConnection.make(DatabaseConnection.java:76) >>> at >>> >> org.apache.jena.tdb2.sys.DatabaseConnection.connectCreate(DatabaseConnection.java:61) >>> at >>> >> org.apache.jena.tdb2.sys.DatabaseConnection.connectCreate(DatabaseConnection.java:52) >>> at >>> org.apache.jena.tdb2.DatabaseMgr.DB_ConnectCreate(DatabaseMgr.java:39) >>> >>> >>> The tdb.lock file does not exists before or after the run so it does get >>> cleaned up. >>> >>> At the bottom of the above exception the output goes on with: >>> >>> E >>> Time: 1.254 >>> There were 7 failures: >>> 1) createDatasetDirect(org.apache.jena.tdb2.assembler.TestTDBAssembler) >>> java.lang.NoClassDefFoundError: >>> org/apache/jena/dboe/trans/bplustree/BPlusTreeFactory >>> at >>> org.apache.jena.tdb2.setup.TDBBuilder.buildRangeIndex(TDBBuilder.java:89) >>> at >>> >> org.apache.jena.tdb2.setup.TDBBuilder.buildBaseNodeTable(TDBBuilder.java:97) >>> at >>> >> org.apache.jena.tdb2.setup.AbstractTDBBuilder.buildNodeTable(AbstractTDBBuilder.java:219) >>> at >>> >> org.apache.jena.tdb2.setup.AbstractTDBBuilder.build$(AbstractTDBBuilder.java:94) >>> at org.apache.jena.tdb2.setup.TDBBuilder.build(TDBBuilder.java:65) >>> at >>> org.apache.jena.tdb2.sys.StoreConnection.make(StoreConnection.java:93) >>> at >>> >> org.apache.jena.tdb2.sys.StoreConnection.connectCreate(StoreConnection.java:61) >&
Re: I know I have asked this before ....
Well, what I like to do is make sure my local master branch is up-to-date (pull early, pull often!) then git rebase my feature branch over that up-to-date master (any conflict or confusion will show up at this point) and then go back to master and git merge my-branch. Then I can just git push master to Apache. Does that makes sense? It looks something like: [working in my branch] git checkout master git pull git checkout my-branch git rebase master [fix any conflicts] git checkout master git merge my-branch Now I usually do a complete mvn clean install, just to make sure, then git push apache master where for my setup, the remote name "apache" is the main repo at Apache that you give the URL for below. ajs6f > On Oct 12, 2018, at 5:27 PM, Claude Warren wrote: > > OK. I figured out it is https://git-wip-us.apache.org/repos/asf/jena.git > > but now I just need a refresher on our process. > > On Fri, Oct 12, 2018 at 10:10 PM Claude Warren wrote: > >> ... but I'm getting old. >> >> Where is the documentation for how to merge into the apache master git >> repository? Do just push merge the master locally and push back to >> g...@github.com:apache/jena.git? >> >> and then close the merge request by hand? Or can I add closes !(merge >> number) in the comments? >> >> sucks getting old, but beats the alternative. ;) >> >> -- >> I like: Like Like - The likeliest place on the web >> <http://like-like.xenei.com> >> LinkedIn: http://www.linkedin.com/in/claudewarren >> > > > -- > I like: Like Like - The likeliest place on the web > <http://like-like.xenei.com> > LinkedIn: http://www.linkedin.com/in/claudewarren
[GitHub] jena issue #474: JENA-1609 Jena master does not build under JDK10
Github user ajs6f commented on the issue: https://github.com/apache/jena/pull/474 @rvesse Yup, that's my site and every other one I know. That's not to say that this PR isn't worthwhile, just that I would certainly like to spend as much time as possible on 11, not 10. ---
[GitHub] jena pull request #474: JENA-1609 Jena master does not build under JDK10
Github user ajs6f commented on a diff in the pull request: https://github.com/apache/jena/pull/474#discussion_r221745287 --- Diff: jena-jdbc/jena-jdbc-core/pom.xml --- @@ -39,17 +39,28 @@ 3.10.0-SNAPSHOT - - - org.slf4j - slf4j-log4j12 - + + + org.slf4j + slf4j-log4j12 + + + + log4j + log4j + + + --- End diff -- Yup. We may have to do something like this, but it's definitely "papering-over" the underlying fault. ---
[GitHub] jena pull request #474: JENA-1609 Jena master does not build under JDK10
Github user ajs6f commented on a diff in the pull request: https://github.com/apache/jena/pull/474#discussion_r221716224 --- Diff: jena-jdbc/jena-jdbc-core/pom.xml --- @@ -39,17 +39,28 @@ 3.10.0-SNAPSHOT - - - org.slf4j - slf4j-log4j12 - + + + org.slf4j + slf4j-log4j12 + + + + log4j + log4j + + + --- End diff -- Why are you pulling in the `log4j` API? ---
[GitHub] jena pull request #474: JENA-1609 Jena master does not build under JDK10
Github user ajs6f commented on a diff in the pull request: https://github.com/apache/jena/pull/474#discussion_r221715600 --- Diff: jena-arq/pom.xml --- @@ -216,6 +216,7 @@ Licenced under the Apache License, Version 2.0 + -html5 --- End diff -- Is this in some way needed for Java 10 builds? ---
[GitHub] jena pull request #474: JENA-1609 Jena master does not build under JDK10
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/474#discussion_r221716057
--- Diff:
jena-elephas/jena-elephas-mapreduce/src/main/java/org/apache/jena/hadoop/rdf/mapreduce/filter/AbstractNodeTupleFilterMapper.java
---
@@ -28,9 +28,7 @@
/**
* Abstract mapper implementation which helps in filtering tuples from the
* input, derived implementations provide an implementation of the
- * {@link #accepts(TKey, T)}
- *
- *
+ * {@link #accepts(Object, AbstractNodeTupleWritable)}
--- End diff --
This just looks wrong-- the method below clearly is `accepts(TKey key, T
tuple)`, and the concrete class isn't there at all.
---
[GitHub] jena pull request #474: JENA-1609 Jena master does not build under JDK10
Github user ajs6f commented on a diff in the pull request: https://github.com/apache/jena/pull/474#discussion_r221715434 --- Diff: .gitignore --- @@ -14,7 +14,10 @@ buildNumber.properties .project .settings .recommenders -.metadata +.metadat --- End diff -- Is this correct? `.metadata` => `.metadat`? ---
Re: [VOTE] Apache Jena 3.9.0 RC1
> On 29/09/18 10:22, Andy Seaborne wrote: > >> Please vote to approve this release: +1 Approve the release Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T14:49:05-05:00) Java version: 1.8.0_65, vendor: Oracle Corporation OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac" > + does everything work on OS X? > + are the GPG signatures fine? > + are the checksums correct? > + is there a source archive? > + can the source archive really be built? > (NB This requires a "mvn install" first time) Yup. I haven't checked the binary distributions. ajs6f > On Sep 29, 2018, at 6:20 AM, Andy Seaborne wrote: > > +1 > > including using the staging maven repo in RDF Delta. > > On 29/09/18 10:22, Andy Seaborne wrote: > >> Please vote to approve this release: >>[ ] +1 Approve the release >>[ ] 0 Don't care >>[ ] -1 Don't release, because ... >> This vote will be open to at least >>Wednesday, 2018-10-03, 08:00 UTC.
Re: Towards Jena 3.9.0
+1 ajs6f > On Sep 27, 2018, at 6:14 AM, Andy Seaborne wrote: > > I'm going to start the 3.9.0 release process. > >Andy
[GitHub] jena pull request #471: JENA-1605: use transactions in spatialindexer
GitHub user ajs6f opened a pull request: https://github.com/apache/jena/pull/471 JENA-1605: use transactions in spatialindexer You can merge this pull request into a Git repository by running: $ git pull https://github.com/ajs6f/jena JENA-1605 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/jena/pull/471.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #471 commit 4816dcecd2992a8236ebbebb30ad2a1796aab92c Author: ajs6f Date: 2018-09-18T15:43:51Z JENA-1605: use transactions in spatialindexer ---
[GitHub] jena issue #470: Rename README to README.md
Github user ajs6f commented on the issue: https://github.com/apache/jena/pull/470 That does look more pleasant! I'll wait a few days in case there's some reason this is a bad idea that I'm not seeing, and then I'll merge. Thanks for the contribution @nirajpatel ! ---
[GitHub] jena issue #470: Rename README to README.md
Github user ajs6f commented on the issue: https://github.com/apache/jena/pull/470 I'm not sure that our `README` actually _is_ Markdown. Is there a reason you would particularly like to see this file ending? Perhaps some further integration? ---
[GitHub] jena issue #469: JENA-1604: transform HTTP requests
Github user ajs6f commented on the issue: https://github.com/apache/jena/pull/469 Great, thanks @nirajpatel! I'll wait a couple of days in case anyone has comments, or if another committer approves I'll go ahead and merge. This is a pretty low-impact changeset. ---
[GitHub] jena pull request #469: JENA-1604: transform HTTP requests
GitHub user ajs6f opened a pull request: https://github.com/apache/jena/pull/469 JENA-1604: transform HTTP requests You can merge this pull request into a Git repository by running: $ git pull https://github.com/ajs6f/jena JENA-1604 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/jena/pull/469.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #469 commit 18a23ca279b3025d4ec12c2977d634c9b86b00f6 Author: ajs6f Date: 2018-09-14T18:25:25Z JENA-1604: transform HTTP requests ---
Re: My Java program using Jena working fine in eclipse but throws an exception when I run jar file from tomcat
This list does not accept attachments. Please put your code and data somewhere
web-accessible like pastebin or gist.
ajs6f
> On Aug 23, 2018, at 9:32 AM, Minakshi Bhardwaj wrote:
>
> I have written a java program to get some queries from an ontology. Its
> working fine in eclipse where I developed it, however, when I run it using
> jar file stored in tomcat an exception is thrown which is give below
> Warning: Unchecked exception detected:
> [[o:Response$UndeclaredThrowableErrorMarker]:"FATAL: Undeclared
> java.lang.RuntimeException detected. java.lang.Exception: Invoke failed:
> [[c:test]]->drawmap((o:String)[o:String]). Cause:
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 VM:
> 1.8.0_181@http://java.oracle.com/; at: #-14
> java.util.ArrayList.rangeCheck(Unknown Source) #-13
> java.util.ArrayList.get(Unknown Source) #-12
> cononto.test.traverse(test.java:64) #-11 cononto.test.drawmap(test.java:976)
> #-10 sun.re[...]ppedResult(true) #3
> http://localhost:8080/JavaBridge/java/Java.inc(588): java_Client->getResult()
> #4 http://localhost:8080/JavaBridge/java/Java.inc(1795):
> java_Client->invokeMethod(1, 'drawmap', Array) #5
> http://localhost:8080/JavaBridge/java/Java.inc(1894):
> java_JavaProxy->__call('drawmap', Array) #6
> http://localhost:8080/JavaBridge/java/Java.inc(2042):
> java_AbstractJava->__call('drawmap', Array) #7 C:\xampp\htdocs\javab.php(6):
> Java->__call('drawmap', Array) #8 {main}] in
> http://localhost:8080/JavaBridge/java/Java.inc on line 230
> [[o:Response$UndeclaredThrowableErrorMarker]:"FATAL: Undeclared
> java.lang.RuntimeException detected. java.lang.Exception: Invoke failed:
> [[c:test]]->drawmap((o:String)[o:String]). Cause:
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 VM:
> 1.8.0_181@http://java.oracle.com/; at: #-14
> java.util.ArrayList.rangeCheck(Unknown Source) #-13
> java.util.ArrayList.get(Unknown Source) #-12
> cononto.test.traverse(test.java:64) #-11 cononto.test.drawmap(test.java:976)
> #-10 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) #-9
> sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) #-8
> sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) #-7
> java.lang.reflect.Method.invoke(Unknown Source) #-6
> php.java.bridge.JavaBridge.Invoke(JavaBridge.java:1068) #-5
> php.java.bridge.parser.Request.handleRequest(Request.java:426) #-4
> php.java.bridge.parser.Request.handleRequests(Request.java:509) #-3
> php.java.bridge.http.ContextRunner.run(ContextRunner.java:143) #-2
> php.java.bridge.util.ThreadPool$Delegate.run(ThreadPool.java:60) #-1
> php.java.bridge.util.AppThreadPool$Delegate.run(AppThreadPool.java:58) #0
> http://localhost:8080/JavaBridge/java/Java.inc(260):
> java_ThrowExceptionProxyFactory->getProxy(2, 'cononto.test', 'F', true) #1
> http://localhost:8080/JavaBridge/java/Java.inc(388):
> java_Arg->getResult(true) #2
> http://localhost:8080/JavaBridge/java/Java.inc(394):
> java_Client->getWrappedResult(true) #3
> http://localhost:8080/JavaBridge/java/Java.inc(588): java_Client->getResult()
> #4 http://localhost:8080/JavaBridge/java/Java.inc(1795):
> java_Client->invokeMethod(1, 'drawmap', Array) #5
> http://localhost:8080/JavaBridge/java/Java.inc(1894):
> java_JavaProxy->__call('drawmap', Array) #6
> http://localhost:8080/JavaBridge/java/Java.inc(2042):
> java_AbstractJava->__call('drawmap', Array) #7 C:\xampp\htdocs\javab.php(6):
> Java->__call('drawmap', Array) #8 {main}]
> Fatal error: An unchecked exception occured during script execution. Please
> check the server log files for details. in
> http://localhost:8080/JavaBridge/java/Java.inc on line 807
>
> I am attaching my java code and a sample ontology.
>
> Please help.
[GitHub] jena pull request #458: JENA-1481, JENA-1586: Delete databases and expel fro...
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/458#discussion_r209314854
--- Diff: jena-base/src/main/java/org/apache/jena/atlas/io/IO.java ---
@@ -364,4 +369,31 @@ public static String uniqueFilename(String directory,
String base, String ext) {
return null ;
}
}
+
+/** Delete everything from a {@code Path} start point, including the
path itself.
+ * This function works on files or directories.
+ * This function does not follow symbolic links.
+ */
+public static void deleteAll(Path start) {
+// Walks down the tree and deletes directories on the way backup.
+try {
+Files.walkFileTree(start, new SimpleFileVisitor() {
--- End diff --
I'm not worried about it. I'm always a bit suspicious on anon inner classes
because of the occasional GC problems, but I think I'm letting my suspicions
run away from me.
---
