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: neutral (asf.osuosl.org: local policy)
Subject: RE: [logging] release status
From: Simon Kitching <skitching@apache.org>
Reply-To: skitching@apache.org
To: commons-dev@jakarta.apache.org
In-Reply-To: <23678.1137756155@www063.gmx.net>
References: <1137753390.22973.19.camel@localhost.localdomain>
	 <23678.1137756155@www063.gmx.net>
Content-Type: text/plain
Date: Sat, 21 Jan 2006 00:33:06 +1300
Message-Id: <1137756786.22973.41.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

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.

Regards,

Simon


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