I have no specific requests/opinions other than that I rather deal with one bang than many small ones. Continuous refactoring is appealing for development, but a serious pain for adopters. And while I realize great care has been taken to keep the disruption as minimal as possible, I fear that some of our internal clients will have unexpected lower-level dependencies.
This brings me to a question I posed quite a while back and had to do with solidifying what is considered internal versus external APIs and SPIs. Ideally for the external interfaces there is a javadoc tag (e.g. @api and @spi) which indicates for an interface or factory if it is considered API/SPI. This could slowly be introduced over time for all accepted client interfaces. The contract would be that anything which is not API/SPI can be freely refactored (over time), and anything which is API/SPI requires deprecation first and an explicit release note before the change is pushed through. Any thoughts on this proposal? Simon From: Rob Vesse <[email protected]> To: "[email protected]" <[email protected]>, Date: 01/08/2013 02:07 PM Subject: Re: Towards Jena 2.10.0 +1 to Stephen's suggestion, it seems like the jena-core and jena-arq split is becoming increasingly contrived and problematic. As for a jena one jar I would be +0, I would prefer to retain the option of using individual modules (barring the proposed jena-core + jena-arq combination) over using a single jar. I feel things like TDB are really not useful in the things I do and I'd prefer not to have the extra dependencies if possible, typically I am only using ARQ. Whether we do it now or in the subsequent release I am ambivalent, I would prefer to get a new release sooner so I can start adapting to the package renames. Module reorgs would be relatively non-disruptive by comparison because that is going to be primarily only maven tweaks vs lots of code fixes. Rob On 1/7/13 7:14 PM, "Stephen Allen" <[email protected]> wrote: >On Sun, Jan 6, 2013 at 2:50 PM, Andy Seaborne <[email protected]> wrote: >> >> One of things we had talked about for 2.10 was a single jar for jena. a >> single clean maven dependency is a good step to that, and maybe the main >> point. > >I would be for a single jar. The split between jena-core and jena-arq >seems outdated at this point. > > >> I have been using a dependency on apache-jena with <type>pom</type> to >> cleanly pull in jena. >> >> apache-jena currently uses <classifier> sources and javadoc [1]. With >>these >> as dependencies, the assembly for the zip gets the sources and javadoc. >> This has not been a problem but I have been scala-ing recently and >>don't use >> m2e for that. >> >> But. >> >> I just set up a m2e project and had problems. m2e adds sources and >>javadoc >> as well to the project Maven dependencies. I'm not convinced the order >>is >> stable, with binaries before sources before javadoc; I've had at least >>one >> time when compilation didn't work. >> >> Does anyone know another, better (correct?) way to get the javadoc and >> sources in apache-jena? > >I do not have much experience with maven, so cannot even recommend >anything here. Sorry. > >> >> Should we include some module rename/reorganisation in 2.10? Or ship >>2.10 >> as-is and move quite quickly to have a 2.11.X for reorg? Seems to be me >>that >> it merits an incremental version bump. (I see pros and cons of each >> approach, doing now or waiting.) >> > >Slight preference for doing it in 2.10, since it's a larger version >bump than normal. > >> Andy >> >> [1] >> >> https://svn.apache.org/repos/asf/jena/trunk/apache-jena/assembly-jena-zip >>.xml >> >> >> On 04/01/13 18:32, Andy Seaborne wrote: >>> >>> It may be useful to check what needs to be done to get Jena 2.10.0 out >>> with some time allocated to user-driven testing before release. i >>> though doing that for SDB was quite successful. >>> >>> 2.10 contains many small changes which are either internal or of >>>minimal >>> external affect. The largest external effect is probably rectification >>> changes. But there are a lot of changes and not all applications stick >>> to external APIs. There is a chance some that something inconvenient >>> has changed which can be smoothed over to help users. >>> >>> So I suggest a "release candidate" cycle like we did for SDB - not a >>> formally release (with all it's vote and maven distribution upload) but >>> a statement that the SNAPSHOT build is ready for pre-release testing. >>> Any unnecessary friction points just get fixed in the dev build cycle; >>> anything significant comes to dev@ for discussion. >>> > >+1 > >>> Things to do for 2.10.0: >>> >>> 1/ It would be good to include the reorganised and refactored tests >>> (JENA-370) >>> >>> Claude - I tried to apply the patch but either I didn't understand the >>> intent or it is missing some classes (moved? and only the old version >>> removed, without a new version in the patch?) >>> >>> 2/ Events >>> >>> Currently, the model-level events are old-style, events for each of the >>> ways to add/delete statements (list, iterator, model, single ...). >>> >>> This is factored into a single global GraphUtil.OldStyle. But many >>> tests are likely to change so I was leaving this until after JENA-370 >>>as >>> the codebase and the patch are already from different generations >>>already. >>> >>> 3/ Steaming support (partial) >>> >>> Stephen - is there anything we should be aiming for in this release to >>> move things along? > >Streaming works except for the out of order lists and blank node >shortcuts. Unfortunately this is related pretty intricately with the >streaming design, so I don't think I can break out much to be >committed separate. I need to fix this, then I think I can merge back >the branch. > >Part of the issue here is I don't really know what the right solution >is. I can theoretically imagine how it can be done by looking ahead, >or with a stack, but translating that into JavaCC is where I'm getting >hung up. But also it's that I haven't had much time recently to work >on it. > >>> >>> 4/ Anything else anyone wants to get in? >>> >>> Andy >>
