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 >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> >> >> -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
