custom packaging

[Steve Ebersole <st...@hibernate.org>]

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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org