Hi guys, we're not yet ready to adopt 2.10.0 any time soon since we are still struggling getting our products on 2.7.4 (not actually due to 2.7.4 issues -> probably, we've some inconsistent performance reports we need to investigate further). However, in order to get a sense of what is ahead of us, I attempted an upgrade and ran our own local junit suite. I created a fresh snapshot with SVN state of today (Feb 11). These are my observations
1) we had a few usages of org.openjena.atlas, but it was straightforward to adjust the package names. I am not anticipating significant effects on our own clients since they should not be using these APIs. If they do, the fix is simple 2) we had a few occurrences of BulkUpdateHandler which is only deprecated and seems simple to change. Same issue with client dependencies. none of this is unexpected and simple to manage. More importantly, after the adjustment, the actual junit suite went through without a hitch. So that is a good thing. now, as always it is possible there are other issues that we are not seeing in our own suite. Usually performance related problems are only uncovered later on when our internal clients start to adopt, but at least there is nothing major right now. Subtle corruption problems may also be uncovered later on in the game. But I can only report on the ones I see Simon From: Rob Vesse <rve...@yarcdata.com> To: "dev@jena.apache.org" <dev@jena.apache.org>, Date: 02/11/2013 01:46 PM Subject: Re: Jena 2.10.0 - ready yet? Hey Andy Personally I have been very happy with the stability of 2.10.0, bar the minor hiccups with the streaming updates API getting finalized it has caused us minimal problems and allowed us to eliminate workarounds for some bugs we had previously encountered. QA have reported no regressions or other issues related to our upgraded to 2.10.0 in the one integration test they have already done and another cycle will be taking place this week which will verify the streaming update changes haven't caused us any regressions. I would like to proceed with the community testing phase ASAP as ideally I need to have a stable release I can switch to in just under 4 weeks which may be pushing things a little but that is my window for fixing the Jena version for our next release. Moving back to 2.9.4 would be a considerable pain at this point so if we can't get things done by then we can likely lock down on the most up to date SNAPSHOT at the time (since we have our own Artifactory deployment). Rob On 2/10/13 8:24 AM, "Andy Seaborne" <a...@apache.org> wrote: >How are we doing for a Jena 2.10.0 release? > >I think we're ready to start pre-release testing with the user community >in advance of the formal release? This is not a purely incremental >release and it would be good to remove any unnecessary disruption that >the changes cause. > >I have put some draft text together (see below) for the testing cycle. >This includes some thing about /Experimental to let people see what's >also going on. > >Rob - any feedback from your early testing work? > >Stephan - I put in some text about update+streaming but if you want to >put some more in to pick out the key details, then please do so. > > >RIOT Status: > >RIOT/readers: > >RIOT - jena is not automatically initializing RIOT readers into >model.read currently; it only happens if ARQ initializes or RIOT.init is >explicitly called. May be doable for the release but I prefer to be >quite sure automatic initialization is stable for all ways to use Jena. > >RIOT/writers: > >The new code is not completely ready yet. It need more tests and tidying >up. The documentation needs writing. > >I don't think waiting on this is a reason to hold the 2.10 release up. > >If it is in good shape by the release proper, it could go in without it >wiring itself into model.write so it is only used when calling the new: > > RDFWriterMgr.write(model, format) > >so if you use it, you get the new code, but existing code continues with >the old writers. > >Other: > >Are there any contributed patches we should try to get in? I know of >one (JENA-228). Any others? > >Have I forgotten anything else? > > Andy > > >----------------- >**** DRAFT **** >Testing cycle announcement text: > > >== apache-jena-libs > >There is a new maven artifact to help applications by providing a single >maven artifact that include the main Jena modules. > > <dependency> > <groupId>org.apache.jena</groupId> > <artifactId>apache-jena-libs</artifactId> > <type>pom</type> > <version>2.10.0</version> > </dependency> > >Note the use of <type>pom</type> > >BY using this artifact, applications will not be affected by any changes >to the internal development module structure of Jena. > >See >http://jena.staging.apache.org/download/maven.html > >== RIOT Reader > >There is a new RDF parser subsystem, which includes > >* improved content negotiation >* the ability to register new parsers into Jena >* alignment to RDF 1.1 Turtle >* these features apply when applications use model.read > >http://jena.apache.org/documentation/io/index.html > >The package name org.openjena.riot becomes org.apache.jena.riot. > >There is some compatibility code in org.openjena.riot. Operations are >deprecated and will be removed after this release. > >Call > org.apache.jena.riot.RIOT.init() >to ensure it is initialized. > >(An automatic initialization inside Jena risks class init loops - we >will add automatic initialization in Jena 2.10.0 only if we can ensure >stability) > >== Streaming Update > >The SPARQL Update engine has been re-architected to make the fundamental >execution of SPARQL Updates streamable. > >There is no change to applications using SPARQL Update. > >There are changes to the interface for storage systems that make special >provision for SPARQL Update. If you are migrating such a storage system, >do talk to the developers on dev@jena.apache.org if you have any >questions or sugegstiosn for improvements. > >== Portuguese Translations of the tutorial > >Guilherme Cavalcanti has provided a Portuguese translation of the >tutorials. > >http://jena.staging.apache.org/tutorials/ > >== Reification > >As part of simplifying Jena, the reification styles Convenient and >Minimal are being removed. These need a significant amount of internal >state management and impede scaling beyond storage in memory. > >The only support style is "standard", which as always been the default >style in Jena. Only style "standard" has even been supported by TDB and >SDB. > >Use of the constants for these styles is deprecated and will be treated >as "standard". > >== Internal simplification > >Other simplifications in this release include the removal of the graph >query handler subsystem. This is unrelated to SPARQL and existed in >support of RDQL. > >The graph level bulk query handler has been removed - compatibility for >the Model API for all bulk update is maintained. > >== Other interesting things >[ Not for the announcement@ message ] > >There is an "experimental" area in Jena SVN where some new features are >being tried out. There is no commitment to these features becoming part >of trunk but you are welcome to browse and contribute to these >developments. > >https://svn.apache.org/repos/asf/jena/Experimental/ > >* jena-client > >new interface to SPARQL services > >* riot-output > >These are new writers to go into RIOT, including Trig and an extensible >registry of writers. > >* sparql-cache > >a HTTP cache for SPARQL queries that caches query results and can also >deal with repeated use of limit/offset to mimic paging and represent >results in different formats without reissuing the query. > >* cancellable-updates > >An experiment into extending the query time mechanism to the SPARQL >Update code. > > > >
