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 <a...@apache.org> 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 <a...@apache.org> 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 <cla...@xenei.com> 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
