On Thu, Jan 6, 2011 at 1:03 AM, Anders Hammar <and...@hammar.net> wrote:
> Don't put the configuration in a file outside the pom. A plugin's
> configuration should be in the pom.
The configuration for my plugin will be in the pom of course, but the
configuration of the filesets and other logic to determine some DLLs I
need to copy has to be in separate xml files because they will come
from the dependencies.
I pretty much know what I need to do to write my plugin, and it won't
be that hard, but I'm looking for the best way to have my own xml that
I can easily parse. And I thought maybe I could re-use the logic the
Maven uses for parsing <resources> into a java.util.List of
org.apache.maven.model.Resource, so that I can re-use the shared code
in org.apache.maven.shared.filtering to do the actual copying.
Here is a longer description of what I'm trying to do. I want to
create a plugin that will
1. copy dlls/pdbs/etc needed for runtime from specific places below
target\dependency\bin to target\bin.
2. copy other dlls/pdbs/etc needed for runtime from specific places
defined by XML files that come from the dependencies.
The plugin would take the following params:
sourceDirectory - where dependencies are checked out to (default is
target\dependency)
sourceBinDirectory - where the binary files live (default is
${sourceDirectory}\bin)
sourceXMLDirectory - where the binaries.xml files live (default is
${sourceDirectory}\setup-runtime)
outputDirectory - where to copy binaries to (default is
target\bin\${config}.${platform})
config - (Debug, Release, or all; defaults to all)
platform - (Win32, x64, "Any CPU", or all; defaults to all)
framework - (vc100, dotnet35, dotnet40, silverlight4, silverlight5)
The plugin will have a copy-binaries goal that starts by copying all
the dlls/pdbs/etc that exist in the standard locations to the
outputDirectory:
1. $sourceBinDirectory/$framework/$config.$platform/*
2. $sourceBinDirectory/$framework/$config for $platform.*/
3. $sourceBinDirectory/$framework/$config/*
4. $sourceBinDirectory/$framework/$platform/* (look for "d" extension
to exclude debug or release depending on config)
The copy-binaries goal will then copy non-standard files (outside
$sourceBinDirectory) by looking for fileset definitions in files named
binaries.xml below $sourceXMLDirectory. The components that need to
will provide this binaries.xml.
Example binaries.xml file, assuming I mimic the XML schema used by the
assembly plugin (directory is relative to ${sourceDirectory}):
<?xml version="1.0" encoding="utf-8"?>
<binaries>
<fileSets>
<!-- Copy all tz files -->
<fileSet>
<includes>
<include>tz/**</include>
</includes>
</fileSet>
<!-- Copy dtSearch 32-bit files if platform is Win32 -->
<fileSet>
<platform>Win32</platform>
<directory>dtSearch\bin\32bit</directory>
<includes>
<include>**</include>
</includes>
</fileSet>
</fileSets>
</binaries>
If I pattern after the resources plugin, and can re-use some of that
logic, then the tags will probably be <resources> and <resource>
instead of <fileSets> and <fileSet>.
Phillip
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
