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 <[email protected]> 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 <[email protected]> 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 would like to contribute the code and documentation to the Jena
project
as an "extras" project. Further information about the project and the
code
can be found at https://github.com/Claudenw/PA4RDF.
Is there any objection to accepting this contribution?
Claude
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
