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
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
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
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
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
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
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
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
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.
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
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
line.
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 g
.
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 gene
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
14 matches
Mail list logo
