On Thu, 14 Aug 2003, Tomasz Pik wrote:
> Henri Yandell wrote: > > > > I figured the munging would be unlikely to pass muster. The easy solution > > is that BeanUtils/Net are not allowed into a combo-distribution until > > their dependencies are. So ORO/commons-logging would have to be in it. One > > problem there is commons-logging's dependency on log4j, logkit and > > avalon-framework. > > Two points here; > 1. here was a disussion of splitting logging into 'api' and > implementation jars but I don't know what's with this idea; > 2. it's compile-time dependency rather then runtime; > I'm also concerned about recompilation of the code. > Note that official release of component comes in source and > binary (compiled) version. And sometimes recompilation may > make code different (OK, I know, in most cases it's J2SE1.4 > problem with StringBuffer.append(StringBuffer) but...). Yep. Splitting proejcts up is the way to handle such things. With an implementation version that does not depend, another one dependent on jdk14 in this instance etc. Combo builds against cvs tags, so as long as the same compiler is used things are fine I think. The problem there is that choice of compiler is not defined in Commons. Not really a Combo issue as such but a cross-Commons issue. Possibly release builds should all occur on some standard machine [nagoya or something]. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
