Hi, just one small addition
What about using xdoclet to generate assembly.xml and manifest for James?
and
> The alternative is to use the org.apache.avalon.framework.service.*
> instead - the difference is that component can be any
java.lang.Object.
> It kind of makes life easier when your working in the real world.
As it has been discussed some time ago (quite long ago in fact), it requires
some changes to servers (SMTP and others) implementation. That is why, in
fact, switchover to Serviceable is not done yet...
Andrei
----- Original Message -----
From: "Stephen McConnell" <[EMAIL PROTECTED]>
To: "James Developers List" <[EMAIL PROTECTED]>
Sent: Sunday, July 28, 2002 1:11 AM
Subject: Re: Avalon feedback request
>
>
> Peter M. Goldstein wrote:
>
> >Stephen,
> >
> >
> >>Personally I would like to see
> >>
> >
> >> (a) improvements in the framework usage
> >>
> >
> >Any specific, immediate recommendations?
> >
>
> Yes.
>
> 1. James uses the org.apache.avalon.framework.component.* interfaces
> and classes. This really ties you to components developed strictly
> in the Avalon model - which simply makes you life more difficult.
> The alternative is to use the org.apache.avalon.framework.service.*
> instead - the difference is that component can be any
java.lang.Object.
> It kind of makes life easier when your working in the real world.
>
> 2. Declare you depedency on the framework as an extension jar dependency.
> The current avalon-framework.jar (Avalon current CVS build) includes
> this. If the jar files created by James include extension depedencies
> your can get more rigerouse about version control.
>
> >
> >
> >> (b) cleaning up of Avalon Excalibur dependencies (the Excalibur
> >> packages has been cleaned up a lot and you can now limit your
> >> dependencies to only those packages you need) - whereas the
> >> James lib includes all Excalibur contents
> >>
> >
> >By my count we have the following top-level James dependencies:
> >
> >org.apache.avalon.excalibur.collections.*
> >
>
> Jar File: excalibur-collections-1.0.jar
> Extension Name: excalibur-collections
>
> >
> >org.apache.avalon.excalibur.datasource.*
> >
>
> Jar File: excalibur-datasource-1.0.jar
> Extension Name: excalibur-datasource
>
> But you should check this because there are two sub-packages included in
> the datasource project that you may have depedencies on.
>
> >
> >org.apache.avalon.excalibur.io.*
> >
>
> Jar File: excalibur-io-1.1.jar
> Extension Name: excalibur-io
>
> >
> >org.apache.avalon.excalibur.thread.*
> >
>
> Jar File: excalibur-thread-1.0.jar
> Extension Name: excalibur-thread
>
> On this package it appears that there are several depedencies to other
> excalibur package ut they are not documeted in the manifest. I'll post
> this ias an issue over on Avalon-Dev.
>
> >
> >So I'm sure we can do that reduction.
> >
> >
> >> (c) elimination of structural dependencies on Phoenix (Block and
> >>Block context
> >> usage). This would eliminate the Phoenix jar dependency and is
> >>relatively
> >> easy to do. It would enable the deployment of James in more
> >>application
> >> scenarios (embedded, part of web-service), etc. - while
> >>maintaining your
> >> ability to deploy under Phoenix where appropriate.
> >>
> >
> >As of right now we use the BlockContext for one thing and one thing only
> >- to determine the root directory where James is running. This allows
> >us to use relative URLs in the configuration parameters. Quite
> >honestly, I'm not sure this is the best way to do this, although I can't
> >come up with anything else other than adding a root directory
> >configuration parameter. This probably requires a little discussion on
> >the james-dev list.
> >
>
> All you need to do is to replace BlockContext with
> framework.context.Context, then get the File reference as follows:
>
> File file = (File) context.get("app.home");
>
> You simply changing the depedency from Phoenix to "a context object
> capable of providing a File instance keyed by the name "app.home".
> There is work going on over in Avalon to enable you to declare this
> context depedency indendently of the container. I can provide more
> about this is a seperate thread (sometime later). In the meantime, the
> above change will work when deployed in Phoeinix - and it will also work
> in avalon containers.
>
> Cheers, Steve.
>
>
> --
>
> Stephen J. McConnell
>
> OSM SARL
> digital products for a global economy
> mailto:[EMAIL PROTECTED]
> http://www.osm.net
>
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
