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" <[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.+1Things 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
