I would also prefer to have the default build target either produce a full log4j.jar identical to the released .jar or fail and produce nothing at all.
It would also be very useful, as Scott suggests, to have a 'build-nodeps' target which was capable of building a minimal 'core' log4j.jar with only jdk dependencies.
An update to the build documentation (HOWTOBUILD.txt) could clearly state all the default build dependencies on the relevant jdk platforms (perhaps with links for obtaining them)
Kind Regards
Andy
On Sat, 18 Dec 2004 13:39:07 -0800 "Scott Deboy" <[EMAIL PROTECTED]> wrote:
How about a compromise:
Rename the current build target to build-deps-optional and make a new (default) build target that fails on missing dependencies.
Scott
-----Original Message-----
From: Jacob Kjome [mailto:[EMAIL PROTECTED]
Sent: Fri 12/17/2004 2:59 PM
To: Log4J Developers List
Cc:
Subject: RE: cvs commit: logging-log4j build.xml
At 08:23 PM 12/17/2004 +0100, you wrote:
>
>Hey Jake,
>
>The current system has the advantage of building a functional
>log4j.jar out of the box. It is in place since about 1659 and in
>practice no one has ever complained about it.
>
1659? I don't get it. Anyway, you've got two now (if I can speak for Scott). As far as user complaints, it is unlikely that you would get many since most use the distributed version. It is really a matter of principal. The mere potential to create a Log4j jar that may not necessarily contain all components that Log4j is advertised to have is reason enough not to make the build work the way it currently does. Imagine if the person generating the release accidentally pointed to the wrong location for a dependency and made a release that didn't have all the features available! People make mistakes which is why you set up environments that catch these mistakes. It doesn't affect me much in practice since the testing I'm doing against the HEAD doesn't really use any components with external dependencies. However, no build that I write will ever use this technique. I'll leave it at that.
Jake
>At 07:19 PM 12/17/2004, you wrote:
>
>>Hi Scott,
>>
>>I think that your change is, indeed, consistent with the rest of the build.
>>However, I think the entire logic of this is flawed. It allows for the
>>generation of an incomplete log4j.jar (as you mentioned) and that just
>>shouldn't be allowed. If there are compile-time dependencies, they should be
>>mandatory. At runtime, if one doesn't use some of the features that require
>>extra dependencies, then they are optional. But the build should never allow
>>them to be optional. All or none.
>>
>>Jake
>
>--
>Ceki Gülcü
>
> The complete log4j manual: http://qos.ch/log4j/
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
The information contained in this e-mail is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If You are not the intended recipient of this e-mail, the use of this information or any disclosure, copying or distribution is Prohibited and may be unlawful. If you received this in error, please contact the sender and delete the material from any computer. The views expressed in this e-mail may not necessarily be the views of The PCMS Group plc and should not be taken as authority to carry out any instruction contained.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
