db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean T. Anderson" <...@bristowhill.com>
Subject Re: [doc] DITA-OT in Derby svn
Date Wed, 16 Nov 2005 15:49:10 GMT
Andrew McIntyre wrote:
> On Nov 15, 2005, at 8:13 PM, Jean T. Anderson wrote:
>> Andrew, I don't think we can just commit the entire DITA Open  Toolkit 
>> to the Derby doc repo without doublechecking what the ASF  process 
>> might be.
> Note that I'm planning on checking the ASL-licensed 'bin' zip file  into 
> the repo, and not source files, and as such I was hoping that we  could 
> treat it like a library. Obviously the NOTICE (and possibly  COPYRIGHT) 
> file in the docs tree would need to be updated  accordingly. Ant would 
> expand the zip file at build time, because  there is not currently a way 
> to use the files in the toolkit while  they're still in the jar.

so, it sounds more like you want the ease-of-use of a maven plug-in 
where it's acquired and expanded on demand.

>> The process for handling the two DITA files that were originally at  
>> issue, xsl/dita2fo-shell.xsl and resource/commonltr.css, is simple.
> Right, and I propose that only Jeff's modified dita2fo-shell.xsl into  
> the repository as a source file, the rest of the toolkit as a binary  
> file. The intention is that dita2fo-shell.xsl will be the only file  we 
> would modify.
>> I understood at the time that if we wanted to import an entire  
>> subproject from some other home, Apache has different processes  
>> depending on the size of the import.
>> So, if you want to import the entire DITA Open Toolkit, we need to  
>> check to see what that process is.
> Should I start a thread on legal-discuss? Or would you like to take  the 
> lead on that, since you're on the PMC and have already led  discussions 
> on this topic?

Actually, I suggest first that you check with infrastructure@ (since 
you're already subscribed) to see if they're ok with distribution -- how 
big is the zip file? Is this a case where we should consider using maven 


View raw message