- From: Romain Deltour <rdeltour@gmail.com>
- Date: Wed, 8 Apr 2015 17:32:40 +0200
- To: Norman Walsh <ndw@nwalsh.com>
- Cc: XProc Dev <xproc-dev@w3.org>
Hi Norm, +1 om splitting step libraries in separate repos. As far as I'm concerned it won't negatively impact our integration (on the contrary), as long as dependencies are properly declared, and jars available on Maven and/or easy to build from sources (but with the Gradle magic you recently applied I suppose it will be easy-peasy? :) BTW, have you considered adopting semantic versioning for Calabash ? (semver [1]: major version increases with API breaks, minor version increases with backwards-compatible API additions, patch version increases for internal changes and bug fixes). It can help maintaining sane versioning practices, and surely helps users knowing about API changes between versions. If you're interested, a reorganization of the project can be a good opportunity to adopt semver... Romain. [1] http://semver.org/ > On 7 avr. 2015, at 03:06, Norman Walsh <ndw@nwalsh.com> wrote: > > Hello world, > > The modulization work I did recently makes it pretty easy to bundle > XML Calabash extension steps in separate repositories. Just put all > the relevant jar files on the classpath and you're done. It'll all > "just work". > > I've separated some steps out into separate repositories already: > > * The MarkLogic XCC steps > * The RDF steps > * The DiTAA step (to resolve a weird build issue that I later > discovered was caused by PlantUML including an older version > of the DiTAA classes) > > Those are all extension steps and I'm tempted to break out a few more: > > * cx:metadata-extractor > * cx:send-email > * cx:plantuml > > Those are candidates mostly because they each have further > dependencies so removing them makes the XML Calabash release smaller. > They're also probably not widely used. > > More controversially, perhaps, I'm tempted to break FO processing out > into a separate repository. FOP in particular has a lot of > dependencies; moving it into a separate repo would reduce the size of > the XML Calabash distribution by almost 25%. I'd probably move CSS > processing out as well, just for parity. > > Practically speaking, this would mean that if you didn't also download > the FO jars, you couldn't do FO processing with XML Calabash. (The > p:xsl-formatter step would fail with a class-not-found exception.) > > One could go all the way to the absurd and bundle every step > separately, but that'd clearly be overkill. > > I'd be intersted to hear with users and developers (especially > developers that bundle XML Calabash into other products) think about > the "multiple repos" question. > > Be seeing you, > norm > > -- > Norman Walsh > Lead Engineer > MarkLogic Corporation > Phone: +1 512 761 6676 > www.marklogic.com
Received on Wednesday, 8 April 2015 15:33:10 UTC