Re: docbook + maven
If you look at the code and projects using it, yes, I am aware of this. Or did you miss the directories containing the font definitios tongue-in-cheekly named no-idea-what-to-do-with-these-yet? ;) Actually I was leaning on the expertise of the Red Hat documentation team here, since DocBook (nor xslt, really) is not my forte. I have yet to breach this particular topic with them. If you have a particular need/requirement, well, patches welcome ;) On Thu, 2007-06-07 at 13:15 +0200, Tamás Cservenák wrote: Hello, I had another problem with docbook plugins for maven2. I will just describe it, as it is too often overseen :) My problem was FOP and it's configuration in docbkx plugin. I needed docbook in maven2 to generate docs in Hungarian language. The FOP per default produces PDF with Adobe Default font set (16 fonts) and with all of them in LATIN1 encoding, which is not enough for Eastern European languages. The resolution is to introduce different fonts beside defaults to FOP. See: http://xmlgraphics.apache.org/fop/0.20.5/fonts.html#register Just a thought, since as i read your code, you do the similar thing as docbkx: http://anonsvn.jboss.org/repos/hibernate/trunk/sandbox/maven-poc/plugins/maven-jboss-docbook-plugin/src/main/java/org/jboss/maven/plugin/docbook/gen/render/PdfRenderer.java http://docbkx-tools.googlecode.com/svn/trunk/docbkx-maven-plugin/src/main/java/com/agilejava/docbkx/maven/AbstractPdfMojo.java The configuration customization for FOP is unreachable in both cases, thus it both would renders unusable PDFs in non-LATIN1 environments. The solution would be to make FOP configuration reachable from maven config, or at least create a possibility to direct the FOP to use some specific config-file from within the project. Btw, the docbkx project moved from agilejava.com to http://code.google.com/p/docbkx-tools/ Cheers, ~t~ On 6/4/07, Steve Ebersole [EMAIL PROTECTED] wrote: As part of migrating Hibernate to use Maven, one of the big issues I ran into was the current state of DocBook plugins for Maven. The current mojo-codehaus hosted plugin is insufficient. There is another more widely used one done by one Wilfred Springer as part of something called agilejava. The agilejava one is fairly full featured, but is really pretty bare bones in terms of configuration (its is mainly a simplistic wrapper around the defined DocBook xslt parameters). In my estimation the, agilejava one was closer to usability, but Mr. Springer did not seem interested in accepting my volunteer to help improve his plugin. So I began implementing my own. It works off of a slightly different approach than the other two. The biggest difference being that custom stylesheets are packaged as separate projects and included via the Maven dependency mechanism. This allows true reuse of the stylesheets across projects. The other is planned better support of translations which is important for Hibernate, and most projects using DocBook. This however led to a conceptual question regarding how to best handle image references. As background, in DocBook, the way images normally get resolved is as via xslt templates. The DocBook supplied templates do a hard file lookup relative to a xslt parameter named 'img.src.path' if it is set; and really this is format specific as well. Regardless, though, I need a mechanism to access the image files from these style projects and be able to resolve reference to them from the DocBook source or xsl stylesheets. I have identified a few potential approaches to achieve that: 1) force separation of (a) xslt and (b) resources like images/css into separate projects. Specifically, #b would need a custom packaging which would allow me to find resources and unarchive them locally into a staging dir for use in 'img.src.path'. A variation on this would be to bundle them together with a custom packaging and somehow extract just the resources. 2) Apply custom graphics resolution templates to the built xsl transformers, hoping that the custom xslt does not itself do this. I'm not (necessarily) looking for volunteers (although certainly that is welcome). More I just need people's thoughts on the various approaches, especially those using or familiar with DocBook. Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: docbook + maven
On 6/6/07, Steve Ebersole [EMAIL PROTECTED] wrote: I am not overly familiar with this dependency plugin, but the overall approach sounds essentially the same as I described in my staging approach. The concern I had was knowing which dependencies to pull resources from. I would then guess that this dependency plugin you mention requires you to explicitly state the coordinate to be unpacked; essentially doubling the config? Not sure I follow. I just make sure that when unzipped, the style goes in the right directory. See dependency:unpack [1] I am not overly familiar with 'xmlto' other than the fact it exists ;) From my understanding, it is an xslt framework, right? I just use SAXON inline with the plugin using a Transformer built based on the configuration, project, etc. The only drawback I have seen is the fact that SAXON eats large amounts of memory. Right. That's why I'm interested by a solution more integrated with Maven. I'll try this solution short term, probably today. Thanks, Stéphane [1] http://maven.apache.org/plugins/maven-dependency-plugin/examples/unpacking-artifacts.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: docbook + maven
Hello, I had another problem with docbook plugins for maven2. I will just describe it, as it is too often overseen :) My problem was FOP and it's configuration in docbkx plugin. I needed docbook in maven2 to generate docs in Hungarian language. The FOP per default produces PDF with Adobe Default font set (16 fonts) and with all of them in LATIN1 encoding, which is not enough for Eastern European languages. The resolution is to introduce different fonts beside defaults to FOP. See: http://xmlgraphics.apache.org/fop/0.20.5/fonts.html#register Just a thought, since as i read your code, you do the similar thing as docbkx: http://anonsvn.jboss.org/repos/hibernate/trunk/sandbox/maven-poc/plugins/maven-jboss-docbook-plugin/src/main/java/org/jboss/maven/plugin/docbook/gen/render/PdfRenderer.java http://docbkx-tools.googlecode.com/svn/trunk/docbkx-maven-plugin/src/main/java/com/agilejava/docbkx/maven/AbstractPdfMojo.java The configuration customization for FOP is unreachable in both cases, thus it both would renders unusable PDFs in non-LATIN1 environments. The solution would be to make FOP configuration reachable from maven config, or at least create a possibility to direct the FOP to use some specific config-file from within the project. Btw, the docbkx project moved from agilejava.com to http://code.google.com/p/docbkx-tools/ Cheers, ~t~ On 6/4/07, Steve Ebersole [EMAIL PROTECTED] wrote: As part of migrating Hibernate to use Maven, one of the big issues I ran into was the current state of DocBook plugins for Maven. The current mojo-codehaus hosted plugin is insufficient. There is another more widely used one done by one Wilfred Springer as part of something called agilejava. The agilejava one is fairly full featured, but is really pretty bare bones in terms of configuration (its is mainly a simplistic wrapper around the defined DocBook xslt parameters). In my estimation the, agilejava one was closer to usability, but Mr. Springer did not seem interested in accepting my volunteer to help improve his plugin. So I began implementing my own. It works off of a slightly different approach than the other two. The biggest difference being that custom stylesheets are packaged as separate projects and included via the Maven dependency mechanism. This allows true reuse of the stylesheets across projects. The other is planned better support of translations which is important for Hibernate, and most projects using DocBook. This however led to a conceptual question regarding how to best handle image references. As background, in DocBook, the way images normally get resolved is as via xslt templates. The DocBook supplied templates do a hard file lookup relative to a xslt parameter named 'img.src.path' if it is set; and really this is format specific as well. Regardless, though, I need a mechanism to access the image files from these style projects and be able to resolve reference to them from the DocBook source or xsl stylesheets. I have identified a few potential approaches to achieve that: 1) force separation of (a) xslt and (b) resources like images/css into separate projects. Specifically, #b would need a custom packaging which would allow me to find resources and unarchive them locally into a staging dir for use in 'img.src.path'. A variation on this would be to bundle them together with a custom packaging and somehow extract just the resources. 2) Apply custom graphics resolution templates to the built xsl transformers, hoping that the custom xslt does not itself do this. I'm not (necessarily) looking for volunteers (although certainly that is welcome). More I just need people's thoughts on the various approaches, especially those using or familiar with DocBook. Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: docbook + maven
Hey,
On 6/5/07, Steve Ebersole [EMAIL PROTECTED] wrote:
On Tue, 2007-06-05 at 09:18 +0200, Stephane Nicoll wrote:
I am currently migration our doc on docbook+M2 and I ran in the same
issues. Is your plugin freely available?
Sure, as of now it is in Hibernate SVN and published to the JBoss Maven repo.
Cool, will try.
Regarding styles, we also use them as dependencies and images are
located alongside the docbook file.
Images alongside the DocBook source is fine for images referenced from
those sources; that makes sense. But I am talking about images packaged
with the styles. Remember, the whole point is to have reusable xslt
bundles.
Sure. What we do is we package the styles in a zip file using a
standard maven project and the build-helper-mojo from codehaus. The
zip file contains not only the CSS, the XSLT parameters but also the
images linked to the style.
Next, in a doc project, we depend on the zip above and we use the
dependency plugin to inject the data (dependency:unpack) in the
target/${artifactId} directory where the docb sources are copied.
Now, we have a hard dependency on xmlto for the actual generation. If
we can use a more elegant solution, I'll be glad to test :)
Thanks,
Stéphane
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: docbook + maven
Sure. What we do is we package the styles in a zip file using a
standard maven project and the build-helper-mojo from codehaus. The
zip file contains not only the CSS, the XSLT parameters but also the
images linked to the style.
Next, in a doc project, we depend on the zip above and we use the
dependency plugin to inject the data (dependency:unpack) in the
target/${artifactId} directory where the docb sources are copied.
I am not overly familiar with this dependency plugin, but the overall
approach sounds essentially the same as I described in my staging
approach. The concern I had was knowing which dependencies to pull
resources from. I would then guess that this dependency plugin you
mention requires you to explicitly state the coordinate to be unpacked;
essentially doubling the config?
Now, we have a hard dependency on xmlto for the actual generation. If
we can use a more elegant solution, I'll be glad to test :)
I am not overly familiar with 'xmlto' other than the fact it exists ;)
From my understanding, it is an xslt framework, right? I just use SAXON
inline with the plugin using a Transformer built based on the
configuration, project, etc. The only drawback I have seen is the fact
that SAXON eats large amounts of memory.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: docbook + maven
I am currently migration our doc on docbook+M2 and I ran in the same issues. Is your plugin freely available? Regarding styles, we also use them as dependencies and images are located alongside the docbook file. Thanks, Stéphane On 6/4/07, Steve Ebersole [EMAIL PROTECTED] wrote: As part of migrating Hibernate to use Maven, one of the big issues I ran into was the current state of DocBook plugins for Maven. The current mojo-codehaus hosted plugin is insufficient. There is another more widely used one done by one Wilfred Springer as part of something called agilejava. The agilejava one is fairly full featured, but is really pretty bare bones in terms of configuration (its is mainly a simplistic wrapper around the defined DocBook xslt parameters). In my estimation the, agilejava one was closer to usability, but Mr. Springer did not seem interested in accepting my volunteer to help improve his plugin. So I began implementing my own. It works off of a slightly different approach than the other two. The biggest difference being that custom stylesheets are packaged as separate projects and included via the Maven dependency mechanism. This allows true reuse of the stylesheets across projects. The other is planned better support of translations which is important for Hibernate, and most projects using DocBook. This however led to a conceptual question regarding how to best handle image references. As background, in DocBook, the way images normally get resolved is as via xslt templates. The DocBook supplied templates do a hard file lookup relative to a xslt parameter named 'img.src.path' if it is set; and really this is format specific as well. Regardless, though, I need a mechanism to access the image files from these style projects and be able to resolve reference to them from the DocBook source or xsl stylesheets. I have identified a few potential approaches to achieve that: 1) force separation of (a) xslt and (b) resources like images/css into separate projects. Specifically, #b would need a custom packaging which would allow me to find resources and unarchive them locally into a staging dir for use in 'img.src.path'. A variation on this would be to bundle them together with a custom packaging and somehow extract just the resources. 2) Apply custom graphics resolution templates to the built xsl transformers, hoping that the custom xslt does not itself do this. I'm not (necessarily) looking for volunteers (although certainly that is welcome). More I just need people's thoughts on the various approaches, especially those using or familiar with DocBook. Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: docbook + maven
On Tue, 2007-06-05 at 09:18 +0200, Stephane Nicoll wrote: I am currently migration our doc on docbook+M2 and I ran in the same issues. Is your plugin freely available? Sure, as of now it is in Hibernate SVN and published to the JBoss Maven repo. Regarding styles, we also use them as dependencies and images are located alongside the docbook file. Images alongside the DocBook source is fine for images referenced from those sources; that makes sense. But I am talking about images packaged with the styles. Remember, the whole point is to have reusable xslt bundles. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [hibernate-dev] docbook + maven
one thing is for sure, the current image location in our docbook is annoying ;( It is not relative to where the xml files are and hence it does not show up in e.g. xmlmind. What makes most sense to me is that the images is located relative/correctly based on the actual xml they are referred in. I know Marc Proctor solved this (at least he claims so) - but I don't know how so I cc'ed him in ;) /max As part of migrating Hibernate to use Maven, one of the big issues I ran into was the current state of DocBook plugins for Maven. The current mojo-codehaus hosted plugin is insufficient. There is another more widely used one done by one Wilfred Springer as part of something called agilejava. The agilejava one is fairly full featured, but is really pretty bare bones in terms of configuration (its is mainly a simplistic wrapper around the defined DocBook xslt parameters). In my estimation the, agilejava one was closer to usability, but Mr. Springer did not seem interested in accepting my volunteer to help improve his plugin. So I began implementing my own. It works off of a slightly different approach than the other two. The biggest difference being that custom stylesheets are packaged as separate projects and included via the Maven dependency mechanism. This allows true reuse of the stylesheets across projects. The other is planned better support of translations which is important for Hibernate, and most projects using DocBook. This however led to a conceptual question regarding how to best handle image references. As background, in DocBook, the way images normally get resolved is as via xslt templates. The DocBook supplied templates do a hard file lookup relative to a xslt parameter named 'img.src.path' if it is set; and really this is format specific as well. Regardless, though, I need a mechanism to access the image files from these style projects and be able to resolve reference to them from the DocBook source or xsl stylesheets. I have identified a few potential approaches to achieve that: 1) force separation of (a) xslt and (b) resources like images/css into separate projects. Specifically, #b would need a custom packaging which would allow me to find resources and unarchive them locally into a staging dir for use in 'img.src.path'. A variation on this would be to bundle them together with a custom packaging and somehow extract just the resources. 2) Apply custom graphics resolution templates to the built xsl transformers, hoping that the custom xslt does not itself do this. I'm not (necessarily) looking for volunteers (although certainly that is welcome). More I just need people's thoughts on the various approaches, especially those using or familiar with DocBook. Thanks, Steve ___ hibernate-dev mailing list [EMAIL PROTECTED] https://lists.jboss.org/mailman/listinfo/hibernate-dev -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss a division of Red Hat [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
docbook + maven
As part of migrating Hibernate to use Maven, one of the big issues I ran into was the current state of DocBook plugins for Maven. The current mojo-codehaus hosted plugin is insufficient. There is another more widely used one done by one Wilfred Springer as part of something called agilejava. The agilejava one is fairly full featured, but is really pretty bare bones in terms of configuration (its is mainly a simplistic wrapper around the defined DocBook xslt parameters). In my estimation the, agilejava one was closer to usability, but Mr. Springer did not seem interested in accepting my volunteer to help improve his plugin. So I began implementing my own. It works off of a slightly different approach than the other two. The biggest difference being that custom stylesheets are packaged as separate projects and included via the Maven dependency mechanism. This allows true reuse of the stylesheets across projects. The other is planned better support of translations which is important for Hibernate, and most projects using DocBook. This however led to a conceptual question regarding how to best handle image references. As background, in DocBook, the way images normally get resolved is as via xslt templates. The DocBook supplied templates do a hard file lookup relative to a xslt parameter named 'img.src.path' if it is set; and really this is format specific as well. Regardless, though, I need a mechanism to access the image files from these style projects and be able to resolve reference to them from the DocBook source or xsl stylesheets. I have identified a few potential approaches to achieve that: 1) force separation of (a) xslt and (b) resources like images/css into separate projects. Specifically, #b would need a custom packaging which would allow me to find resources and unarchive them locally into a staging dir for use in 'img.src.path'. A variation on this would be to bundle them together with a custom packaging and somehow extract just the resources. 2) Apply custom graphics resolution templates to the built xsl transformers, hoping that the custom xslt does not itself do this. I'm not (necessarily) looking for volunteers (although certainly that is welcome). More I just need people's thoughts on the various approaches, especially those using or familiar with DocBook. Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [hibernate-dev] docbook + maven
yes I raised that with steve, after being abused for some time, I think I eventually persuaded him to include the properties necessary for this. Mark Max Rydahl Andersen wrote: one thing is for sure, the current image location in our docbook is annoying ;( It is not relative to where the xml files are and hence it does not show up in e.g. xmlmind. What makes most sense to me is that the images is located relative/correctly based on the actual xml they are referred in. I know Marc Proctor solved this (at least he claims so) - but I don't know how so I cc'ed him in ;) /max As part of migrating Hibernate to use Maven, one of the big issues I ran into was the current state of DocBook plugins for Maven. The current mojo-codehaus hosted plugin is insufficient. There is another more widely used one done by one Wilfred Springer as part of something called agilejava. The agilejava one is fairly full featured, but is really pretty bare bones in terms of configuration (its is mainly a simplistic wrapper around the defined DocBook xslt parameters). In my estimation the, agilejava one was closer to usability, but Mr. Springer did not seem interested in accepting my volunteer to help improve his plugin. So I began implementing my own. It works off of a slightly different approach than the other two. The biggest difference being that custom stylesheets are packaged as separate projects and included via the Maven dependency mechanism. This allows true reuse of the stylesheets across projects. The other is planned better support of translations which is important for Hibernate, and most projects using DocBook. This however led to a conceptual question regarding how to best handle image references. As background, in DocBook, the way images normally get resolved is as via xslt templates. The DocBook supplied templates do a hard file lookup relative to a xslt parameter named 'img.src.path' if it is set; and really this is format specific as well. Regardless, though, I need a mechanism to access the image files from these style projects and be able to resolve reference to them from the DocBook source or xsl stylesheets. I have identified a few potential approaches to achieve that: 1) force separation of (a) xslt and (b) resources like images/css into separate projects. Specifically, #b would need a custom packaging which would allow me to find resources and unarchive them locally into a staging dir for use in 'img.src.path'. A variation on this would be to bundle them together with a custom packaging and somehow extract just the resources. 2) Apply custom graphics resolution templates to the built xsl transformers, hoping that the custom xslt does not itself do this. I'm not (necessarily) looking for volunteers (although certainly that is welcome). More I just need people's thoughts on the various approaches, especially those using or familiar with DocBook. Thanks, Steve ___ hibernate-dev mailing list [EMAIL PROTECTED] https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [hibernate-dev] docbook + maven
Mark and I already discussed this. But its a different discussion, since he does not deal with pre-packaged styles... On Mon, 2007-06-04 at 21:38 +0200, Max Rydahl Andersen wrote: one thing is for sure, the current image location in our docbook is annoying ;( It is not relative to where the xml files are and hence it does not show up in e.g. xmlmind. What makes most sense to me is that the images is located relative/correctly based on the actual xml they are referred in. I know Marc Proctor solved this (at least he claims so) - but I don't know how so I cc'ed him in ;) /max As part of migrating Hibernate to use Maven, one of the big issues I ran into was the current state of DocBook plugins for Maven. The current mojo-codehaus hosted plugin is insufficient. There is another more widely used one done by one Wilfred Springer as part of something called agilejava. The agilejava one is fairly full featured, but is really pretty bare bones in terms of configuration (its is mainly a simplistic wrapper around the defined DocBook xslt parameters). In my estimation the, agilejava one was closer to usability, but Mr. Springer did not seem interested in accepting my volunteer to help improve his plugin. So I began implementing my own. It works off of a slightly different approach than the other two. The biggest difference being that custom stylesheets are packaged as separate projects and included via the Maven dependency mechanism. This allows true reuse of the stylesheets across projects. The other is planned better support of translations which is important for Hibernate, and most projects using DocBook. This however led to a conceptual question regarding how to best handle image references. As background, in DocBook, the way images normally get resolved is as via xslt templates. The DocBook supplied templates do a hard file lookup relative to a xslt parameter named 'img.src.path' if it is set; and really this is format specific as well. Regardless, though, I need a mechanism to access the image files from these style projects and be able to resolve reference to them from the DocBook source or xsl stylesheets. I have identified a few potential approaches to achieve that: 1) force separation of (a) xslt and (b) resources like images/css into separate projects. Specifically, #b would need a custom packaging which would allow me to find resources and unarchive them locally into a staging dir for use in 'img.src.path'. A variation on this would be to bundle them together with a custom packaging and somehow extract just the resources. 2) Apply custom graphics resolution templates to the built xsl transformers, hoping that the custom xslt does not itself do this. I'm not (necessarily) looking for volunteers (although certainly that is welcome). More I just need people's thoughts on the various approaches, especially those using or familiar with DocBook. Thanks, Steve ___ hibernate-dev mailing list [EMAIL PROTECTED] https://lists.jboss.org/mailman/listinfo/hibernate-dev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DocBook Maven Plugin
: plexus:plexus-root::1.0 for project: plexus:plexus-utils:jar:1.0.1 from the repository. [DEBUG] plexus:plexus-utils:jar:1.0.1:runtime (selected for runtime) [DEBUG] commons-io:commons-io:jar:1.1:runtime (selected for runtime) [DEBUG] saxpath:saxpath:jar:1.0-FCS:runtime (selected for runtime) [DEBUG] Retrieving parent-POM: org.codehaus.plexus:plexus-components::1.1.4 for project: null:plexus-archiver:jar:1.0-alpha-5 from the repository. [DEBUG] Retrieving parent-POM: org.codehaus.plexus:plexus::1.0.4 for project: org.codehaus.plexus:plexus-components:pom:1.1.4 from the repository. [DEBUG] org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-5:runtime (selected for runtime) [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0:runtime (selected for runtime) [DEBUG] Configuring mojo 'com.agilejava.docbkx:docbkx-maven-plugin:1.69.1.0:generate-html' -- [DEBUG] (f) generateToc = /book toc [DEBUG] (f) ignoreImageScaling = 1 [DEBUG] (f) includes = interface-home.xml,progress-report.xml [DEBUG] (f) sectionAutolabel = 1 [DEBUG] (f) sectionLabelIncludesComponentLabel = 1 [DEBUG] (f) sourceDirectory = C:\Documents and Settings\borutb\Desktop\Workspace\feed-index-server\src\docbkx [DEBUG] (f) stylesheetLocation = META-INF/docbkx/html/docbook.xsl [DEBUG] (f) targetDirectory = C:\Documents and Settings\borutb\Desktop\Workspace\feed-index-server\target\docbkx\html [DEBUG] (f) targetFileExtension = html [DEBUG] -- end configuration -- [INFO] [docbkx:generate-html] [INFO] Processing files matching interface-home.xml. [INFO] Processing files matching progress-report.xml. [INFO] Stylesheet location: jar:file:/C:/Documents and Settings/borutb/.m2/repository/com/agilejava/docbkx/docbkx-maven-plugin/1.6 9.1.0/docbkx-maven-plugin-1.69.1.0.jar!/META-INF/docbkx/html/docbook.xsl [INFO] Setting catalog files to: jar:file:/C:/Documents and Settings/borutb/.m2/repository/org/docbook/docbook-xml/4.4/docbook-xml -4.4.jar!/catalog.xml [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 9 seconds [INFO] Finished at: Fri May 19 12:33:52 CEST 2006 [INFO] Final Memory: 7M/50M [INFO] And here is an example Docbook document: !DOCTYPE book PUBLIC -//OASIS//DTD DocBook XML V4.1.2//EN http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd book bookinfo titleDocBook document example/title author firstnameOvidiu/firstname surnamePredescu/surname /author copyright year2001/year holderOvidiu Predescu/holder /copyright /bookinfo preface titleExample document/title paraA simple DocBook example document./para /preface chapter titleDocBook and XSLT-process mode for GNU Emacs/XEmacs/title paraThe emphasisXSLT-process/emphasis mode, when used with the DocBook-XSL stylesheets makes GNU Emacs/XEmacs the ideal DocBook processor./para paraTo find out more on how to use the emphasisXSLT-process/emphasis mode for DocBook processing, point your browser to ulink url="" href="http://xslt-process.sourceforge.net/docbook.php">http://xslt-process.sourceforge.net/docbook.phphttp://xslt-process.sourceforge.net/docbook.php/ulink./para /chapter /book Regards, Borut On 12.5.2006 22:06, Wilfred Springer wrote: All, With JavaOne around the corner, I figured it would be good time to make some announcements, aka shameless advertising. For those of you who are not completely satisfied by the kind of DocBook support that Maven has on board, or the Mojo at mojo.codehaus.org, here's a chance to try something different. I just pushed a version from my own personal DocBook supporting plugin to the Maven repository at http://agilejava.com/maven/ (which is - contrary to what you might expect from it by its name - a Maven 2 repository). Being the father of this baby, I am of course convinced that it has some nice distinguishing features, including: 1. Based on the DocBook XSL stylesheets, however... 2. Completely self-contained; you don't need to install the DocBook XSL stylesheets on your system. You don't even need to have the DTD's on your system, and you can run the plugin if you are offline. 3. Dedicated configuration support for a huge collection of properties to influence the transformation. (In fact, it has dedicated properties for all XSL parameters documented in the DocBook XSL distribution.) 4. It has been built using a dedicated Maven plugin to generate DocBook Maven plugins. Feel free to give it a try. And read more about
Re: DocBook Maven Plugin
-components:pom:1.1.4 from the repository. [DEBUG] org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-5:runtime (selected for runtime) [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0:runtime (selected for runtime) [DEBUG] Configuring mojo 'com.agilejava.docbkx:docbkx-maven-plugin:1.69.1.0:generate-html' -- [DEBUG] (f) generateToc = /book toc [DEBUG] (f) ignoreImageScaling = 1 [DEBUG] (f) includes = interface-home.xml,progress-report.xml [DEBUG] (f) sectionAutolabel = 1 [DEBUG] (f) sectionLabelIncludesComponentLabel = 1 [DEBUG] (f) sourceDirectory = C:\Documents and Settings\borutb\Desktop\Workspace\feed-index-server\src\docbkx [DEBUG] (f) stylesheetLocation = META-INF/docbkx/html/docbook.xsl [DEBUG] (f) targetDirectory = C:\Documents and Settings\borutb\Desktop\Workspace\feed-index-server\target\docbkx\html [DEBUG] (f) targetFileExtension = html [DEBUG] -- end configuration -- [INFO] [docbkx:generate-html] [INFO] Processing files matching interface-home.xml. [INFO] Processing files matching progress-report.xml. [INFO] Stylesheet location: jar:file:/C:/Documents and Settings/borutb/.m2/repository/com/agilejava/docbkx/docbkx-maven-plugin/1.6 9.1.0/docbkx-maven-plugin-1.69.1.0.jar!/META-INF/docbkx/html/docbook.xsl [INFO] Setting catalog files to: jar:file:/C:/Documents and Settings/borutb/.m2/repository/org/docbook/docbook-xml/4.4/docbook-xml -4.4.jar!/catalog.xml [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 9 seconds [INFO] Finished at: Fri May 19 12:33:52 CEST 2006 [INFO] Final Memory: 7M/50M [INFO] And here is an example Docbook document: !DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" book bookinfo titleDocBook document example/title author firstnameOvidiu/firstname surnamePredescu/surname /author copyright year2001/year holderOvidiu Predescu/holder /copyright /bookinfo preface titleExample document/title paraA simple DocBook example document./para /preface chapter titleDocBook and XSLT-process mode for GNU Emacs/XEmacs/title paraThe emphasisXSLT-process/emphasis mode, when used with the DocBook-XSL stylesheets makes GNU Emacs/XEmacs the ideal DocBook processor./para paraTo find out more on how to use the emphasisXSLT-process/emphasis mode for DocBook processing, point your browser to ulink url="" class="moz-txt-link-rfc2396E" href="http://xslt-process.sourceforge.net/docbook.php">"http://xslt-process.sourceforge.net/docbook.php"http://xslt-process.sourceforge.net/docbook.php/ulink./para /chapter /book Regards, Borut On 12.5.2006 22:06, Wilfred Springer wrote: All, With JavaOne around the corner, I figured it would be good time to make some announcements, aka shameless advertising. For those of you who are not completely satisfied by the kind of DocBook support that Maven has on board, or the Mojo at mojo.codehaus.org, here's a chance to try something different. I just pushed a version from my own personal DocBook supporting plugin to the Maven repository at http://agilejava.com/maven/ (which is - contrary to what you might expect from it by its name - a Maven 2 repository). Being the father of this baby, I am of course convinced that it has some nice distinguishing features, including: 1. Based on the DocBook XSL stylesheets, however... 2. Completely self-contained; you don't need to install the DocBook XSL stylesheets on your system. You don't even need to have the DTD's on your system, and you can run the plugin if you are offline. 3. Dedicated configuration support for a huge collection of properties to influence the transformation. (In fact, it has dedicated properties for all XSL parameters documented in the DocBook XSL distribution.) 4. It has been built using a dedicated Maven plugin to generate DocBook Maven plugins. Feel free to give it a try. And read more about it on my web log: http://agilejava.com/blog/ Cheers, Wilfred -- -- Naključna izjava tedna iz tednika Mladina:
DocBook Maven Plugin
All, With JavaOne around the corner, I figured it would be good time to make some announcements, aka shameless advertising. For those of you who are not completely satisfied by the kind of DocBook support that Maven has on board, or the Mojo at mojo.codehaus.org, here's a chance to try something different. I just pushed a version from my own personal DocBook supporting plugin to the Maven repository at http://agilejava.com/maven/ (which is - contrary to what you might expect from it by its name - a Maven 2 repository). Being the father of this baby, I am of course convinced that it has some nice distinguishing features, including: 1. Based on the DocBook XSL stylesheets, however... 2. Completely self-contained; you don't need to install the DocBook XSL stylesheets on your system. You don't even need to have the DTD's on your system, and you can run the plugin if you are offline. 3. Dedicated configuration support for a huge collection of properties to influence the transformation. (In fact, it has dedicated properties for all XSL parameters documented in the DocBook XSL distribution.) 4. It has been built using a dedicated Maven plugin to generate DocBook Maven plugins. Feel free to give it a try. And read more about it on my web log: http://agilejava.com/blog/ Cheers, Wilfred
