If that's not enough, previous experience indicates I'll eventually hit a wall delegating to or extending Red5 classes and will have to resort to modifying the source. If I chose to fully mavenize the project, I'll drive myself crazy trying to keep the Red5 drop tracking well with the vendor source. What I need is a way to kick off the drop's Ant build and collect the resulting jar(s) as resolvable Maven artifacts.
Enter maven-antrun-plugin
. This convenient little tool allows me to bind appropriate Ant targets to phases in a Maven build's lifecycle. I've chosen to handle, obviously, clean, compile and package.
maven-antrun-plugin
1.6
Each execution targets the same goal, antrun:run.
...
run
...
Cleaning is fairly trivial, requiring only executing ant against the target clean.
antrun.clean
clean
...
To compile, we simply call ant
with no specified target. The Red5 project defines a build.xml configuration that Ant automatically picks up, but we could easily provide our own and specify an antfile
attribute to the ant tag.
antrun.compile
compile
...
Packaging is a little more interesting. Since Maven isn't actually handling archiving, we have to coax Maven into injecting the resulting jar (or jars) from the Ant build under resolvable coordinates. This is where the attachartifact tag proves extremely useful.
antrun.package
package
...
You can read up on classifiers here, but for now the important thing to take away is that our complete POM will configure three artifacts in our local repository:
- red5-1.0.0-SNAPSHOT.pom
- red5-1.0.0-SNAPSHOT-server.jar
- red5-1.0.0-SNAPSHOT-boot.jar
No comments:
Post a Comment