I asked this before, but I don't think I understood the problem well
enough to voice it properly nor had I sat down and implemented the
alternatives.
This is in regards to my DocBook plugin which works completely off the
Maven dependency mechanism. So every aspect of the "DocBook
environment" is defined by dependencies rather than having to have
DocBook set up locally as is usual with DocBook plugins. So everything
from the DocBook XSLT and DTD distro to customizations, fonts and images
are defined via dependencies and "mixed together" to actually perform
the transformation. Anyway, logically it makes sense to break the
pieces up into a few dependencies:
1) DocBook distro
2) fonts
3) "resources" (images, css, etc)
4) custom XSLT (might contain #2 and/or #3 also)
5) DocBook sources (might contain #2, #3 and/or #4 also)
The way DocBook works, fonts and images have to be treated specially
depending on the formating. Thus, I need a way to be able to identify
dependencies containing fonts and/or images and "stage them". It is
this identification step on which I need advice. Basically there seem
to be 2 approaches.
The first approach I have seen in many plugins. Here I would require
the user to tell me the groupId/artifactId of dependency artifacts which
contain fonts and images. The (major) downside of this to me always
seemed the duplication of this information. For example, consider:
<plugin>
...
<configuration>
<imageSources>
<artifact>
<!-- here is the duplication -->
<groupId>com.acme</groupId>
<artifactId>uber-docbook-xslt</artifactId>
</artifact>
</imageSources>
....
</configuration>
<dependencies>
<dependency>
<groupId>com.acme</groupId>
<artifactId>uber-docbook-xslt</artifactId>
<version>1.0.0</version>
</dependency>
</dependencies>
</plugin>
The other approach does not seem much used (that I could find). The
thought was to use custom packaging definitions for the various types of
"ingredients" that go into this DocBook mixture. Then I could
distinguish the various pieces based on the artifact.type w/o any
duplication:
<plugin>
...
<configuration>
...
</configuration>
<dependencies>
<dependency>
<groupId>com.acme</groupId>
<artifactId>uber-docbook-xslt</artifactId>
<type>docbook-xslt</type>
<version>1.0.0</version>
</dependency>
</dependencies>
</plugin>
The other aspect of this comes into play after identification, when I
need to "stage" these resources. Basically, this means I need to
aggregate the images and fonts from multiple sources into a local
staging or work directory. For "dedicated bundles" like #2 and #3, this
is no issue as I can make the assumption that the directory structure
inside the archive is the target structure as well as the fact that all
files should get staged. However, for #4 (and to an extent #5) that is
most likely not the case.
So again, applying the 2 approaches, the first seems pretty verbose:
<plugin>
...
<configuration>
<imageSources>
<artifact>
<!-- here is the duplication -->
<groupId>com.acme</groupId>
<artifactId>uber-docbook-xslt</artifactId>
<sourceBase>resources</sourceBase>
<targetBase>images</targetBase>
<includes>...</includes>
<excludes...</excludes>
</artifact>
</imageSources>
....
</configuration>
<dependencies>
<dependency>
<groupId>com.acme</groupId>
<artifactId>uber-docbook-xslt</artifactId>
<version>1.0.0</version>
</dependency>
</dependencies>
</plugin><plugin>
...
<configuration>
<imageSources>
<artifact>
<!-- here is the duplication -->
<groupId>com.acme</groupId>
<artifactId>uber-docbook-xslt</artifactId>
</artifact>
</imageSources>
....
</configuration>
<dependencies>
<dependency>
<groupId>com.acme</groupId>
<artifactId>uber-docbook-xslt</artifactId>
<version>1.0.0</version>
</dependency>
</dependencies>
</plugin>
Whereas with the second approach, because it is a known packaging, I can
make educated assumptions about the contents and structure of those
contents.
I guess, overall, a slight variation on the first approach would be to
use dependency properties rather than explicit configuration.
Overall I really liked the idea of custom packaging as a solution here
but I had concerns because I did not see anyone using packaging in this
manner which leads me to believe that either this is not its intended
use or there is some practical difficulty with using them.
Anyway, if someone could validate my thinking here and give
recomendations/suggestions, that would be much appreciated.
Thanks,
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
