Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of
 robertburrelldonkin@blueyonder.co.uk designates 195.188.213.5 as permitted
 sender)
Subject: Re: [logging] dependencies [WAS Re: [logging] new release?]
From: robert burrell donkin <robertburrelldonkin@blueyonder.co.uk>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
In-Reply-To: <1128850705.5014.27.camel@knossos.elmet>
References: <1128676573.3998.17.camel@localhost.localdomain>
	 <1128850705.5014.27.camel@knossos.elmet>
Content-Type: text/plain
Date: Sun, 09 Oct 2005 13:35:39 +0100
Message-Id: <1128861339.5014.88.camel@knossos.elmet>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Sun, 2005-10-09 at 09:39 +0000, Henning P. Schmiedehausen wrote: 
> robert burrell donkin <robertburrelldonkin@blueyonder.co.uk> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org