It is difficult to find the link of "Tutorial 1".

[Anonymous CMS User]

Clone URL (Committers only):
https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/tutorials%2Frdf_api.mdtext

Hello.

It is difficult to find the source link to "Tutorial 1".

I think because another code block is between the code block of "Tutorial 1" 
and the link.

The change fix it.

Index: trunk/content/tutorials/rdf_api.mdtext
===
--- trunk/content/tutorials/rdf_api.mdtext  (revision 1655891)
+++ trunk/content/tutorials/rdf_api.mdtext  (working copy)
@@ -129,6 +129,11 @@
 classes for other well known schemas, such as RDF and RDF schema themselves,
 Dublin Core and OWL.
 
+The working code for this example can be found in the /src-examples 
directory of
+the Jena distribution as https://github.com/apache/jena/tree/master/jena-core/src-examples/jena/examples/rdf/Tutorial01.java;>tutorial
 1.  As
+an exercise, take this code and modify it to create a simple VCARD for
+yourself.
+
 The code to create the resource and add the property, can be more
 compactly written in a cascading style:
 
@@ -138,11 +143,6 @@
  .addProperty(VCARD.FN, fullName);
 
 
-The working code for this example can be found in the /src-examples 
directory of
-the Jena distribution as https://github.com/apache/jena/tree/master/jena-core/src-examples/jena/examples/rdf/Tutorial01.java;>tutorial
 1.  As
-an exercise, take this code and modify it to create a simple VCARD for
-yourself.
-
 Now let's add some more detail to the vcard, exploring some more features
 of RDF and Jena.
 

Re: JPA contribution

[Claude Warren]

I missed your Q regarding links.  Yes they are closed or semi-closed.
Granatum (run by deri.ie now insight.ie) was supposed to be an opensource
project but they never released the code :(  So I don't have any links.

Claude

On Fri, Jan 27, 2017 at 8:46 AM, Andy Seaborne  wrote:

> I think that putting code into the corner of a large project is actually
> less likely to create community.  Moving it has a cost as people loose
> track of it or keep going to the old place (c.f. Jena SF->ASF).  Then, it
> can get lost on the discussions about the whole project.
>
> As you haven't answered, I presume the uses of PA4RDF are in closed or no
> longer running projects.
>
> I'll take the wider point on finding other projects to a separate reply.
>
> Andy
>
>
> On 26/01/17 11:11, Claude Warren wrote:
>
>> Moving PA4RDF is about building a stronger community.
>>
>> Perhaps it makes more sense to create more visible links to external
>> projects that extend Jena rather than bring them in.
>> Or perhaps we should consider "extras" as things that build on Jena but
>> are
>> not part of the mainline build and open it up to more projects, or set
>> some
>> measure they have to meet to be included.
>>
>> I think Jena would be well served if it were possible to come to the Jena
>> website and discover how viverent the external community is, how it is
>> being used and what extra tooling is available to make whatever project
>> easier to implement.
>>
>> Claude
>>
>> On Thu, Jan 26, 2017 at 10:21 AM, Andy Seaborne  wrote:
>>
>>
>>>
>>> On 25/01/17 21:00, Claude Warren wrote:
>>>
>>> I know of 3 projects that used PA4RDF.  There has been virtually no
 change
 (except for the renaming for oaj packaging).  So there is virtually no
 community.


>>> Are these open source projects? Links?
>>>
>>> I would like to put the code into the Jena code base as an extra.
>>>


>>> I don't understand why you want to move the code.
>>>
>>> If this is just moving the code over, nothing is gained for PA4RDF and it
>>> is extra code to look after for Jena.
>>>
>>>  However,
>>>
 I understand the issue around the large build.

 Andy,  you mention jena-maven-tools, jena-csv and jena-fuseki1.  Do you
 have a strategy for how to separate them and yet build them as part of
 the
 master build.


>>> I would suggest labelling them "deprecated" then removing them.
>>> How we retire them is not about builds.
>>>
>>> Andy
>>>
>>>
>>>
>>> I think we might be able to create jenkins builds that depend upon the
 master build to build the various "extra" parts.  I would suggest that
 we
 attempt to get a build like that working and do it as the 3.3.0 release.
 This would put us in a better position to deprecate those components
 later.



>>> I think we would also need to adjust the website to highlight the
 "extra"s
 better.

 We will need to have discussions around what should go into the master
 build and what should be moved to "extra" as well as how we determine
 that
 in future.

 Claude

 On Sun, Jan 22, 2017 at 7:50 PM, Andy Seaborne  wrote:



> On 22/01/17 14:21, A. Soroka wrote:
>
> This is a cool project that seems like it would be of use to Jena
>
>> users. It raises a question for me about how Jena handles
>> contributions generally (not specific to this example).
>>
>> Do we have any policy about how much support must exist from
>> committers to accept a project? For example, in some other projects
>> in which I participate, it's necessary for at least two committers to
>> accept responsibility to maintain a module before it can be accepted,
>> and if there are ever fewer than that over time, it goes into a
>> deprecation path that eventuates in it leaving the project. I'm not
>> arguing for that policy in particular for Jena, just wondering if we
>> have anything like that, or whether the modules are pruned on an ad
>> hoc basis.
>>
>>
>> Good points.  There needs to be activity around a component to keep it
> alive and well.
>
> In addition, if we put everything into a single build process it
> becomes
> increasingly harder to release and to make changes to the main codebase
> because everything is lock-step.  2 of the release releases have been
> like
> that.
>
> I wonder if splitting into "the main build" where we can regularly
> release
> with fixes. Other parts can be released separately by people
> interested.
>
> We need to be able to retire parts: jena-maven-tools and jena-csv are
> current examples, as is jena-fuseki1.  This process needn't be fast or
> abrupt but for the long term health of the project, we have to
> recognize
> that some parts will fade away when no one is 

Re: 3.2.0 Release

[Andy Seaborne]

On 27/01/17 15:24, A. Soroka wrote:

Hi, folks--

As previously discussed, we seem to be ready for a 3.2.0 release. I
would like to begin that process on Monday. With that in mind, please
do any last minor work you would like to see in this release before
Monday morning (US Eastern). I will begin cutting a release candidate
at that time and like all release managers everywhere, I'd prefer to
have a non-moving target for my release-cutting knife. :)

Of course, if there are any reasons to delay or block a release,
please do speak up about them.

ajs6f



Works for me.

I sorted out the outstanding JSON-LD PR from fps and clear-up PR I had 
on the stack.


I have another in in-progress (improvements In GraphUtils for adding and 
deleting graphs when one graph is a very different size to the other) 
but this is not for 3.2 and I won't put in a pull request yet.


Andy

Re: Jena 3.2.0 release processing

[A. Soroka]

I've got more to do than that-- as I said, I've had some computer failures, so 
I need to make sure that I'll have a solid workstation with which to do this. 
That's why I'm waiting 'til Monday, when I am back in the office. It shouldn't 
be a problem by then.

ajs6f


> On Jan 27, 2017, at 10:30 AM, Andy Seaborne  wrote:
> 
> 
> 
> On 27/01/17 15:19, A. Soroka wrote:
>> Just getting onto this-- I've had a laptop failure and have been slowly 
>> assembling alternative systems. But I think I'm in good enough shape to move 
>> on this.
>> 
>> Let me start with an official call-- I'm not sure I saw three exact +1s, and 
>> on my first release, I'd like to cross all the 't's and dot all the 'i's. 
>> :grin:
> 
> That's the vote.
> 
> Anyone can call for a release at any time - it's not a vote or consensus.
> 
> It may not succeed, but that's a different matter.
> 
> As well as saying it's happening, as you have, you can do the dry run now and 
> let mavne download the internet into a clean repo.
> 
> I'm not sure if this is needed still in the clean clone .git/config
> 
> ## Put hashes in status output
> [status]
> displayCommentPrefix = true
> 
> I thought it wasn't but when I did TDB2 recently, I found it was.
> 
>   Andy
> 
> For lurkers watching:
> 
> https://cwiki.apache.org/confluence/display/JENA/Release+Process
> 
>> 
>> ajs6f
>> 
>>> On Jan 27, 2017, at 3:48 AM, Andy Seaborne  wrote:
>>> 
>>> Ping.
>>> 
>>> What can I do to help you with the release?
>>> 
>>>   Andy
>>> 
>>> On 23/01/17 15:15, A. Soroka wrote:
 +1 to a release, and I would be happy to RM, provided Andy or
 someone  else who has driven the course would be available to advise a 
 bit. I'm
 going to go study the release procedures page now.
>>> ...
 ---
 A. Soroka
>> 

Re: Jena 3.2.0 release processing

[Andy Seaborne]

On 27/01/17 15:19, A. Soroka wrote:

Just getting onto this-- I've had a laptop failure and have been slowly 
assembling alternative systems. But I think I'm in good enough shape to move on 
this.

Let me start with an official call-- I'm not sure I saw three exact +1s, and on 
my first release, I'd like to cross all the 't's and dot all the 'i's. :grin:


That's the vote.

Anyone can call for a release at any time - it's not a vote or consensus.

It may not succeed, but that's a different matter.

As well as saying it's happening, as you have, you can do the dry run 
now and let mavne download the internet into a clean repo.


I'm not sure if this is needed still in the clean clone .git/config

## Put hashes in status output
[status]
 displayCommentPrefix = true

I thought it wasn't but when I did TDB2 recently, I found it was.

Andy

For lurkers watching:

https://cwiki.apache.org/confluence/display/JENA/Release+Process



ajs6f


On Jan 27, 2017, at 3:48 AM, Andy Seaborne  wrote:

Ping.

What can I do to help you with the release?

   Andy

On 23/01/17 15:15, A. Soroka wrote:

+1 to a release, and I would be happy to RM, provided Andy or
someone  else who has driven the course would be available to advise a bit. I'm
going to go study the release procedures page now.

...

---
A. Soroka

3.2.0 Release

[A. Soroka]

Hi, folks--

As previously discussed, we seem to be ready for a 3.2.0 release. I would like 
to begin that process on Monday. With that in mind, please do any last minor 
work you would like to see in this release before Monday morning (US Eastern). 
I will begin cutting a release candidate at that time and like all release 
managers everywhere, I'd prefer to have a non-moving target for my 
release-cutting knife. :)

Of course, if there are any reasons to delay or block a release, please do 
speak up about them.

ajs6f

Re: Jena 3.2.0 release processing

[A. Soroka]

Just getting onto this-- I've had a laptop failure and have been slowly 
assembling alternative systems. But I think I'm in good enough shape to move on 
this.

Let me start with an official call-- I'm not sure I saw three exact +1s, and on 
my first release, I'd like to cross all the 't's and dot all the 'i's. :grin:

ajs6f

> On Jan 27, 2017, at 3:48 AM, Andy Seaborne  wrote:
> 
> Ping.
> 
> What can I do to help you with the release?
> 
>Andy
> 
> On 23/01/17 15:15, A. Soroka wrote:
>> +1 to a release, and I would be happy to RM, provided Andy or
>> someone  else who has driven the course would be available to advise a bit. 
>> I'm
>> going to go study the release procedures page now.
> ...
>> ---
>> A. Soroka

[jira] [Resolved] (JENA-1282) Rename fatal as error in Log support.

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne resolved JENA-1282.
-
Resolution: Fixed

> Rename fatal as error in Log support.
> -
>
> Key: JENA-1282
> URL: https://issues.apache.org/jira/browse/JENA-1282
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.1.1
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.2.0
>
>
> "error" is the more usual naming nowadays. slf4j dos not have a "fatal" 
> level. "fatal" can be taken to indicate that either code can not continue at 
> all but errors in data do not necessarily mean that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1282) Rename fatal as error in Log support.

[ASF subversion and git services (JIRA)]

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

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

Commit 44264d1c5310f7764256cbfee646a165a1e8e2dc in jena's branch 
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=44264d1 ]

JENA-1282: Merge commit 'refs/pull/208/head' of github.com:apache/jena

This closes #208.


> Rename fatal as error in Log support.
> -
>
> Key: JENA-1282
> URL: https://issues.apache.org/jira/browse/JENA-1282
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.1.1
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.2.0
>
>
> "error" is the more usual naming nowadays. slf4j dos not have a "fatal" 
> level. "fatal" can be taken to indicate that either code can not continue at 
> all but errors in data do not necessarily mean that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena pull request #208: Logging fatal to error

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/jena/pull/208


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-1276) "loading remote context failed" reading JSON-LD

[ASF subversion and git services (JIRA)]

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

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

Commit 05e68d00043f374e7fd28e7342102bc4cd297064 in jena's branch 
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=05e68d0 ]

JENA-1276: Merge commit 'refs/pull/207/head' of github.com:apache/jena

Some maintenance after JENA-1276.

This closes #207.


> "loading remote context failed" reading JSON-LD
> ---
>
> Key: JENA-1276
> URL: https://issues.apache.org/jira/browse/JENA-1276
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.1.1
> Environment: mac osx 10.11, eclipse mars
>Reporter: François-Paul Servant
> Fix For: Jena 3.2.0
>
>
> getting org.apache.jena.riot.RiotException: loading remote context failed: 
> http://schema.org/ reading json-ld with an @context set to schema.org
> see https://github.com/apache/jena/pull/203
> the exception occurs here:
> com.github.jsonldjava.core.DocumentLoader.loadDocument(String) line 29
> where I get:
> org.apache.http.ConnectionClosedException: Premature end of Content-Length 
> delimited message body (expected: 124346; received: 0
> {noformat}
> public class TestJsonLDReader {
> @Test public final void simpleReadTest() {
> try {
> String jsonld = someSchemaDorOrgJsonld();
> Model m = ModelFactory.createDefaultModel();
> try (StringReader reader = new StringReader(jsonld)) {
> m.read(reader, null, "JSON-LD");  
> }
> assertJohnDoeIsOK(m);
> } catch (RiotException e) {
> // org.apache.jena.riot.RiotException: loading remote context 
> failed: http://schema.org/
> e.printStackTrace();
> }
> }
> /** Example data */
> private String someSchemaDorOrgJsonld() {
> return "{\"@id\":\"_:b0\",\"@type\":\"Person\",\"name\":\"John 
> Doe\",\"@context\":\"http://schema.org/\"};;
> }
> /** Checking that the data loaded from someSchemaDorOrgJsonld into a 
> model, is OK */
> private void assertJohnDoeIsOK(Model m) {
> assertTrue(m.contains(null, RDF.type, 
> m.createResource("http://schema.org/Person;)));
> assertTrue(m.contains(null, 
> m.createProperty("http://schema.org/name;), "John Doe"));   
> }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1276) "loading remote context failed" reading JSON-LD

[ASF subversion and git services (JIRA)]

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

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

Commit 05e68d00043f374e7fd28e7342102bc4cd297064 in jena's branch 
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=05e68d0 ]

JENA-1276: Merge commit 'refs/pull/207/head' of github.com:apache/jena

Some maintenance after JENA-1276.

This closes #207.


> "loading remote context failed" reading JSON-LD
> ---
>
> Key: JENA-1276
> URL: https://issues.apache.org/jira/browse/JENA-1276
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.1.1
> Environment: mac osx 10.11, eclipse mars
>Reporter: François-Paul Servant
> Fix For: Jena 3.2.0
>
>
> getting org.apache.jena.riot.RiotException: loading remote context failed: 
> http://schema.org/ reading json-ld with an @context set to schema.org
> see https://github.com/apache/jena/pull/203
> the exception occurs here:
> com.github.jsonldjava.core.DocumentLoader.loadDocument(String) line 29
> where I get:
> org.apache.http.ConnectionClosedException: Premature end of Content-Length 
> delimited message body (expected: 124346; received: 0
> {noformat}
> public class TestJsonLDReader {
> @Test public final void simpleReadTest() {
> try {
> String jsonld = someSchemaDorOrgJsonld();
> Model m = ModelFactory.createDefaultModel();
> try (StringReader reader = new StringReader(jsonld)) {
> m.read(reader, null, "JSON-LD");  
> }
> assertJohnDoeIsOK(m);
> } catch (RiotException e) {
> // org.apache.jena.riot.RiotException: loading remote context 
> failed: http://schema.org/
> e.printStackTrace();
> }
> }
> /** Example data */
> private String someSchemaDorOrgJsonld() {
> return "{\"@id\":\"_:b0\",\"@type\":\"Person\",\"name\":\"John 
> Doe\",\"@context\":\"http://schema.org/\"};;
> }
> /** Checking that the data loaded from someSchemaDorOrgJsonld into a 
> model, is OK */
> private void assertJohnDoeIsOK(Model m) {
> assertTrue(m.contains(null, RDF.type, 
> m.createResource("http://schema.org/Person;)));
> assertTrue(m.contains(null, 
> m.createProperty("http://schema.org/name;), "John Doe"));   
> }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena pull request #207: JsonLDWriter.toJsonLDJavaAPI: create a JsonLD API ob...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/jena/pull/207


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-1282) Rename fatal as error in Log support.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1282:
--

Github user afs commented on the issue:

https://github.com/apache/jena/pull/208
  
JENA-1282


> Rename fatal as error in Log support.
> -
>
> Key: JENA-1282
> URL: https://issues.apache.org/jira/browse/JENA-1282
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.1.1
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.2.0
>
>
> "error" is the more usual naming nowadays. slf4j dos not have a "fatal" 
> level. "fatal" can be taken to indicate that either code can not continue at 
> all but errors in data do not necessarily mean that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JENA-1282) Rename fatal as error in Log support.

[Andy Seaborne (JIRA)]

Andy Seaborne created JENA-1282:
---

 Summary: Rename fatal as error in Log support.
 Key: JENA-1282
 URL: https://issues.apache.org/jira/browse/JENA-1282
 Project: Apache Jena
  Issue Type: Bug
Affects Versions: Jena 3.1.1
Reporter: Andy Seaborne
Assignee: Andy Seaborne
Priority: Minor
 Fix For: Jena 3.2.0


"error" is the more usual naming nowadays. slf4j dos not have a "fatal" level. 
"fatal" can be taken to indicate that either code can not continue at all but 
errors in data do not necessarily mean that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena issue #208: Logging fatal to error

[afs]

Github user afs commented on the issue:

https://github.com/apache/jena/pull/208
  
JENA-1282


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Jena 3.2.0 release processing

[Andy Seaborne]

Ping.

What can I do to help you with the release?

Andy

On 23/01/17 15:15, A. Soroka wrote:

+1 to a release, and I would be happy to RM, provided Andy or
someone  else who has driven the course would be available to advise a bit. I'm
going to go study the release procedures page now.

...

---
A. Soroka

Re: JPA contribution

[Andy Seaborne]

I think that putting code into the corner of a large project is actually 
less likely to create community.  Moving it has a cost as people loose 
track of it or keep going to the old place (c.f. Jena SF->ASF).  Then, 
it can get lost on the discussions about the whole project.


As you haven't answered, I presume the uses of PA4RDF are in closed or 
no longer running projects.


I'll take the wider point on finding other projects to a separate reply.

Andy

On 26/01/17 11:11, Claude Warren wrote:

Moving PA4RDF is about building a stronger community.

Perhaps it makes more sense to create more visible links to external
projects that extend Jena rather than bring them in.
Or perhaps we should consider "extras" as things that build on Jena but are
not part of the mainline build and open it up to more projects, or set some
measure they have to meet to be included.

I think Jena would be well served if it were possible to come to the Jena
website and discover how viverent the external community is, how it is
being used and what extra tooling is available to make whatever project
easier to implement.

Claude

On Thu, Jan 26, 2017 at 10:21 AM, Andy Seaborne  wrote:




On 25/01/17 21:00, Claude Warren wrote:


I know of 3 projects that used PA4RDF.  There has been virtually no change
(except for the renaming for oaj packaging).  So there is virtually no
community.



Are these open source projects? Links?

I would like to put the code into the Jena code base as an extra.




I don't understand why you want to move the code.

If this is just moving the code over, nothing is gained for PA4RDF and it
is extra code to look after for Jena.

 However,

I understand the issue around the large build.

Andy,  you mention jena-maven-tools, jena-csv and jena-fuseki1.  Do you
have a strategy for how to separate them and yet build them as part of the
master build.



I would suggest labelling them "deprecated" then removing them.
How we retire them is not about builds.

Andy




I think we might be able to create jenkins builds that depend upon the
master build to build the various "extra" parts.  I would suggest that we
attempt to get a build like that working and do it as the 3.3.0 release.
This would put us in a better position to deprecate those components
later.





I think we would also need to adjust the website to highlight the "extra"s
better.

We will need to have discussions around what should go into the master
build and what should be moved to "extra" as well as how we determine that
in future.

Claude

On Sun, Jan 22, 2017 at 7:50 PM, Andy Seaborne  wrote:




On 22/01/17 14:21, A. Soroka wrote:

This is a cool project that seems like it would be of use to Jena

users. It raises a question for me about how Jena handles
contributions generally (not specific to this example).

Do we have any policy about how much support must exist from
committers to accept a project? For example, in some other projects
in which I participate, it's necessary for at least two committers to
accept responsibility to maintain a module before it can be accepted,
and if there are ever fewer than that over time, it goes into a
deprecation path that eventuates in it leaving the project. I'm not
arguing for that policy in particular for Jena, just wondering if we
have anything like that, or whether the modules are pruned on an ad
hoc basis.



Good points.  There needs to be activity around a component to keep it
alive and well.

In addition, if we put everything into a single build process it becomes
increasingly harder to release and to make changes to the main codebase
because everything is lock-step.  2 of the release releases have been
like
that.

I wonder if splitting into "the main build" where we can regularly
release
with fixes. Other parts can be released separately by people interested.

We need to be able to retire parts: jena-maven-tools and jena-csv are
current examples, as is jena-fuseki1.  This process needn't be fast or
abrupt but for the long term health of the project, we have to recognize
that some parts will fade away when no one is interested.


For PA4RDF - what communities are there? User community? Developer
community?

Andy


Incidentally, in a sort of slow, long term activity, I have some work to
extract what linked data applications need for XSD datatyping:

https://github.com/afs/xsd4ld

It has the missing types of PA4RDF; it is not tied to Jena at all (no
dependency).






---
A. Soroka

On Jan 21, 2017, at 3:40 AM, Claude Warren  wrote:


Greetings,

I have a project (PA4RDF) that provides persistence annotations that
read/write a Jena graph.

It basically turns any RDF subject into an object with the predicates
defining the properties of the object.

The current implementation can apply the annotations to interfaces,
abstract or concrete classes.  It has been used in several projects
with
different corporate and government owners.

I