W3C home > Mailing lists > Public > xproc-dev@w3.org > April 2015

Re: How many repos?

From: James Fuller <james.fuller.2007@gmail.com>
Date: Tue, 7 Apr 2015 10:35:58 +0200
Message-ID: <CADsXk-Y1Nonn4TOhSxvD7UUNcLgyzBs+riPt-zOTNhzSweQmpg@mail.gmail.com>
To: Conal Tuohy <conal.tuohy@gmail.com>
Cc: Norman Walsh <ndw@nwalsh.com>, XProc Dev <xproc-dev@w3.org>
unsurprisingly I too also agree its a good idea to provide separate jars
with related step libs.

I think the only developer facing issue to be concerned about is ensuring
dependency analysis all works in terms of older/newer versions of calabash
and potentially different versions of any particular step lib jar.

J


On Tue, Apr 7, 2015 at 10:19 AM, Conal Tuohy <conal.tuohy@gmail.com> wrote:

> It makes sense to me to bundle each set of extension steps with common
> external dependencies into a jar of its own.
>
> I don't see any problem with proliferating jars, personally.
>
>
>
>
> On 7 April 2015 at 11: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 Tuesday, 7 April 2015 08:36:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 7 April 2015 08:36:26 UTC