ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <Craig.McClana...@eng.sun.com>
Subject Re: New build process???
Date Tue, 23 Jan 2001 03:22:58 GMT
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



Mime
View raw message