Hi Marshall,
I mostly agree with you for putting binaries into lib dir from SVN for the
release because we would like the checkout/compile phase to be as easy and
quick as possible.
Though it could be somehow annoying I think it would be nice in the near
future (after the release) to leave those binaries out and use long time
stable artifact versions from the central Maven repository where possible.
Tommaso
2009/9/20 Marshall Schor <m...@schor.com>
> 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
>
