Re: Next apache-jena release

Paulo, thanks. The pom.xml information is certainly useful as it proves how the tests were run. In most cases this will be enough. However, problems start happening when a later component (e.g. LARQ) has been tested with later snapshots than the current release. I think it is important that all

Re: LARQ (and other Fuseki extensions) Integration Strategy

Hi Rob Robert Vesse wrote: > There's nothing to stop us making LARQ generate an uber-jar in the same > way we do for Fuseki with maven shade is there? > > This would be sufficient for users if they only had to drop in a single > extra JAR into a directory - most users can manage that ;-) My 0 ha

Re: LARQ (and other Fuseki extensions) Integration Strategy

On 5/25/12 10:25 AM, "Paolo Castagna" wrote: >Hi Rob > >Robert Vesse wrote: >> In the context of the discussion of next releases maybe this is a good >>time to revisit the topic of LARQ and its integration with Fuseki >> >> As I understand it right now the way to deploy LARQ is to modify the >>

Re: LARQ (and other Fuseki extensions) Integration Strategy

Hi Rob Robert Vesse wrote: > In the context of the discussion of next releases maybe this is a good time > to revisit the topic of LARQ and its integration with Fuseki > > As I understand it right now the way to deploy LARQ is to modify the Fuseki > POM to pull in the LARQ dependency so that on

Re: Next apache-jena release

Simon Helsen wrote: > 4) LARQ: so far, we have not been using it, but we are thinking of > starting with that, so having it released with 2.7.1 would be nice. If > this does not happen, then, it would help if there is a clear indication > with what release a given component would be compatible (

LARQ (and other Fuseki extensions) Integration Strategy

In the context of the discussion of next releases maybe this is a good time to revisit the topic of LARQ and its integration with Fuseki As I understand it right now the way to deploy LARQ is to modify the Fuseki POM to pull in the LARQ dependency so that one can built a modified Fuseki uber jar

Re: Next apache-jena release

Hi Andy Seaborne wrote: > Starting proposal: > > 1/ Single source release, not one per module. Good. > Paolo - what about LARQ? If it gets placed in the release, would that > hamper getting incremental update released soon? Or do as a parallel > release (i.e. not in apache-jena but part of th

Re: Next apache-jena release

Thanks Andy. I was going to ask about this non-incubating release, but this answers it :-) I have been testing a 2.7.1 snapshot of earlier in the week and have found no functional problems so far. Query performance with 50+ threads is still somewhat weak, but I am going to compare the same sui

[jira] [Closed] (JENA-225) TDB datasets can be corrupted by performing certain operations within a transaction

[ https://issues.apache.org/jira/browse/JENA-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne closed JENA-225. -- > TDB datasets can be corrupted by performing certain operations within a > transaction > -

[jira] [Resolved] (JENA-225) TDB datasets can be corrupted by performing certain operations within a transaction

[ https://issues.apache.org/jira/browse/JENA-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne resolved JENA-225. Resolution: Fixed Fix Version/s: TDB 0.9.1 Assignee: Andy Seaborne > TDB datasets

SDB - release?

I'm feeling guilt we haven't released SDB under ASL. Thoughts that come to mind are: Whether to provide to do it as maven only release (and source-release on /dist), no binary download. Include any database someone has provided the code for on the understanding that we haven't tested it. To

Next apache-jena release

It would be nice to make a release now we are out of incubation. I think doing the least to make the release happen is the right next step but I can be persuaded that doing more on integration of components is worth waiting for. Starting proposal: 1/ Single source release, not one per module