On Sun, 2005-10-09 at 09:39 +0000, Henning P. Schmiedehausen wrote: > robert burrell donkin <[EMAIL PROTECTED]> writes:
<snip> > >downstream maintainers > >---------------------- > >my major concern was about the impact of JCL dependencies on downstream > >maintainers (rather than users). this include the gump infrastructure > >and packagers such as debian. JCL is now a really basic component right > >at the bottom of the java package tree. > > I think the problem is the perception of "compile time dependencies" > and "run time dependencies" here. IMHO for downstream maintainers, it's more a question of official core dependencies (which is something a little different from either runtime or compile time dependencies). the current build detects when optional dependencies are missing and does not build anything relying on them. required core dependencies are much smaller than those that we compile into the standard distribution. for gump, JCL is split into api and full. projects declare themselves dependent upon the api and then don't have to worry about all the other dependencies. one of the biggest mistakes we made was creating an official distribution which works only for compilation: to run an application, you need something a little bigger. this means that the tactic which works well for gump can't be easily applied by downstream maintainers elsewhere. > Our current build tool (maven) is not able to distinguish between > compile-time and run-time dependencies. And some packagers don't > understand this and start to require all of the compile time > dependencies also at runtime. (logging uses ant for builds but) i agree that this is a major issue for all projects that use maven. JCL uses maven to generate the documentation which is misleading. does anyone know how to add comments for dependencies? > >in the best case scenario, more dependencies mean that maintainers have > >more work to do. in the worst case scenario, maintainers will be forced > >to remove JCL and all packages that depend upon it from their > >distribution. for example, debian will only ship java libraries that > >will run on a free JVM. so, the impact of adding an innocuous dependency > > That is a political decision of debian (and e.g. Fedora) to do > so. They won't be able to ship a large number of packages anyway > (e.g. everything that requires Sun libs until either GlassFish or > Geronimo come along far enough to allow the usage of things like mail > or activation). though some are more agnostic about JVM's than debian, all packagers have similar problems with any dependencies they cannot package and distribute. the whole point of package maintenance is to ensure that the end user ends up with a working system. the more official required dependencies a library declares, the more likely it is that it cannot be packaged. so this is a real issue (as well as one of perception). > The question for this scenario is: Do we want to cater to the needs of > "truly free software" (as in GNU) or do we want to continue down the > road of "truly free software" (as in ASF). :-) JCL is a library whose downstream users are often libraries and applications. IMO the right attitude is to allow downstream libraries and application a choice. this means having some appreciation of the problems of downstream maintainers of packages. > >may be that downstream maintainers are forced to remove scores or > >hundreds or packages from their distributions. > > No matter what decision we make, there is someone is bound to stand up > and whine. So IMHO we should just continue as it is comfortable to the > JCL community and let the rest sort out the political details. this isn't politics: it's about being sympathetic to the needs of our downstream users. downstream users for a library include many maintainers as well as developers of libraries and applications. IMO it's important that allow them to choose whether they want to be able to support packaged distributions or not. we should not be making this choice for them. many (most?) downstream maintainers roll their own from the source possibly this could be addressed by analysing the ant build and creating documentation aimed specifically at them. > >perceived dependencies > >---------------------- > >a different concern is that users are given the wrong impression of the > >libraries which are required to run JCL. this includes users who feel > >they need to find and download sources for all dependencies and those > >who need to distribution and run a minimal stripped down version. what > >classes and dependencies are required is a FAQ. > > +1 I hope that m2 will help us along here in being able to clearly > specify build and runtime dependencies. +1 the documentation we created for the break in compatibility between collections 2 and 3 seemed to work out ok so maybe this one can be addressed by documentation. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
