On 2/26/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
> I didn't notice before because i was using a version of solr i build from
> svn, but none of the nightly ZIP files don't contain solr.war in the
> example...

Ahh, in my tests I just did "ant clean" before "package", and that
didn't remove the war in example (and hence why I didn't catch it). 
I've checked in the simplest fix (add example as a package dependency)
so the build tonight should be OK.

> ...I think the problem is that the dependency tree for "nightly" doesn't
> include "dist-example"

dist-example makes a zip of example - but we decided not to distribute
that separately.

> "ant package" doesn't seem
> to care bout the zip produced by "ant dist-example" .. it goes straight to
> ./example)
>
> developers would never notice the problem as long as they've run "ant
> example" at least once ... "ant clean" doesn't remove that artifact, so no
> matter how many changes you might make, the war in the example will never
> change unless you manually run "ant example" again.
>
> I'm not ant expert, but I'm a little uneasy about the way "ant example"
> copies build artifacts from dist into what is really a source directory
> (./example).

I had considered example to be a binary directory, like lib (and hence
not under source).

> Perhaps...
>
>   * "ant example" should copy everything from
>      ./example to ./build/example

in which case maybe example should go under src...

>   * "and dist-example" should:
>     1) depend on dist-war
>     2) zip up:
>           ./build/example/**
>           ./dist/solr-version.war
>        into: ./dist/solr-version-example.zip
>   * "ant dist" should depend on "dist-example"

>   * "ant package" rely only on the files it can find in the dist

Why is that?

>     directories, and not pull from any of the directories under version
>     control, or even the ./build directory (to makt the master zip, it can
>     explode re-zip the what it finds in ./dist)
>
> thoughts?

I took the shortest path I knew in getting a nightly binary
distribtion (and I modeled the layout based on nightly builds from
nutch/hadoop/lucene).  So if things can be cleaned up, go for it...
i'm more interested in the results (the actual layout of the final
.zip)

-Yonik

Reply via email to