[jira] [Commented] (JENA-1842) Replace System.*.print* with Log.*

[Jan Martin Keil (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040744#comment-17040744
 ] 

Jan Martin Keil commented on JENA-1842:
---

I took a brief look on 
[https://github.com/apache/jena/search?q=System.err.println|https://github.com/apache/jena/search?q=System.err.println],
 and some of the results looked like further cases. But I did not check that in 
detail.

> Replace System.*.print* with Log.*
> --
>
> Key: JENA-1842
> URL: https://issues.apache.org/jira/browse/JENA-1842
> Project: Apache Jena
>  Issue Type: Improvement
>Affects Versions: Jena 3.14.0
>Reporter: Jan Martin Keil
>Priority: Major
>
> Apache Jena uses {{Sytem.err.print*}} (e.g. {{ParserSPARQL11#perform}}) 
> outside of testcases, cmd tools, and examples. This makes it hard to control 
> the output of software using the Jena libraries. I recommend to consistently 
> replace them with appropriated {{Log.info}}, {{Log.warn}}, or {{Log.error}} 
> calls.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] Moving Jena site from Apache CMS/SVN to Git

[Andy Seaborne]

On 19/02/2020 19:06, Andy Seaborne wrote:

I am finding some conversion issues around boxes and 

https://jena.apache.org/tutorials/rdf_api.html#ch-Statements
vs
http://jena.roylenferink.nl/tutorials/rdf_api.html#ch-Statements

The example is doubly boxed and the fint size keeps jumping.

Yes, the Jena site markup is a bit yuk - it is a conversion itself - but 
we have the content we have.


I've cleared up some problems - on staging now.



There are changes around whitespace and tables. sometimes better, 
sometimes not. And I have seen an odd "Title" change where ":" becomes "-"


     Andy

On 15/02/2020 13:28, Roy Lenferink wrote:

Hi Jena community,

I noticed Jena is still serving its site from SVN with help of the 
Apache CMS. At the Apache Celix
project we decided to move away from the CMS and move towards git for 
serving our website [1].
This because the CMS was introduced in 2010 and is currently not 
accepting any new projects. With
the move to Hugo we're sure that we still can update the site when the 
ASF CMS will be

decommissioned.

The master branch contains the actual website sources whereas the 
generated website is served
from the asf-site branch. Hugo is being used as static website 
generator. Content is written in

Markdown.

I had a look at Jena its site and it was quite easy to migrate Jena 
its site to use Hugo as well. An
example of Hugo its output is (for demo purposes only) available on 
[2]. These are the existing

markdown files with a slightly changed header.

Moving to git can enlarge the visibility of how projects are 
functioning. Next to that, new contributors
can simply create a pull request against the website repository if 
they find anything they want to
improve. I've updated the 'Improve this page' to 'Edit this page' 
which will open the GitHub webpage
to edit the currently viewed page (currently returning a 404 because 
the apache/jena-site repository

does not exist).

If the community is interested in this move what I propose:
- Someone from the PMC to request a new git repository for the website 
(e.g. jena-site) via [4]
- Me creating the pull request from the repository I am temporarily 
using for the website contents [5]

to the official jena-site repository
- Create a Jenkins job to automatically build the site after changes 
happen on the master branch.
- When the pull request is reviewed and merged ask INFRA to move over 
from the current svnpubsub

to the gitpubsub approach and remove Jena from the Apache CMS.

Next to that Jena is also providing javadocs on its site. My proposal 
for this is to serve them from a
separate branch (e.g. release-docs). This way people who only want to 
clone the site can clone the
the master branch using --single-branch and will not be bothered with 
cloning all the javadocs.


All the URLs are still the same so the SEO score is not influenced in 
any way.


I'd like to hear everyone's opinion on this :)

Best regards,
Roy

[1] https://github.com/apache/celix-site
[2] http://jena.roylenferink.nl/
[3] http://celix.apache.org/contributing/releasing.html
[4] https://gitbox.apache.org/setup/newrepo.html
[5] https://github.com/rlenferink/jena-site

Re: mvn build Apache Jena 3.15.0-SNAPSHOT

[Marco Neumann]

thanks Andy, I am sure these flags will come in handy

the PR goes into jira?

On Wed 19. Feb 2020 at 19:17, Andy Seaborne  wrote:

> The version of ES isn't compatible with Java13+
>
> Use mvn -pl '!jena-text-es' install
>
> or better yet, a PR for jena-text-es to skip building when java is 13+.
>
>  Andy
>
> On 19/02/2020 18:56, Marco Neumann wrote:
> >
> >
> >
> > On Wed, Feb 19, 2020 at 4:49 PM Andy Seaborne  > > wrote:
> >
> >
> >
> > On 19/02/2020 14:04, Marco Neumann wrote:
> >  > On Wed, Feb 19, 2020 at 10:27 AM Andy Seaborne  > > wrote:
> >  >
> >  >> https://builds.apache.org/view/H-L/view/Jena/
> >  >>
> >  >> On 17/02/2020 15:32, Marco Neumann wrote:
> >  >>> FYI
> >  >>>
> >  >>> current Apache Jena 3.15.0-SNAPSHOT mvn build fails with
> > OpenJDK 13.02 on
> >  >>> SPARQL Text Search - Elasticsearch
> >  >>
> >  >> In what way?
> >
> > Marco - in what way does it fail?
> >
> >
> > Andy, something along those lines:
> > Caused by: java.security.AccessControlException: access denied
> > ("java.lang.RuntimePermission"
> > "accessClassInPackage.jdk.internal.vm.annotation")
> >
> > in the Apache Jena - SPARQL Text Search - Elasticsearch module
> >
> > for details see attached debug.log  openjdk version "13.0.2"
> > 2020-01-14 linux (64-Bit Server VM)
> >
> > It's not a big deal for our current setup to change the jdk but it might
> > interfere with some build pipelines
> >
> >
> >  >> Do you have fix?
> >  >>
> >  >
> >  > the fix for now is to use jdk_12.01 for the build and tests with
> > 'clean
> >  > install'
> >  >
> >  > BUILD SUCCESS
> >  > Total time:  06:51 min
> >  >
> >  > I have a similar issue and jdks with the ElasticSearch build over
> > at RDF4j.
> >  > looks like it's jdk_13.02 related
> >  >
> >  >
> >  >>
> >  >> BTW ElasticSearch test plugin has a timing issue - the
> > background server
> >  >> does not always close down promptly. The error does not cause
> > maven to
> >  >> stop usually.
> >  >>
> >  >>>
> >  >>> builds successful with OpenJDK 12.0.1 but need to manually skip
> > java doc.
> >  >>> Doesn't skip on GeoSPARQL Engine doc automatically.
> >  >>
> >  >> With -Pdev?
> >  >>
> >  >
> >  > see above. fixed for now
> >  >
> >  >
> >  >>
> >  >>> Apache Maven 3.6.3
> >  >>> OS name: "linux"
> >  >>> Total time:  04:23 min
> >  >>>
> >  >>
> >  >
> >  >
> >
> >
> >
> > --
> >
> >
> > ---
> > Marco Neumann
> > KONA
> >
>
-- 


---
Marco Neumann
KONA

Re: mvn build Apache Jena 3.15.0-SNAPSHOT

[Marco Neumann]

yes, that sounds reasonable. good to be aware of the status here though

On Wed 19. Feb 2020 at 19:09, Rob Vesse  wrote:

> So that stack trace implies that ElasticSearch is violating some of the
> constraints imposed by newer JVMs which are all part of JPMS (Java Platform
> Module System) which is ultimately about making code more easily portable
> and trying to stop people doing “naughty” stuff with JVM internals that
> they shouldn’t
>
>
>
> The upshot of which is that this should be addressed by the ElasticSearch
> community
>
>
>
> It is possible that they already have addressed this and the Jena
> community needs to upgrade to a newer ElasticSearch, in which case
> contributions welcome
>
>
>
> Rob
>
>
>
> From: Marco Neumann 
> Reply to: 
> Date: Wednesday, 19 February 2020 at 18:57
> To: 
> Subject: Re: mvn build Apache Jena 3.15.0-SNAPSHOT
>
>
>
>
>
>
>
>
>
> On Wed, Feb 19, 2020 at 4:49 PM Andy Seaborne  wrote:
>
>
>
> On 19/02/2020 14:04, Marco Neumann wrote:
> > On Wed, Feb 19, 2020 at 10:27 AM Andy Seaborne  wrote:
> >
> >> https://builds.apache.org/view/H-L/view/Jena/
> >>
> >> On 17/02/2020 15:32, Marco Neumann wrote:
> >>> FYI
> >>>
> >>> current Apache Jena 3.15.0-SNAPSHOT mvn build fails with OpenJDK 13.02
> on
> >>> SPARQL Text Search - Elasticsearch
> >>
> >> In what way?
>
> Marco - in what way does it fail?
>
>
>
> Andy, something along those lines:
>
> Caused by: java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission"
> "accessClassInPackage.jdk.internal.vm.annotation")
>
>
>
> in the Apache Jena - SPARQL Text Search - Elasticsearch module
>
>
>
> for details see attached debug.log  openjdk version "13.0.2" 2020-01-14
> linux (64-Bit Server VM)
>
>
>
> It's not a big deal for our current setup to change the jdk but it might
> interfere with some build pipelines
>
>
>
>
>
>
> >> Do you have fix?
> >>
> >
> > the fix for now is to use jdk_12.01 for the build and tests with 'clean
> > install'
> >
> > BUILD SUCCESS
> > Total time:  06:51 min
> >
> > I have a similar issue and jdks with the ElasticSearch build over at
> RDF4j.
> > looks like it's jdk_13.02 related
> >
> >
> >>
> >> BTW ElasticSearch test plugin has a timing issue - the background server
> >> does not always close down promptly. The error does not cause maven to
> >> stop usually.
> >>
> >>>
> >>> builds successful with OpenJDK 12.0.1 but need to manually skip java
> doc.
> >>> Doesn't skip on GeoSPARQL Engine doc automatically.
> >>
> >> With -Pdev?
> >>
> >
> > see above. fixed for now
> >
> >
> >>
> >>> Apache Maven 3.6.3
> >>> OS name: "linux"
> >>> Total time:  04:23 min
> >>>
> >>
> >
> >
>
>
>
>
> --
>
>
>
> ---
> Marco Neumann
> KONA
>
> --


---
Marco Neumann
KONA

Re: [VOTE][LAZY] Move from CMS/SVN to Hugo/Git

[Bruno P. Kinoshita]

 +1 for moving to Git, no strong opinion on which site generator to use, 
Jekyll, Hugo, etc. But being able to get pull requests for the docs could 
increase the contributions IMO

Thanks
Bruno

On Thursday, 20 February 2020, 2:41:16 am NZDT, 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

  

[jira] [Commented] (JENA-1842) Replace System.*.print* with Log.*

[Andy Seaborne (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040364#comment-17040364
 ] 

Andy Seaborne commented on JENA-1842:
-

{{Log.}} is supposed to be used.

The one in {{ParserSPARQL11#perform}} looks like a stray development. 

[~jmkeil] - what other case have you found?

> Replace System.*.print* with Log.*
> --
>
> Key: JENA-1842
> URL: https://issues.apache.org/jira/browse/JENA-1842
> Project: Apache Jena
>  Issue Type: Improvement
>Affects Versions: Jena 3.14.0
>Reporter: Jan Martin Keil
>Priority: Major
>
> Apache Jena uses {{Sytem.err.print*}} (e.g. {{ParserSPARQL11#perform}}) 
> outside of testcases, cmd tools, and examples. This makes it hard to control 
> the output of software using the Jena libraries. I recommend to consistently 
> replace them with appropriated {{Log.info}}, {{Log.warn}}, or {{Log.error}} 
> calls.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: mvn build Apache Jena 3.15.0-SNAPSHOT

[Andy Seaborne]

The version of ES isn't compatible with Java13+

Use mvn -pl '!jena-text-es' install

or better yet, a PR for jena-text-es to skip building when java is 13+.

Andy

On 19/02/2020 18:56, Marco Neumann wrote:




On Wed, Feb 19, 2020 at 4:49 PM Andy Seaborne > wrote:




On 19/02/2020 14:04, Marco Neumann wrote:
 > On Wed, Feb 19, 2020 at 10:27 AM Andy Seaborne mailto:a...@apache.org>> wrote:
 >
 >> https://builds.apache.org/view/H-L/view/Jena/
 >>
 >> On 17/02/2020 15:32, Marco Neumann wrote:
 >>> FYI
 >>>
 >>> current Apache Jena 3.15.0-SNAPSHOT mvn build fails with
OpenJDK 13.02 on
 >>> SPARQL Text Search - Elasticsearch
 >>
 >> In what way?

Marco - in what way does it fail?


Andy, something along those lines:
Caused by: java.security.AccessControlException: access denied 
("java.lang.RuntimePermission" 
"accessClassInPackage.jdk.internal.vm.annotation")


in the Apache Jena - SPARQL Text Search - Elasticsearch module

for details see attached debug.log  openjdk version "13.0.2" 
2020-01-14 linux (64-Bit Server VM)


It's not a big deal for our current setup to change the jdk but it might 
interfere with some build pipelines



 >> Do you have fix?
 >>
 >
 > the fix for now is to use jdk_12.01 for the build and tests with
'clean
 > install'
 >
 > BUILD SUCCESS
 > Total time:  06:51 min
 >
 > I have a similar issue and jdks with the ElasticSearch build over
at RDF4j.
 > looks like it's jdk_13.02 related
 >
 >
 >>
 >> BTW ElasticSearch test plugin has a timing issue - the
background server
 >> does not always close down promptly. The error does not cause
maven to
 >> stop usually.
 >>
 >>>
 >>> builds successful with OpenJDK 12.0.1 but need to manually skip
java doc.
 >>> Doesn't skip on GeoSPARQL Engine doc automatically.
 >>
 >> With -Pdev?
 >>
 >
 > see above. fixed for now
 >
 >
 >>
 >>> Apache Maven 3.6.3
 >>> OS name: "linux"
 >>> Total time:  04:23 min
 >>>
 >>
 >
 >



--


---
Marco Neumann
KONA

[jira] [Commented] (JENA-1005) Move off Log4j v1.

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040348#comment-17040348
 ] 

ASF subversion and git services commented on JENA-1005:
---

Commit 2e136071fc278debd461888bbeaf716f0b0bda18 in jena's branch 
refs/heads/master from Andy Seaborne
[ https://gitbox.apache.org/repos/asf?p=jena.git;h=2e13607 ]

JENA-1005: Isolate log4j1 usage in tests.

Put in log4j2 dependency settings
Update slj4j to 1.7.30
Put log4j2 operations into LogCtl


> Move off Log4j v1.
> --
>
> Key: JENA-1005
> URL: https://issues.apache.org/jira/browse/JENA-1005
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Log4J v1 is approaching end-of-life.  Jena uses slf4j for logging from code.
> Jena depends on log4j for controlling output in tests and for the output in 
> commands. This is in the log4j explicit control utilities.
> Choices include:
> * Log4jv2 log4j v2 does not support log4j.properties.
> * Use java.util.logging (JUL) in some or all of those places.
> Others?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JENA-1005) Move off Log4j v1.

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040349#comment-17040349
 ] 

ASF subversion and git services commented on JENA-1005:
---

Commit 9cc1b65d7a765004f13bd18f413b58e3387afd78 in jena's branch 
refs/heads/master from Andy Seaborne
[ https://gitbox.apache.org/repos/asf?p=jena.git;h=9cc1b65 ]

Merge pull request #690 from afs/test-logging

JENA-1005: Isolate log4j1 usage in tests.

> Move off Log4j v1.
> --
>
> Key: JENA-1005
> URL: https://issues.apache.org/jira/browse/JENA-1005
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Log4J v1 is approaching end-of-life.  Jena uses slf4j for logging from code.
> Jena depends on log4j for controlling output in tests and for the output in 
> commands. This is in the log4j explicit control utilities.
> Choices include:
> * Log4jv2 log4j v2 does not support log4j.properties.
> * Use java.util.logging (JUL) in some or all of those places.
> Others?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: mvn build Apache Jena 3.15.0-SNAPSHOT

[Rob Vesse]

So that stack trace implies that ElasticSearch is violating some of the 
constraints imposed by newer JVMs which are all part of JPMS (Java Platform 
Module System) which is ultimately about making code more easily portable and 
trying to stop people doing “naughty” stuff with JVM internals that they 
shouldn’t

 

The upshot of which is that this should be addressed by the ElasticSearch 
community

 

It is possible that they already have addressed this and the Jena community 
needs to upgrade to a newer ElasticSearch, in which case contributions welcome

 

Rob

 

From: Marco Neumann 
Reply to: 
Date: Wednesday, 19 February 2020 at 18:57
To: 
Subject: Re: mvn build Apache Jena 3.15.0-SNAPSHOT

 

 

 

 

On Wed, Feb 19, 2020 at 4:49 PM Andy Seaborne  wrote:



On 19/02/2020 14:04, Marco Neumann wrote:
> On Wed, Feb 19, 2020 at 10:27 AM Andy Seaborne  wrote:
> 
>> https://builds.apache.org/view/H-L/view/Jena/
>>
>> On 17/02/2020 15:32, Marco Neumann wrote:
>>> FYI
>>>
>>> current Apache Jena 3.15.0-SNAPSHOT mvn build fails with OpenJDK 13.02 on
>>> SPARQL Text Search - Elasticsearch
>>
>> In what way?

Marco - in what way does it fail?

 

Andy, something along those lines:

Caused by: java.security.AccessControlException: access denied 
("java.lang.RuntimePermission" 
"accessClassInPackage.jdk.internal.vm.annotation")

 

in the Apache Jena - SPARQL Text Search - Elasticsearch module

 

for details see attached debug.log  openjdk version "13.0.2" 2020-01-14 linux 
(64-Bit Server VM)

 

It's not a big deal for our current setup to change the jdk but it might 
interfere with some build pipelines

 

 


>> Do you have fix?
>>
> 
> the fix for now is to use jdk_12.01 for the build and tests with 'clean
> install'
> 
> BUILD SUCCESS
> Total time:  06:51 min
> 
> I have a similar issue and jdks with the ElasticSearch build over at RDF4j.
> looks like it's jdk_13.02 related
> 
> 
>>
>> BTW ElasticSearch test plugin has a timing issue - the background server
>> does not always close down promptly. The error does not cause maven to
>> stop usually.
>>
>>>
>>> builds successful with OpenJDK 12.0.1 but need to manually skip java doc.
>>> Doesn't skip on GeoSPARQL Engine doc automatically.
>>
>> With -Pdev?
>>
> 
> see above. fixed for now
> 
> 
>>
>>> Apache Maven 3.6.3
>>> OS name: "linux"
>>> Total time:  04:23 min
>>>
>>
> 
> 


 

-- 



---
Marco Neumann
KONA

Re: [DISCUSS] Moving Jena site from Apache CMS/SVN to Git

[Andy Seaborne]

I am finding some conversion issues around boxes and 

https://jena.apache.org/tutorials/rdf_api.html#ch-Statements
vs
http://jena.roylenferink.nl/tutorials/rdf_api.html#ch-Statements

The example is doubly boxed and the fint size keeps jumping.

Yes, the Jena site markup is a bit yuk - it is a conversion itself - but 
we have the content we have.


There are changes around whitespace and tables. sometimes better, 
sometimes not. And I have seen an odd "Title" change where ":" becomes "-"


Andy

On 15/02/2020 13:28, Roy Lenferink wrote:

Hi Jena community,

I noticed Jena is still serving its site from SVN with help of the Apache CMS. 
At the Apache Celix
project we decided to move away from the CMS and move towards git for serving 
our website [1].
This because the CMS was introduced in 2010 and is currently not accepting any 
new projects. With
the move to Hugo we're sure that we still can update the site when the ASF CMS 
will be
decommissioned.

The master branch contains the actual website sources whereas the generated 
website is served
from the asf-site branch. Hugo is being used as static website generator. 
Content is written in
Markdown.

I had a look at Jena its site and it was quite easy to migrate Jena its site to 
use Hugo as well. An
example of Hugo its output is (for demo purposes only) available on [2]. These 
are the existing
markdown files with a slightly changed header.

Moving to git can enlarge the visibility of how projects are functioning. Next 
to that, new contributors
can simply create a pull request against the website repository if they find 
anything they want to
improve. I've updated the 'Improve this page' to 'Edit this page' which will 
open the GitHub webpage
to edit the currently viewed page (currently returning a 404 because the 
apache/jena-site repository
does not exist).

If the community is interested in this move what I propose:
- Someone from the PMC to request a new git repository for the website (e.g. 
jena-site) via [4]
- Me creating the pull request from the repository I am temporarily using for 
the website contents [5]
to the official jena-site repository
- Create a Jenkins job to automatically build the site after changes happen on 
the master branch.
- When the pull request is reviewed and merged ask INFRA to move over from the 
current svnpubsub
to the gitpubsub approach and remove Jena from the Apache CMS.

Next to that Jena is also providing javadocs on its site. My proposal for this 
is to serve them from a
separate branch (e.g. release-docs). This way people who only want to clone the 
site can clone the
the master branch using --single-branch and will not be bothered with cloning 
all the javadocs.

All the URLs are still the same so the SEO score is not influenced in any way.

I'd like to hear everyone's opinion on this :)

Best regards,
Roy

[1] https://github.com/apache/celix-site
[2] http://jena.roylenferink.nl/
[3] http://celix.apache.org/contributing/releasing.html
[4] https://gitbox.apache.org/setup/newrepo.html
[5] https://github.com/rlenferink/jena-site

Re: mvn build Apache Jena 3.15.0-SNAPSHOT

[Marco Neumann]

On Wed, Feb 19, 2020 at 4:49 PM Andy Seaborne  wrote:

>
>
> On 19/02/2020 14:04, Marco Neumann wrote:
> > On Wed, Feb 19, 2020 at 10:27 AM Andy Seaborne  wrote:
> >
> >> https://builds.apache.org/view/H-L/view/Jena/
> >>
> >> On 17/02/2020 15:32, Marco Neumann wrote:
> >>> FYI
> >>>
> >>> current Apache Jena 3.15.0-SNAPSHOT mvn build fails with OpenJDK 13.02
> on
> >>> SPARQL Text Search - Elasticsearch
> >>
> >> In what way?
>
> Marco - in what way does it fail?
>

Andy, something along those lines:
Caused by: java.security.AccessControlException: access denied
("java.lang.RuntimePermission"
"accessClassInPackage.jdk.internal.vm.annotation")

in the Apache Jena - SPARQL Text Search - Elasticsearch module

for details see attached debug.log  openjdk version "13.0.2"
2020-01-14 linux (64-Bit Server VM)

It's not a big deal for our current setup to change the jdk but it might
interfere with some build pipelines



>
> >> Do you have fix?
> >>
> >
> > the fix for now is to use jdk_12.01 for the build and tests with 'clean
> > install'
> >
> > BUILD SUCCESS
> > Total time:  06:51 min
> >
> > I have a similar issue and jdks with the ElasticSearch build over at
> RDF4j.
> > looks like it's jdk_13.02 related
> >
> >
> >>
> >> BTW ElasticSearch test plugin has a timing issue - the background server
> >> does not always close down promptly. The error does not cause maven to
> >> stop usually.
> >>
> >>>
> >>> builds successful with OpenJDK 12.0.1 but need to manually skip java
> doc.
> >>> Doesn't skip on GeoSPARQL Engine doc automatically.
> >>
> >> With -Pdev?
> >>
> >
> > see above. fixed for now
> >
> >
> >>
> >>> Apache Maven 3.6.3
> >>> OS name: "linux"
> >>> Total time:  04:23 min
> >>>
> >>
> >
> >
>


-- 


---
Marco Neumann
KONA


debug.log.gz
Description: GNU Zip compressed data

Re: [DISCUSS] Moving Jena site from Apache CMS/SVN to Git

[Roy Lenferink]

(inline comments)

On 2020/02/19 17:04:56, Andy Seaborne  wrote: 
> 
> Sorry, I haven't had time to investigate all the machinery but if the 
> javadoc is a different branch or repo, how does publish happen? And not 
> happen for changes during the development cycle?
> 

Publishing right now happens by checking out the 'production' site and adding 
the javadocs to there.
Publishing in the git way would happen by adding the generated javadocs to a 
separate branch or
repository.

Right now jena.a.o is served using SVN (config here [1]). In these config files 
it is possible to specify
multiple lines and specify a subfolder as well. E.g. what beam is doing here 
[2].

The following could make sense for jena:
/www/jena.apache.org:   $gitbox/jena-site
/www/jena.apache.org/content/documentation/javadoc: 
$gitbox/jena-site:release-docs

This means:
- That the 'master' branch will contain the sources for the site
- That the 'asf-site' branch will contain the generated output for the site
- That the 'release-docs' branch will contain additional files which will be 
served at http://jena.apache.org/documentation/javadoc/

>
> I know infra is working on a CMS replacement and/or guidelines.  Is this 
> it? Is it compatible? I thought they were going to have a buildbot2.
> 

Infra currently offers pelican and jekyll as 'replacements' for the CMS. 
However, Infra is also testing
a new build approach were the project can more or less define how their site is 
build [3]. This could
be a script to e.g. retrieve and execute Hugo.

I already had a quick chat with Infra about how to implement support for Hugo 
(e.g. next to Jekyll
and Pelican) but we decided that the new build approach will probably be a 
better fit.

> > 
> > Good to hear the community is interested in this :)
> 
> TBC: I am interested - I can't speak for the community.

My bad. I made the quick assumption by taking 2 responses and calling that 'the 
community', which is
almost never the case, oops!

> 

Let me know if any additional information is needed.

Roy

[1] 
https://github.com/apache/infrastructure-puppet/blob/5bd3b7cc8bd6d8f2698a6e0cac1f421dd960ddf0/modules/svnwcsub/files/svnwcsub.conf#L115
[2] 
https://github.com/apache/infrastructure-puppet/blob/5bd3b7cc8bd6d8f2698a6e0cac1f421dd960ddf0/modules/gitwcsub/files/config/gitwcsub.cfg#L49-L50
[3] 
https://lists.apache.org/thread.html/rf0d4fef9b65e1ef346bc71b66253f9e54f15e048be6d011751a24ae0%40%3Cdev.community.apache.org%3E

Re: [DISCUSS] Moving Jena site from Apache CMS/SVN to Git

[Andy Seaborne]

On 16/02/2020 18:38, Roy Lenferink wrote:

Hi Andy,

Thanks for your answer!

I can confirm it is easier to use Hugo on Windows compared to Jekyll (I am 
generating and testing
using the Ubuntu shell on Windows). Just downloading the tarball containing the 
Hugo binary and
you're good to go. With Jekyll the process is a bit more complex as it requires 
some specific Ruby
stuff.

(see my inline comments below as well)

On 2020/02/16 17:06:59, Andy Seaborne  wrote:

Hi Roy - looks good! Thanks for pushing this along.#

We had discussed this using Jekyll (because GH uses Jekyll) but I read
that installation on Windows is easier for Hugo (the speed issue does not
look like such an advantage for us) - and that that is helpful to get more
contributions. CMS and "improve this page" editing has had a reasonable
amount of use over the years but we do need to migrate away from CMS.


And this is something that will be kept in place, however instead of a redirect 
to the Apache CMS
it will open the GitHub editor with the file for the page the person is viewing 
at that moment.



Was conversion quite smooth? Any discoveries?
What's the markdown like? I don't know of anything special except of course
tables.



Most of it was just putting the pieces together. The CMS skeleton.html could 
--with a few minor
changes-- be re-used as Hugo template. The pages of the website were already 
written in
markdown and only the header of the file needed to be changed (old: [1], new 
[2]), the content of the
pages could just be re-used. Basically whatever syntax markdown supports is 
supported by Hugo [3].


Managing javadoc separately would be nice. Putting a lot of javadoc into
svn is a bit clunky.



Well, in the end the data still needs to be stored somewhere. However, in this 
case I'd suggest to put
it in a separate branch because in that way it is still possible for others to 
clone the site without the
huge javadoc collection.


Sorry, I haven't had time to investigate all the machinery but if the 
javadoc is a different branch or repo, how does publish happen? And not 
happen for changes during the development cycle?


I know infra is working on a CMS replacement and/or guidelines.  Is this 
it? Is it compatible? I thought they were going to have a buildbot2.




An alternative could be a complete separate repository, e.g. jena-release-docs, 
which contains all the
javadoc documentation, but this is just a matter of preference.



 Andy



Good to hear the community is interested in this :)


TBC: I am interested - I can't speak for the community.



Best,
Roy

[1] 
https://svn.apache.org/repos/asf/jena/site/trunk/content/getting_involved/reviewing_contributions.mdtext
[2] 
https://raw.githubusercontent.com/rlenferink/jena-site/110a42f109b25b9771f55a500cfffcb0593544f0/source/getting_involved/reviewing_contributions.md
[3] https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet

Re: mvn build Apache Jena 3.15.0-SNAPSHOT

[Andy Seaborne]

On 19/02/2020 14:04, Marco Neumann wrote:

On Wed, Feb 19, 2020 at 10:27 AM Andy Seaborne  wrote:


https://builds.apache.org/view/H-L/view/Jena/

On 17/02/2020 15:32, Marco Neumann wrote:

FYI

current Apache Jena 3.15.0-SNAPSHOT mvn build fails with OpenJDK 13.02 on
SPARQL Text Search - Elasticsearch


In what way?


Marco - in what way does it fail?


Do you have fix?



the fix for now is to use jdk_12.01 for the build and tests with 'clean
install'

BUILD SUCCESS
Total time:  06:51 min

I have a similar issue and jdks with the ElasticSearch build over at RDF4j.
looks like it's jdk_13.02 related




BTW ElasticSearch test plugin has a timing issue - the background server
does not always close down promptly. The error does not cause maven to
stop usually.



builds successful with OpenJDK 12.0.1 but need to manually skip java doc.
Doesn't skip on GeoSPARQL Engine doc automatically.


With -Pdev?



see above. fixed for now





Apache Maven 3.6.3
OS name: "linux"
Total time:  04:23 min

Re: mvn build Apache Jena 3.15.0-SNAPSHOT

[Marco Neumann]

On Wed, Feb 19, 2020 at 10:27 AM Andy Seaborne  wrote:

> https://builds.apache.org/view/H-L/view/Jena/
>
> On 17/02/2020 15:32, Marco Neumann wrote:
> > FYI
> >
> > current Apache Jena 3.15.0-SNAPSHOT mvn build fails with OpenJDK 13.02 on
> > SPARQL Text Search - Elasticsearch
>
> In what way?
> Do you have fix?
>

the fix for now is to use jdk_12.01 for the build and tests with 'clean
install'

BUILD SUCCESS
Total time:  06:51 min

I have a similar issue and jdks with the ElasticSearch build over at RDF4j.
looks like it's jdk_13.02 related


>
> BTW ElasticSearch test plugin has a timing issue - the background server
> does not always close down promptly. The error does not cause maven to
> stop usually.
>
> >
> > builds successful with OpenJDK 12.0.1 but need to manually skip java doc.
> > Doesn't skip on GeoSPARQL Engine doc automatically.
>
> With -Pdev?
>

see above. fixed for now


>
> > Apache Maven 3.6.3
> > OS name: "linux"
> > Total time:  04:23 min
> >
>


-- 


---
Marco Neumann
KONA

[VOTE][LAZY] Move from CMS/SVN to Hugo/Git

[Roy Lenferink]

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: mvn build Apache Jena 3.15.0-SNAPSHOT

[Andy Seaborne]

https://builds.apache.org/view/H-L/view/Jena/

On 17/02/2020 15:32, Marco Neumann wrote:

FYI

current Apache Jena 3.15.0-SNAPSHOT mvn build fails with OpenJDK 13.02 on
SPARQL Text Search - Elasticsearch


In what way?
Do you have fix?

BTW ElasticSearch test plugin has a timing issue - the background server 
does not always close down promptly. The error does not cause maven to 
stop usually.




builds successful with OpenJDK 12.0.1 but need to manually skip java doc.
Doesn't skip on GeoSPARQL Engine doc automatically.


With -Pdev?


Apache Maven 3.6.3
OS name: "linux"
Total time:  04:23 min