I'm going through our build process for the Sandbox Distribution, and
consolidating/unifying many aspects of it (not yet checked in - still a
work in progress).
One area I've examined: Many sandbox projects rely on and redistribute
3rd party Jars (that are Apache licensed, or are otherwise OK to
distribute).
All (I think) of these Jars are dependencies (in the Maven system) that
maven can automatically download from its repositories, to the .m2 local
repo.
Many sandbox projects put these Jars into the project's lib/ directory.
Some sandbox projects check in these Jars into SVN, and build their
distributions by copying their lib/ dir to the distribution; others use
the maven dependency plugin to get these jars into the local repository
(if not already there) and then copy that into the distribution.
After thinking about this for a while, and considering both methods, I
think the most reliable way to handle 3rd party Jars is to manually put
them into the lib/ directory, once, and then check the lib/ directory
into SVN. This avoids build issues in the future which could occur if
the Jar obtained from the maven dependency plugin is somehow corrupted,
or changes level, etc. Also, having the Jars in SVN insures that
whatever work we do to update the LICENSE/NOTICE files for those Jars
remains valid (because the Jar doesn't (potentially) change).
Examples of project copying Jars into its lib/ dir manually:
BSFAnnotator
DictionaryAnnotator
RegularExpressionAnnotator
SimpleServer
Examples of project using the maven dependency plugin:
ConfigurableFeatureExtractor (work in progress, pom doing this not yet
checked in)
Lucas
So, unless there are strong objections, I'm going to be changing the
sandbox build to consistently do the following:
- for 3rd party dependencies - expect the Jars to be manually put in
the lib/ dir and checked into SVN
- put the lib/ into the bin distribution
- if a pear is being built, put the lib/ into the pear
- not automatically populate the lib/ using the maven dependency
plugin mechanism
- change the maven descriptors for these dependencies, where needed,
to <scope>system</scope> indicating these jars are in the lib/, and add
the <systemPaht> element.
This places a small burden on the developers when creating a new project
to obtain the needed 3rd party Jars once and put them in the lib/ dir.
One way to do this is to initially code the maven 3rd party Jar
dependencies with no <scope> (defaulting thereby to compile) and let
maven get these Jars from searching its repositories. Then, copy them
from the .m2 local repository to the lib/ dir, and change the scope to
system, and set <systemPath>${basedir}/lib/XXXX.jar</systemPath>.
-Marshall
