[jira] Updated: (DBF-1) Copy images based on type and target
[ https://issues.apache.org/jira/browse/DBF-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Koch updated DBF-1: --- Attachment: (was: imageincludes.patch) > Copy images based on type and target > > > Key: DBF-1 > URL: https://issues.apache.org/jira/browse/DBF-1 > Project: DocBook Framework > Issue Type: Improvement > Environment: Ubuntu Feisty >Reporter: Matthew Koch >Priority: Minor > > I noticed in the DBF documentation that there is a TODO item to not blindly > copy images. Would an acceptable solution be to add an 'includesfile' to the > fileset for the copy task for images based on the target (and if desirable on > the type)? For example, for the 'pdf' type of the 'manual' target there > could be a file called manual.pdf.image.includes that would specify which > images to include/exclude. I haven't tested the behavior of the includesfile > attribute much, so it may be necessary to have a default includesfile with > "images/**". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBF-1) Copy images based on type and target
[ https://issues.apache.org/jira/browse/DBF-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Koch updated DBF-1: --- Attachment: default.imageincludes default.imageincludes Update to previous patch. The includes files are now expected to be in the src/docbook/projectname directory with names akin to projectname.html.imageincludes. If the includes file does not exist, then a default.imageincludes is used from the dbf base directory. > Copy images based on type and target > > > Key: DBF-1 > URL: https://issues.apache.org/jira/browse/DBF-1 > Project: DocBook Framework > Issue Type: Improvement > Environment: Ubuntu Feisty >Reporter: Matthew Koch >Priority: Minor > Attachments: default.imageincludes, default.imageincludes > > > I noticed in the DBF documentation that there is a TODO item to not blindly > copy images. Would an acceptable solution be to add an 'includesfile' to the > fileset for the copy task for images based on the target (and if desirable on > the type)? For example, for the 'pdf' type of the 'manual' target there > could be a file called manual.pdf.image.includes that would specify which > images to include/exclude. I haven't tested the behavior of the includesfile > attribute much, so it may be necessary to have a default includesfile with > "images/**". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBF-1) Copy images based on type and target
[ https://issues.apache.org/jira/browse/DBF-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Koch updated DBF-1: --- Attachment: (was: default.imageincludes) > Copy images based on type and target > > > Key: DBF-1 > URL: https://issues.apache.org/jira/browse/DBF-1 > Project: DocBook Framework > Issue Type: Improvement > Environment: Ubuntu Feisty >Reporter: Matthew Koch >Priority: Minor > Attachments: default.imageincludes, imageincludes.patch > > > I noticed in the DBF documentation that there is a TODO item to not blindly > copy images. Would an acceptable solution be to add an 'includesfile' to the > fileset for the copy task for images based on the target (and if desirable on > the type)? For example, for the 'pdf' type of the 'manual' target there > could be a file called manual.pdf.image.includes that would specify which > images to include/exclude. I haven't tested the behavior of the includesfile > attribute much, so it may be necessary to have a default includesfile with > "images/**". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBF-1) Copy images based on type and target
[ https://issues.apache.org/jira/browse/DBF-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Koch updated DBF-1: --- Attachment: imageincludes.patch oops, attached wrong file... > Copy images based on type and target > > > Key: DBF-1 > URL: https://issues.apache.org/jira/browse/DBF-1 > Project: DocBook Framework > Issue Type: Improvement > Environment: Ubuntu Feisty >Reporter: Matthew Koch >Priority: Minor > Attachments: default.imageincludes, imageincludes.patch > > > I noticed in the DBF documentation that there is a TODO item to not blindly > copy images. Would an acceptable solution be to add an 'includesfile' to the > fileset for the copy task for images based on the target (and if desirable on > the type)? For example, for the 'pdf' type of the 'manual' target there > could be a file called manual.pdf.image.includes that would specify which > images to include/exclude. I haven't tested the behavior of the includesfile > attribute much, so it may be necessary to have a default includesfile with > "images/**". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Table creation helper package for Velocity?
Hi, thanks a lot for the quick responses! > I haven't actually seen anyone do this sort of thing. At least, i > don't recall anyone contributing it. This would be a good thing to > have up on our Wiki somewhere (perhaps under CommunityArticles and > ContributedCode. Yes, the CommunityArticles and ContributedCode sections look promising to me as well. I'll try to get something done soon. I'm not as sure where the VelocityInteractor would fit, but i would be curious to see/know more about what it does. In recent months, i've been mulling over the possibility of a new project (or new package in the core project) to provide super-easy-to-use wrappers around the Velocity runtime that are pre-configured (or much more easily and specifically configured) and enhanced for particular Velocity tasks (e.g. like a VelocityEmailer). It's still just a thought at this point, but a glance at how you're using it makes it look like the VelocityInteractor could be a such a thing or at least a seed for such things. I have attached the source code for the VelocityInteractor. It's not rocket science, just a wrapper that I found useful for handling many different VelocityContexts and Templates. Maybe you also find it useful. Feel free to use or modify. Thanks, Matthias P.S.: I noticed that the mailing list archive seems to discard attachments, at least I can't see the attachment from my previous posting in the web interface. Let me know if I should resend it directly. /* * VelocityException.java * * Created on 6. August 2007, 09:00 * * To change this template, choose Tools | Template Manager * and open the template in the editor. */ /** * * @author i000698 */ public class VelocityException extends Exception { /** * Constructs a new VelocityException exception with null as its * detail message. The cause is not initialized, and may subsequently be * initialized by a call to [EMAIL PROTECTED] #initCause}. */ public VelocityException() { super(); } /** * Constructs a new VelocityException exception with the specified detail message. * The cause is not initialized, and may subsequently be initialized by a * call to [EMAIL PROTECTED] #initCause}. * * * @param message the detail message. The detail message is saved for * later retrieval by the [EMAIL PROTECTED] #getMessage()} method. */ public VelocityException(String message) { super(message); } /** * Constructs a new VelocityException exception with the specified detail message and * cause. Note that the detail message associated with * cause is not automatically incorporated in * this VelocityException exception's detail message. * * * @param message the detail message (which is saved for later retrieval * by the [EMAIL PROTECTED] #getMessage()} method). * @param cause the cause (which is saved for later retrieval by the * [EMAIL PROTECTED] #getCause()} method). (A null value is * permitted, and indicates that the cause is nonexistent or * unknown.) */ public VelocityException(String message, Throwable cause) { super(message, cause); } /** * Constructs a new VelocityException exception with the specified cause and a * detail message of (cause==null ? null : cause.toString()) * (which typically contains the class and detail message of * cause). This constructor is useful for VelocityException exceptions * that are little more than wrappers for other throwables. * * * @param cause the cause (which is saved for later retrieval by the * [EMAIL PROTECTED] #getCause()} method). (A null value is * permitted, and indicates that the cause is nonexistent or * unknown.) */ public VelocityException(Throwable cause) { super(cause); } } import java.io.Writer; import java.util.HashMap; import java.util.Map; import org.apache.velocity.Template; import org.apache.velocity.VelocityContext; import org.apache.velocity.app.Velocity; import org.apache.velocity.exception.MethodInvocationException; import org.apache.velocity.exception.ParseErrorException; import org.apache.velocity.exception.ResourceNotFoundException; import org.apache.velocity.runtime.RuntimeConstants; /** * A helper class to encapsulate the interaction with the Velocity template engine */ public class VelocityInteractor { private static final String ENCODING = "ISO-8859-1"; private Map contexts = new HashMap(); private Maptemplates= new HashMap(); private MapdefaultTemplates = new HashMap(); private VelocityContext defaultContext = new VelocityContext(); private TemplatedefaultTemplate = null; /** * Create a new interactor instance * * Setup the search path for velocity: first, relative ot the local * directory (".") and
[jira] Updated: (DBF-1) Copy images based on type and target
[ https://issues.apache.org/jira/browse/DBF-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Koch updated DBF-1: --- Attachment: (was: imageincludes.patch) > Copy images based on type and target > > > Key: DBF-1 > URL: https://issues.apache.org/jira/browse/DBF-1 > Project: DocBook Framework > Issue Type: Improvement > Environment: Ubuntu Feisty >Reporter: Matthew Koch >Priority: Minor > > I noticed in the DBF documentation that there is a TODO item to not blindly > copy images. Would an acceptable solution be to add an 'includesfile' to the > fileset for the copy task for images based on the target (and if desirable on > the type)? For example, for the 'pdf' type of the 'manual' target there > could be a file called manual.pdf.image.includes that would specify which > images to include/exclude. I haven't tested the behavior of the includesfile > attribute much, so it may be necessary to have a default includesfile with > "images/**". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBF-1) Copy images based on type and target
[ https://issues.apache.org/jira/browse/DBF-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Koch updated DBF-1: --- Attachment: (was: default.imageincludes) > Copy images based on type and target > > > Key: DBF-1 > URL: https://issues.apache.org/jira/browse/DBF-1 > Project: DocBook Framework > Issue Type: Improvement > Environment: Ubuntu Feisty >Reporter: Matthew Koch >Priority: Minor > > I noticed in the DBF documentation that there is a TODO item to not blindly > copy images. Would an acceptable solution be to add an 'includesfile' to the > fileset for the copy task for images based on the target (and if desirable on > the type)? For example, for the 'pdf' type of the 'manual' target there > could be a file called manual.pdf.image.includes that would specify which > images to include/exclude. I haven't tested the behavior of the includesfile > attribute much, so it may be necessary to have a default includesfile with > "images/**". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBF-1) Copy images based on type and target
[ https://issues.apache.org/jira/browse/DBF-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Koch updated DBF-1: --- Attachment: imageincludes.patch default.imageincludes Real uploads this time. doh... > Copy images based on type and target > > > Key: DBF-1 > URL: https://issues.apache.org/jira/browse/DBF-1 > Project: DocBook Framework > Issue Type: Improvement > Environment: Ubuntu Feisty >Reporter: Matthew Koch >Priority: Minor > Attachments: default.imageincludes, imageincludes.patch > > > I noticed in the DBF documentation that there is a TODO item to not blindly > copy images. Would an acceptable solution be to add an 'includesfile' to the > fileset for the copy task for images based on the target (and if desirable on > the type)? For example, for the 'pdf' type of the 'manual' target there > could be a file called manual.pdf.image.includes that would specify which > images to include/exclude. I haven't tested the behavior of the includesfile > attribute much, so it may be necessary to have a default includesfile with > "images/**". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]