> > Another alternative that wouldn't involve us integrating forrest into > the build would be to nuke docs/ and rename it to > src/site/generated_content or something. Then when you run ant it > copies this to build/docs. >
+1. If site is built under src/site/build, we can have "ant docs" or something that generates jdocs and puts them under build/docs + it copies src/site/build under build/docs. BTW, I tried "ant prepare-release" from "src" and it doesn't work b/c of "get-svn-info" which makes sense because this is not a svn checkout. But maybe we can have it not fail on errors? I.e., if I run "ant jar" then the .jars are created with this prop in manifest: Implementation Version: 3.2.0 exported somehow it knows it's not a svn checkout, and instead of the revision (which appears in the binary pack), it puts 'exported'. Can't we do the same here? Shai On Tue, May 31, 2011 at 3:06 PM, Robert Muir <[email protected]> wrote: > On Tue, May 31, 2011 at 8:01 AM, Shai Erera <[email protected]> wrote: > > I don't think it's a showstopper b/c the docs work fine in the binary > > release, though it'd be good if we can fix that somehow for future > releases. > > I don't like inconsistencies. Maybe we should remove all "docs" and > generate > > them by an Ant target? > > Lets open an issue for this? > Really this is nothing new (I checked lucene 2.4 again). > > If a user runs 'ant prepare-release' from a source dist, they will get > a usable 'docs' folder. > But its confusing that in SVN we have 'docs' (which is in fact > generated code from src/site). > > It would be way less confusing if docs/ didnt exist at all, but when > running the build task, forrest would run and put this stuff in > build/docs, then any src user/svn consumer wouldnt see these pre-built > docs and have false hopes. > Another alternative that wouldn't involve us integrating forrest into > the build would be to nuke docs/ and rename it to > src/site/generated_content or something. Then when you run ant it > copies this to build/docs. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
