ant-dev mailing list archives

Peter Donald wrote:
> At 09:21 22/1/01 -0800, Craig R. McClanahan wrote:
> >I'm not an Ant committer, so I don't have a useful vote here, but Tomcat (and
> >several other Jakarta subprojects) are facting the same basic issues, and it
> >would be nice to see some commonality in how the subprojects organize their
> >build processes.
>
> +1000 ;)
> One of the biggest complaints when I tried to push various apache java web
> technologies on people was that there was no standard build process.
>
> >My personal preference is that the "dist" subdirectory would contain an exact
> >image of the files you would package into a "binary distribution" -- such
> as for
>
> +0.9
>
> For all the projects I develope I have both a dist-lite and a dist
> directory. dist is a full binary image and the -lite version is the binary
> image minus documentation. That way you can use dist-lite as your default
> target and everything still runs reasonably well.
>
In Tomcat (and several other projects I'm involved in), the "build" directory
serves this purpose ... it is designed so that developers can turn around more
quickly after a compile cycle without having to waste the time to create a
complete release directory structure. This is the default build target, and you
have to ask for the "dist" target explicitly.
I don't know if we need any mandated guidelines about such things ... it's the
"dist" target I would like to see codified across subprojects.
>
> >Other common conventions/guidelines could be added to this, if considered
> >desireable -- for example, if your subproject creates executable shell
> scripts,
> >then go in "dist/bin", library JAR files produced by the subproject (as
> opposed
> >to used in creating it) go into "dist/lib", and so on. Such conventions
> would
> >make cross project dependencies much easier to deal with.
>
> +1
> I would also like to see some conventions in the base tree. For instance in
> base tree you would have
>
> README
> LICENSE
> build.[sh|bat]
> build.xml
> src/[x]/** where x is a dimension either by form (java/sql/conf) or
> content
> (shared, core, optional)
> tools/bin/* all scripts used in *build* proces but not during deploy
> (except
> for build.[sh|bat])
> tools/lib/* libraries used during build but not deployed (ie stylebook/ant)
>
These all make sense to me.
>
> >I don't see any reason to impose any Jakarta-wide restrictions on the
> internal
> >contents of the "build" subdirectory, other than a convention that if your
> >subproject utilizes such a thing, it should reside in a subdirectory called
> >"build".
>
> Right - the only issue is that some projects (velocity/turbin/jetspeed) use
> build to denote build scripts atm.
>
As above, I don't think we need to say anything about "dist-lite" or "build" type
targets, as long as the "dist" target is a constant.
>
>
> >What do you think?
>
> +1
>
> I was going to wait till the tinderbox thingie becomes more solidified
> which would allow a use case to be described and thus more likely to
> convince people to use it ;)
>
I think Sam's already been using it for that purpose :-).
>
> Cheers,
>
> Pete
>
Craig