I'd like to add one comment to this discussion. Oour legal department has to scan the entire source code of the bits we include in our product before we ship. Since we do not need/use all jars, we only package some of them and have those reviewed to reduce the time to adopt (and reduce the considerable cost for a review). In other words, it would help if not everything is thrown together
Simon From: Dave Reynolds <[email protected]> To: [email protected] Date: 09/08/2011 06:01 AM Subject: Re: Jena build (some thoughts) On Tue, 2011-09-06 at 13:06 +0100, Andy Seaborne wrote: [Great set of thoughts.] > == Goals [snip] > + A single download zip file for using Jena as a library > > + A single jar file for using Jena as a library +1 for goals overall and for the notion of a single jar. I'd like (as in, I would put work into this) to also have osgi support. Suggest: o the jena-one-jar would also be marked as an OSGI bundle (easy to do via maven bundle plugin) o a third top level download, jena-complete, which is the jena-one-jar plus dependent jars (i.e. xerces, slf4j/log4j etc) packaged as an single jar/OSGI bundle. The latter is not *necessary* for OSGi support but the way we/I currently work with OSGi makes it easier to have reasonably chunky self-contained bundles than do the fine grain dependency management at the OSGi level. This can also be used via "java -jar jena-complete.jar ..." to run any of the command line utilities which would save some support list load on classpath advice :) > == Possible build layout. OK with going for maven multi-module project structure. Given comments on the "Build experiments" thread I wonder if we a want sub-project structure as well. A possible structure might be: Jena sub-project modules JenaSys IRI Atlas RIOT ARQ TDB? Jena (one jar and zip) - just for building integrated artefact JenaComplete - just for building integrated artefact Website sub-project SDB sub-project Fuseki sub-project Eyeball sub-project So sub projects can be independently checked out and the Jena sub-project can then be hierarchical. If we went the sub-project route then it might make sense to have TDB as a separate sub-project as well since that is under more active development. Depends partly on whether we feel TDB should be part of jena-one-jar or separate (I noted your "maybe?" on that, have no settled view myself). > === Questions and notes. > > 1/ We currently make some attempt to deliver the test suite in the zip > so people can locally run it to check an installation. From memory, the > only thing this seems to catch is problems running the test suite, not > problems with installation. Maybe it's not worth the effort. Not worth the effort. > 3/ For RDB, I propose creating a maven module and putting the code here > with a dependency of whatever version of Jena it is at the time then > leaving it frozen. Alternatively, zip up the code and dump somewhere in > case anyone wants to port it. Prefer former (create module then leave frozen) but OK with either. > 4/ Shall we leave the documentation out of the build and just have it on > the website? Yes, except for some minimal "getting started" documentation in the zip that references the website for details. > 5/ Jump to maven 3? If that risks any increase in maven/m2e unpredictability then no :) but I've no knowledge of what the specific issues might be. Dave
