ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Ruby" <ru...@us.ibm.com>
Subject Re: build.classpath and tinderbox builds
Date Wed, 27 Dec 2000 19:40:37 GMT
Jon Stevens wrote:
>
> > adding to my classpath is being friendly, overriding it
> > silently is not.
>
> I agree.

If I don't hear anything shortly, I will check in the change with having
the system class path before the build's class path being the default.  If
anyone objects after that point, changing the defaut is easy enough...

> One suggestion, add full dates to the output. In other
> words, I want to know time and date when things were built.

I figured it was more important to know when the code was last updated or
checked out than when it was built.  Click on the "Project: cvs" link at
the top of any build log and you will see exactly when the code was checked
out and what files were updated.

The build time is already listed on the top index.html page.  I'll add the
date to the banner.

> > I have verified that at least the xml-fop changes
> > will break xml-cocoon2.
>
> The Turbine ones will as well if Cocoon2 is depending on the
> database pool.

As near as I can tell, cocoon2 does not depend on turbine.

> Other than above, it looks great! I want it! :-)

I'll recommend waiting until the code settles down.

- Sam Ruby


Jon Stevens <jon@latchkey.com> on 12/27/2000 12:46:18 PM

Please respond to ant-dev@jakarta.apache.org

To:   <ant-dev@jakarta.apache.org>
cc:
Subject:  Re: build.classpath and tinderbox builds



on 12/26/2000 2:29 PM, "Sam Ruby" <rubys@us.ibm.com> wrote:

> I'm contemplating making a change to
...taskdefs.javac.getCompileClasspath,
> and would like to solicit feedback before making the change.  At the
> moment, the classpath attributes/elements are placed in *FRONT* of any
> system defined classpaths.  In most cases, this means that the developer
> has no easy way to override this behavior at runtime.
>
> What I would like to do is to introduce a build.classpath property that
> modifies this behavior.  Depending on the value of this property, the
> system class path is placed in front, in back, or is not overridden at
all.
> I'm willing to leave the default behavior as it is, though I disagree
with
> it - adding to my classpath is being friendly, overriding it silently is
> not.

I agree.

> For an example of why this is important to me, take a look at :
>
>
http://oss.software.ibm.com/developerworks/opensource/jakarta/proto/index.ht

ml> .
>

Nice layout. :-) One suggestion, add full dates to the output. In other
words, I want to know time and date when things were built. FYI, I just
used
your tool to fix the javadoc and compiler warnings in Turbine. :-)

> I'm attempting to build each project using the latest results from all
the
> projects that they depend on.  If you notice the xml-cocoon build failed,
> and it looks like there are recent changes to both the xml-fop and
turbine
> projects which will likely break cocoon if they are released in their
> current form.  You may also notice that the xml-cocoon2 build did *not*
> fail - this is because the xml-cocoon2 build process overrides the
> classpath I provided; I have verified that at least the xml-fop changes
> will break xml-cocoon2.

The Turbine ones will as well if Cocoon2 is depending on the database pool.

> Suggestions for property names, values, alternate approaches, or comments
> on the tinderbox builds I am prototyping are all welcome.

Other than above, it looks great! I want it! :-)

-jon

--
Honk if you love peace and quiet.



---------------------------------------------------------------------
To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ant-dev-help@jakarta.apache.org




Mime
View raw message