"Craig R. McClanahan" wrote:
>
> On Sun, 29 Apr 2001, Peter Donald wrote:
>
> > At 04:55 28/4/01 -0700, Craig R. McClanahan wrote:
> > >(1) "ant dist" Output Directory:
> > >
> > > Suggestion:
> > > ${commons.home}/${package}/build
> > >
> > > Reasoning:
> > > - All current packages (except Cactus) do this already
> >
> > I have said this before but ... a lot of projects outside commons use
> > "build" for an intermediate directory and "dist" for distribution
> > directory. Other projects (turbine et al) use build to contain build
> > related scripts etc. So why not flip to dist???
> >
>
> I would be happy with "dist" or "foo" or anything ... but trying to get
> this gang to change in unison is like swimming in molasses. :-)
I like dist too, mostly because it's what I'm used too. Foo would be
fine too.
+1 dist
>
> > >(2) Binary Distribution Contents
> > >
> > > The "ant dist" target for a package should ensure that all of the
> > > following contents are placed in the output directory:
> > >
> > > Suggestion:
> > > LICENSE Copy of Apache License
> > > README README with dependencies, etc.
> > > commons-xxxxx.jar Package JAR (no version number)
> > > javadoc/ Package Javadocs
> >
> > how about docs/api and then any extra documentation required by component
> > sits in docs/. This conforms to what a lot of projects do and also matches
> > jdk.
> >
>
> Sounds reasonable -- as long as it is common and predictable.
+1 I agree we need to have a place for non-javadoc documentation.
> > > Reasoning for "No Version Number":
> > > - Allows build.xml files that use these JARs to define properties
> > > (commons-beanutils.jar=${commons-beanutils.home}/commons-beanutils.jar)
> > > without worrying about version numbers
> > > - We're going to maintain API stability, right? :-)
> > > - Versioning information should be included in the MANIFEST.MF
> > > file inside the JAR anyway, so it's redundant in the filename
I actually like having the version number on the jar.
Can't the build scripts assume a pattern :
commons-<component>-<version>.jar
and then deal with them that way, wildcarding the <version> part when
you don't care?
To try to relate a little about why I think this, I have noticed that
people do some strange things, like putting all jars into one directory
for easy access/replacement/copying. So when you are dealing with a
problem, and you get told the classpath is :
CLASSPATH=/opt/jars/commons-beanutils.jar:/opt/jars/commons-fubar.jar:/opt/jars/woogie.jar...
you have no clue whats really going on, requreing another round-trip to
dig into the manifest. It also means when logging in production, and
you dump your classpath to log, you can't tell either. (No, I personally
never depend upon classpaths if I can avoid it...)
Anyway, I don't feel too strongly (have been away from commons for a
bit, so just getting back up to speed on stuff) and agree that the
proposal would make things neater, but there is some upside to the
version in the filename, and I think if we can arrange for it to be
dealt with via patterns and wildcards, things might be better.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
