commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject RE: [logging] release status
Date Fri, 20 Jan 2006 11:33:06 GMT
On Fri, 2006-01-20 at 12:22 +0100, Boris Unckel wrote:
> > > Sorry for not precise enough. I do not want to represent the runtime
> > > dependencies or all compiletime dependencies for a special case.
> > > The manifest should just represent against which APIs and their 
> > > versions it
> > > was actually compiled.
> > > So if someone did not compile against avalon and just uses log4j - OK.
> > > The manifest represents just log4j and its version.
> > > 
> > > Optional fulfilled dependeny => entry in the manifest
> > > Optional ignored dependeny => _no_ entry in the manifest
> > 
> > I don't quite understand what you mean. The JCL distribution is
> > *compiled* against all of the libraries it supports (about 5 of them),
> > creating the appropriate adapter classes. It is then shipped with all of
> > the adapters but none of those libraries, and the user provides
> > whichever one they want to use for a particular app.
> > 
> > Listing all of these libraries as "dependencies" seems misleading, as
> > JCL can run fine with none of them (using its internal SimpleLog or
> > NoOpLog).
> The official distribution is compiled against all versions. Am I correct
> that the build trys to detect which dependencies are there and
> compiles/builds a jar for the fulfilled dependencies?
> A user could build a jcl...jar with the default build.xml but without the
> official distribution dependencies.
> The suggestion is to document the fulfilled compile time dependencies. It
> should not document the needed runtime dependencies. If the user who builds
> the jar herself distributes the jar with a different name (i.E. to not have
> to change startup scripts) or something, a third person could see which
> dependencies in which version were there.

I see what you mean. However that sounds rather tricky to do.

And again the user might compile against three different libs (rather
than all 5 supported), in which case again it would be misleading to
insert "dependency" lines for all of the available libs.

People have got by with the way JCL has done things for the last 4 years
or so, and we're probably doing away with this entire process for the
next release. So unless a change is (a) very easy, or (b) very important
I'm not keen to mess with the way things are already done.

Adding a "Specification-Title" entry to MANIFEST.MF - sure, why not. But
dynamically calculating dependencies - this all sounds much more complex
and I can't see the actual benefit. 

If someone wants to know what libs a custom JCL jar was compiled
against, they can look inside the jarfile to see what adapter classes
are present.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message