You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2013/01/04 19:32:05 UTC
Towards Jena 2.10.0
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.
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?
4/ Anything else anyone wants to get in?
Andy
Re: Towards Jena 2.10.0
Posted by Andy Seaborne <an...@apache.org>.
On 06/01/13 20:10, Claude Warren wrote:
> I think that taking 2.10.0 as a good start. I would still like to
> change some of the test directories as we have discussed (e.g. move
> .../model/test into .../model) That, I think, can wait until 2.11
Right - I'd like to make the change as well. I'm OK with large-scale
structural changes to the test structure at any point because it is not
something application code relies on.
The main possibility is other graph implementations and we can work
directly with those people. I'm sure once it's in principle package
renaming to de-/test we can do that pre or post 2.10.
I don't what people prefer - batch as much together or roll out
significant changes over several (close together) releases. When on the
receiving end, I prefer all together in one change.
Andy
Re: Towards Jena 2.10.0
Posted by Claude Warren <cl...@xenei.com>.
I think that taking 2.10.0 as a good start. I would still like to
change some of the test directories as we have discussed (e.g. move
.../model/test into .../model) That, I think, can wait until 2.11
On Sun, Jan 6, 2013 at 7:50 PM, Andy Seaborne <an...@apache.org> 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 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?
>
> 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.)
>
> 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.
>>
>> 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?
>>
>> 4/ Anything else anyone wants to get in?
>>
>> Andy
>
>
--
I like: Like Like - The likeliest place on the web
Identity: https://www.identify.nu/user.php?claude@xenei.com
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: Towards Jena 2.10.0
Posted by Andy Seaborne <an...@apache.org>.
On 09/01/13 18:17, Simon Helsen wrote:
> Thanks Andy,
>
> right now, we are not yet planning to upgrade from 2.7.4. I don't know at
> this point when we'll plan to adopt the next upgrade, but I have to work
> around changed release cycles on our end. Usually, we make the decision
> based on a compelling new feature, but our biggest go/no-go is determined
> by the amount of adoption work by our internal clients. They tend to be
> more conservative and if they fear additional work, they usually want
> something for it. So that is what I have to juggle. The one thing that
> stands out right now in 2.10.0 that relates to our use-cases is the fix
> for aborting bad queries which made it in 2.10.0. But not sure if it is
> enough. I also like to coordinate with another internal group and I still
> have to talk to them about what they think in terms of going to the next
> release
It is a tricky balance between adopting every release, and jumping
across release but with the potential for compounded changes. The costs
of migration will always be there in a later release.
Even aside from adoption of a particular release, there is also the
feedback we could useful use on the changes before they are committed to
a formal release. Before release, migration support is mutable, after a
release, and it's the "new legacy" (a wonderful phrase I came across
recently).
>
> btw, my comment below as intended to be more general, not just my own or
> IBM's interests. Any Jena user benefits from consolidating incompatible
> changes in as few steps as possible
Understood, and I didn't read it as an IBM-only point.
That's why I hope having an up-to-date development build is useful
externally, as well as for the developers, to get poked and prodded so
the consequences (unintended) don't get baked into a release.
Andy
>
> Simon
>
>
>
>
>
> From:
> Andy Seaborne <an...@apache.org>
> To:
> dev@jena.apache.org,
> Date:
> 01/09/2013 08:54 AM
> Subject:
> Re: Towards Jena 2.10.0
>
>
>
> On 08/01/13 19:41, Simon Helsen wrote:
>> 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.
>
> Simon,
>
> The development snapshots now follow the new organisation and have the
> compatibility placeholders. Once a release is done, it becomes the new
> legacy. As it may take you more than one month (elapsed) for internal
> client testing, I strongly suggest starting now.
>
> Andy
>
>
>
>
Re: Towards Jena 2.10.0
Posted by Simon Helsen <sh...@ca.ibm.com>.
Thanks Andy,
right now, we are not yet planning to upgrade from 2.7.4. I don't know at
this point when we'll plan to adopt the next upgrade, but I have to work
around changed release cycles on our end. Usually, we make the decision
based on a compelling new feature, but our biggest go/no-go is determined
by the amount of adoption work by our internal clients. They tend to be
more conservative and if they fear additional work, they usually want
something for it. So that is what I have to juggle. The one thing that
stands out right now in 2.10.0 that relates to our use-cases is the fix
for aborting bad queries which made it in 2.10.0. But not sure if it is
enough. I also like to coordinate with another internal group and I still
have to talk to them about what they think in terms of going to the next
release
btw, my comment below as intended to be more general, not just my own or
IBM's interests. Any Jena user benefits from consolidating incompatible
changes in as few steps as possible
Simon
From:
Andy Seaborne <an...@apache.org>
To:
dev@jena.apache.org,
Date:
01/09/2013 08:54 AM
Subject:
Re: Towards Jena 2.10.0
On 08/01/13 19:41, Simon Helsen wrote:
> 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.
Simon,
The development snapshots now follow the new organisation and have the
compatibility placeholders. Once a release is done, it becomes the new
legacy. As it may take you more than one month (elapsed) for internal
client testing, I strongly suggest starting now.
Andy
Re: Towards Jena 2.10.0
Posted by Andy Seaborne <an...@apache.org>.
On 08/01/13 19:41, Simon Helsen wrote:
> 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.
Simon,
The development snapshots now follow the new organisation and have the
compatibility placeholders. Once a release is done, it becomes the new
legacy. As it may take you more than one month (elapsed) for internal
client testing, I strongly suggest starting now.
Andy
Re: Towards Jena 2.10.0
Posted by Simon Helsen <sh...@ca.ibm.com>.
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 <rv...@yarcdata.com>
To:
"dev@jena.apache.org" <de...@jena.apache.org>,
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" <sa...@apache.org> wrote:
>On Sun, Jan 6, 2013 at 2:50 PM, Andy Seaborne <an...@apache.org> 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
>>
Re: Streaming [was: Towards Jena 2.10.0]
Posted by Stephen Allen <sa...@apache.org>.
On Tue, Jan 8, 2013 at 2:24 PM, Andy Seaborne <an...@apache.org> wrote:
> On 08/01/13 10:41, Andy Seaborne wrote:
>>>>>
>>>>> 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.
>>
>>
>> Stephen - I quite understand about time and lack of. I'll try to take a
>> look at the parser in the branches/streaming-update and update it for
>> 2.10.0-SNAPSHOT but I'm work-projected-out ATM. I don't think the
>> syntax fundamentally is at odds with ordered output; it "just" be a
>> matter of poking javacc hard enough.
>>
>> Andy
>
>
> Integration with 2.10.0 trunk done - I used Eclipse to integrate just ARQ,
> then checked out the whole branch and merged from trunk into the branch.
> Only one merge conflict (UpdateWriter) which I think was something left over
> from the partial merge from the patch. Hard to check but one test failure
> (jena-arq/testing/ARQ/Serialization/syntax-forms-01.rq) which is to be
> expected as it is ()/[] dependent.
>
Great, thanks for doing that. That is indeed the test that fails
because of the mixed up parsing of () and [].
-Stephen
Re: Streaming [was: Towards Jena 2.10.0]
Posted by Andy Seaborne <an...@apache.org>.
On 08/01/13 10:41, Andy Seaborne wrote:
>>>> 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.
>
> Stephen - I quite understand about time and lack of. I'll try to take a
> look at the parser in the branches/streaming-update and update it for
> 2.10.0-SNAPSHOT but I'm work-projected-out ATM. I don't think the
> syntax fundamentally is at odds with ordered output; it "just" be a
> matter of poking javacc hard enough.
>
> Andy
Integration with 2.10.0 trunk done - I used Eclipse to integrate just
ARQ, then checked out the whole branch and merged from trunk into the
branch. Only one merge conflict (UpdateWriter) which I think was
something left over from the partial merge from the patch. Hard to
check but one test failure
(jena-arq/testing/ARQ/Serialization/syntax-forms-01.rq) which is to be
expected as it is ()/[] dependent.
Andy
Streaming [was: Towards Jena 2.10.0]
Posted by Andy Seaborne <an...@apache.org>.
>>> 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.
Stephen - I quite understand about time and lack of. I'll try to take a
look at the parser in the branches/streaming-update and update it for
2.10.0-SNAPSHOT but I'm work-projected-out ATM. I don't think the
syntax fundamentally is at odds with ordered output; it "just" be a
matter of poking javacc hard enough.
Andy
Re: Towards Jena 2.10.0
Posted by Andy Seaborne <an...@apache.org>.
On 08/01/13 19:04, Rob Vesse wrote:
> +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
To me, there isn't a great deal of value to a single repacked jar when
using maven. It's for the zip download and commands.
For maven, its having a single dependency (with sources of everything).
For the DL, it'll have to be all in the lib/ anyway.
For commands, a single uber jar is convenient, but we do provide scripts.
The best target might be to put in fixed maven dependencies that
separate the delivery artifacts from the development structure.
e.g. An apache-jena-maven dependency whose sole job is to depend on the
current state of the development structure. At the moment, it would
need a <type>pom</type> IIUC as the default is jar. An empty jar may
cause questions!
The current apache-jena is close but for the assembly needs to depend on
sources and javadoc.
I think I'd like to repurpose the current "apache-jena" and use it for
the maven fixed point, then have "apache-jena-system" for the download.
Not clear-cut with pros and cons of doing that.
The file names and artifacts have to align (if you set them different,
the upload to a repo changes them! Cause of much puzzlement to me in the
past).
Andy
> On 1/7/13 7:14 PM, "Stephen Allen" <sa...@apache.org> wrote:
>
>> On Sun, Jan 6, 2013 at 2:50 PM, Andy Seaborne <an...@apache.org> 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
>>>
>
Re: Towards Jena 2.10.0
Posted by Rob Vesse <rv...@yarcdata.com>.
+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" <sa...@apache.org> wrote:
>On Sun, Jan 6, 2013 at 2:50 PM, Andy Seaborne <an...@apache.org> 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
>>
Re: Towards Jena 2.10.0
Posted by Stephen Allen <sa...@apache.org>.
On Sun, Jan 6, 2013 at 2:50 PM, Andy Seaborne <an...@apache.org> 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
>
>
Re: Towards Jena 2.10.0
Posted by Andy Seaborne <an...@apache.org>.
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 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?
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.)
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.
>
> 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?
>
> 4/ Anything else anyone wants to get in?
>
> Andy