Mailing List Archive

> Hey all, after all of the discussion that went on, I just want to confirm
> that the build file changes that I made with regards to the properties
> settings are indeed cool with everyone and that no one was overly put out by
> those changes.
>
> Any real/major complaints?

I think the build.properties idea is a good one, and I've adopted the
idea in other projects, but I've got a suggestion for making it
slightly better (which might quell some of the complaints.)

I like the idea of separating environment-specific properties from
project-specific properties. For example, the structure of the source
tree and distribution kit is part of the project, wheras the location
of the JavaCC install, or the favorite Java compiler, or the location
of the jakarta-site2 stuff is part of the environment.

Properties describing the user's environment should go in the user's
~/lucene.properties. It would be nice if the structure of build.properties
reflected the fact that there are three categories of properties there:
- properties that are part of the project structure, and expected to
not change very often.
- properties that will change often, like the version number
- properties that the user may want to override in his ~/lucene.properties,
like build.compiler and the location of the JavaCC install.

Simply dividing b.p into three sections, with appropriate comments,
would be helpful.

I'd further consider moving the properties in the first category,
those that structure the project and which are not really designed to
be changed without other major changes to the project, back into the
build.xml. That way, b.p would have only highly dynamic or
environment-speicific properties, and b.xml would have only structural
properties. Since the goal (I assume) was factoring out the dynamic
stuff so users don't have to edit b.xml to change the
version/environment, this seems to more explicitly follow that goal.

--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

on 3/11/02 2:07 PM, "Brian Goetz" <brian@quiotix.com> wrote:

> Simply dividing b.p into three sections, with appropriate comments,
> would be helpful.

Yea, I just did this earlier today with Scarab's default.properties and I
think it helped the readability of it quite a bit.

> I'd further consider moving the properties in the first category,
> those that structure the project and which are not really designed to
> be changed without other major changes to the project, back into the
> build.xml. That way, b.p would have only highly dynamic or
> environment-speicific properties, and b.xml would have only structural
> properties. Since the goal (I assume) was factoring out the dynamic
> stuff so users don't have to edit b.xml to change the
> version/environment, this seems to more explicitly follow that goal.

I agree with that as well, Scarab does something similar to that.

Although, I'm not entirely 100% sure which properties belong in build.xml
and which don't. I can see a property such as dist.dir and packages= going
back into the build.xml because in reality, they don't need to be changed by
the user, but others are definitely questionable. I would also suggest
modifying the javacc.* properties to be a single property...the location of
the JavaCC.zip file (relative or absolute). There is really no need to have
three properties like that.

-jon


--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

> Although, I'm not entirely 100% sure which properties belong in build.xml
> and which don't. I can see a property such as dist.dir and packages= going
> back into the build.xml because in reality, they don't need to be changed by
> the user, but others are definitely questionable.

I could see dist.dir and packages (call this javadoc.packages, since I
could see wanting to filter on packages in other ways) going into the
build.properties, since they are really modifiers as to how you want
the distribution built. I could also see build.root going in
b.properties, which would enable (for example) the source tree to live
on a read-only or shared volume. Other build.x properties go in b.xml.

I'd propose these rules:
- anything having to do with the structure of the source tree goes in b.xml
- anything having to do with the structure of the build tree goes in b.xml
- anything having to do with resources that comes from outside the source
tree, or the locations of where to put the build or distribution trees
go in b.props.
- Anything having to do with anticipated build options (build only this
subset of the distribution) should be controlled by flags in b.props.

> modifying the javacc.* properties to be a single property...
> the location of the JavaCC.zip file (relative or absolute). There is
> really no need to have three properties like that.

Right. Besides, the structure of the JavaCC distribution directory
changed at one point, so with the three-property case, you'd still
have to change two properties anyway.

--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>