+1 After some thought I agree too. == Question on the CSV stuff and perhaps a "policy" idea. ==
Does the CSV conceptually just do IO into the graph? How closely are we aligned with RDF-Commons? Does it make sense that we urge (push is too strong a word) load/save of non-standard format (like CSV) to RDF-Commons where it might benefit a wider audience and have more development backing? I guess the "policy" idea is to look for synergies with RDF-Commons and act accordingly. Claude On Thu, May 11, 2017 at 3:06 PM, <aj...@apache.org> wrote: > I'm basically +1 to this. I wouldn't mind "setting a cron job" to do a > similar review every other or every three releases. > > --- > A. Soroka > > Bruno P. Kinoshita wrote on 5/11/17 4:59 AM: > > +1 to removing Fuseki1 now. And +1 for the legacy module definition and >> expectations. >> I'd be fine with jena-csv being removed, though I can see that being >> useful for people who need to quickly ingest data into something like >> Hadoop/Hive. >> And jena-spatial and jena-text are modules that I plan to study someday, >> just to have fun learning the ins and outs. May submit smaller commits to >> fix bits and pieces but not sure if could maintain the module. >> CheersBruno >> >> From: Andy Seaborne <a...@apache.org> >> To: dev@jena.apache.org >> Sent: Thursday, 11 May 2017 8:19 AM >> Subject: Evolution and legacy modules >> >> We need to do more than just add code to Jena; there needs to be a route >> to removing code as well. >> >> Starting with modules, there are some that are some that don't get the >> same care and attention and without some level of maintenance, such >> modules are dead weight to development. >> >> A "legacy module" >> >> * does not hold up a release >> * may be removed from the build >> (so they get swept up in a release as source only) >> * may be archived >> (taken out of the build and put elsewhere, such as a different repo) >> >> The way for anyone to "unlegacy" is to give it care and attention. >> >> Suggestions for legacy modules: >> >> jena-sdb >> jena-fuseki1 >> jena-csv >> jena-maven-tools >> jena-spatial >> >> Others? >> >> I don't have any plans to remove jena-sdb and it is unlikely to get in >> the way. TQ do not use it. >> >> jena-csv interferes with RIOT as it has a pseudo RDF Syntax for CSV >> which is simple and not standard (not CSVW). Steps to untangle it are >> in v3.3.0 and now we can make us of the pseudo RDF Syntax require >> jena-csv and put it all there. >> >> >> For Fuseki1, the next steps would be to remove it from the direct mention: >> >> * Remove explicit mention on the downloads page. >> * Remove jena-fuseki1 binary from the dist/binaries/ area. >> * Remove Fuseki1 from the javadoc on the website and the javadoc maker. >> >> These can be done now, not at the next release - it's not releasing >> anything. >> >> Andy >> >> >> >> >> >> -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
