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 > >
