commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henning P. Schmiedehausen" <...@intermeta.de>
Subject Re: [logging] dependencies [WAS Re: [logging] new release?]
Date Sun, 09 Oct 2005 09:39:59 GMT
robert burrell donkin <robertburrelldonkin@blueyonder.co.uk> writes:

>>   There have been objections about adding "dependencies", but JCL is
>>   a project that already has heaps of compile-time dependencies that
>>   aren't actually runtime dependencies, eg LogKit is a compile-time
>>   dependency too, but isn't needed to run.

>i think that there are a lot of different issues here which could do
>with being untangled. i'll make a stab at outlined the different ones i
>see (possibly with a few to documenting later). please feel free to kick
>off discussion (i've refrained from presenting solutions) and add any
>i've missed.

>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.

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.

>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).

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). :-)

>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.

>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.

	Best regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/

RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for hire
   Linux, Java, perl, Solaris -- Consulting, Training, Development

		      4 - 8 - 15 - 16 - 23 - 42

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


Mime
View raw message