ext directory [WAS Re: Imap Function]

[Robert Burrell Donkin <ro...@gmail.com>]

On 7/31/07, norman <no...@apache.org> wrote:
> Hi Paulo,
>
> I think it whould be enough to put the jars
> in /path/to/james/apps/james/SAR-INF/lib/ directory ( You need to create
> the lib after james was started once)

IMHO it would be useful to have an extensions directory whose contents
would be automatically copied into the SAR. can anyone think of any
good reasons for me not to just go ahead and add it to the code?

- robert

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

Re: Distributions [WAS: Re: ext directory [WAS Re: Imap Function]]

[Stefano Bagnara <ap...@bago.org>]

Bernd Fondermann ha scritto:
> Stefano Bagnara wrote:
>> As a "next step" we could have a "raw" binary distribution including all
>> of our modules jars and configurations files and the deployment options.
>> In addition to this we can then provide the current phenix distribution
>> starting from this one.
>>
>> This way we have a "binaries" distribution and a "phoenix-deployment".
> 
> Is this "binary" dist a real distribution for end-users (what would they
> do with it?) or just a build artefact?
> 
>   Bernd

Disclaimer: my sentences are part of brainstorming and I'm not
describing a complete solution I already analyzed and I'm supporting.

That said I was thinking at it as a _real_ distribution: I may argue
that I think the "end-users" of this distribution will be java
developers for a while, but maybe this will change with time as we add
documentations, installers, helper to manage it as windows/unix services
and so on.

What I wanted to notice is that if we have one step preparing all of our
module jars then the phoenix deployment is simply a particular
assemblage of that jars and the phoenix folder.

As one of the requirement was to be able to create a customized sar then
I thought we could try to solve 2 issues with one change.

People wanting to use a standard JAMES will use the phoenix
distribution, that do not require anything but the JVM installed and is
ready to run. People wanting to customize the sar, to write some mailets
(mailet sdk) or to use the spring stuff will instead download "binaries"
distribution.

I mean a zip file including all of the jars, some configuration file and
a build.xml used to build the phoenix distribution or to build a custom
sar including custom configs/jars or to build custom mailets sources
placed in a specific folder. In this case the binary zip should also
include the phoenix-packaging and the spring-packaging folders including
jars and other files needed to create our phoenix distribution or to be
able to run james using spring. The build.xml could be a specific
build.xml or could be the same build.xml we used to build the modules
sources but having logic to understand if there are sources or binaries
and accept/reject specific targets based on this. Here ant experts
suggestions will be much more useful then mine.

This distribution would be much bigger than any other artifact we
redistribute as it will contain all of our binaries and will include
phoenix and our spring-based container (and maybe more in future).
At the moment I think that it is better (for both: us and our users) to
manage this as a single distributions instead of publishing more
separate options.

Stefano

PS: About the container vs framework definitions I think there's no need
to argue about this: we have different opinions and I bet we can live
with it with no problems ;-) Let's concentrate on a good solution that
will allow us to limit the set of distributions to manage and our users
to feel comfortable with this.



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

Re: Distributions [WAS: Re: ext directory [WAS Re: Imap Function]]

[Serge Knystautas <sk...@gmail.com>]

On 8/4/07, Bernd Fondermann <bf...@brainlounge.de> wrote:
> Stefano Bagnara wrote:
> > Developers will probably want to look at the startup method to
> > understand how to invoke it within their own application and how to get
> > references to our components so to be able to interact with them.
>
> Our users want easy setup, configuration, integration and extendability.
> This is where Spring could make our user's live easier.
> I know that Avalon has a big bunch of capabilities. But I firmly believe
> that Spring is less invasive, easier to understand and configure,
> better documented, wider used and supported by other technologies.

+1  I would greatly prefer using Spring instead of Phoenix as the
container for basic sysadmin stuff.  There's just so much more
awareness of Spring, it would make non-developers' life easier as well
IMHO.

-- 
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com

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

Distributions [WAS: Re: ext directory [WAS Re: Imap Function]]

[Bernd Fondermann <bf...@brainlounge.de>]

Stefano Bagnara wrote:
> Robert Burrell Donkin ha scritto:
>> On 8/1/07, Stefano Bagnara <ap...@bago.org> wrote:
>>> Robert Burrell Donkin ha scritto:
>> <snip>
>>
>>>>> In fact it does not build anything from source: it only has to take the
>>>>> original SAR, replace the config.xml and add some library.
>>>>>
>>>>> Maybe the tool (another ant script) would also be useful to people
>>>>> downloading the binary distribution (well, in fact it is only a zip
>>>>> file, but I saw some user has problems working with it).
>>>> i agree that a SAR manipulation tool would be useful for the binary
>>>> distribution. IIRC pheonix ships an ant task for this. would need to
>>>> think about whether documentation on customisation would be better
>>>> than an actual script.
>>>>
>>>> - robert
>>> Maybe it's time to split the sar generation from the phoenix-deployment.
>>> This way we could have a module building the sar and another module that
>>> takes the sar and place it in the phoenix distribution to create a
>>> binary build. The ant script used for this last action could be almost
>>> the same used by the binary distribution to create custom sar.
>>> I don't know if the api-library-function-deployment layers are enough to
>>> do that.
>> i suppose the bigger question is how to approach binary distributions
>> once JAMES supports multiple containers: do we issue an distribution
>> per container or one distribution containing multiple artifacts?
>>
>> - robert
> 
> Interesting question.
> 
> I think that, at the moment, the spring deployment is more developer
> oriented than user oriented.
> 
> Spring is not a container 

It is a container, though it lacks the entry point. providing the entry 
point is trivial. it can be in a main() method, or when a servlet engine 
inits a web app. All the rest is there which makes it a container: IoC, 
factories, configuration, classloaders, contexts, ...

 > but a framework and we can compare it to
> avalon and not to phoenix. Bernd wrote a simple startup class and not a
> full "server" kernel for the spring based solution. We could have
> written a simple startup class also for the avalon components (in fact
> what Bernd wrote is an avalon-to-spring wrapper and a simple container
> for spring, so it is in the end a simple container for avalon applications)

well, you _could_ write another kernel besides Spring or Phoenix.

> So, currently, I think that the spring deployment option is more about
> downloading the right jars and follow documentation for specific use
> cases, but the official deployment will remain phoenix for a while.

It will, certainly.

> Developers will probably want to look at the startup method to
> understand how to invoke it within their own application and how to get
> references to our components so to be able to interact with them.

Our users want easy setup, configuration, integration and extendability. 
This is where Spring could make our user's live easier.
I know that Avalon has a big bunch of capabilities. But I firmly believe 
that Spring is less invasive, easier to understand and configure, 
better documented, wider used and supported by other technologies.

> In the phoenix deployment we bundle everything in a sar, while a spring
> distribution would need that jars/xmls exploded.

:-) But on first start, the SAR gets expanded and only then you have 
access to crucial config files. This is really one of the biggest 
annoyances right now.

James/Phoenix setup goes like this:
1. Download dist file
2. expand (everything, but the SAR)
3. startup Phoenix (expand SAR)
4. stop Phoenix
5. edit config files etc.
6. startup Server

We now have: a cryptical, not exactly flat, directory structure with 
config files and data files spread around at  mysterious places

James/Spring would work like this:
1. Download dist file
2. expand
3. edit config files in /config
4. startup Server

This is how most software dists work nowadays. It's convenient. Less 
potential to scare users away.

> As a "next step" we could have a "raw" binary distribution including all
> of our modules jars and configurations files and the deployment options.
> In addition to this we can then provide the current phenix distribution
> starting from this one.
> 
> This way we have a "binaries" distribution and a "phoenix-deployment".

Is this "binary" dist a real distribution for end-users (what would they 
do with it?) or just a build artefact?

   Bernd

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

Re: ext directory [WAS Re: Imap Function]

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> On 8/1/07, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
> 
> <snip>
> 
>>>> In fact it does not build anything from source: it only has to take the
>>>> original SAR, replace the config.xml and add some library.
>>>>
>>>> Maybe the tool (another ant script) would also be useful to people
>>>> downloading the binary distribution (well, in fact it is only a zip
>>>> file, but I saw some user has problems working with it).
>>> i agree that a SAR manipulation tool would be useful for the binary
>>> distribution. IIRC pheonix ships an ant task for this. would need to
>>> think about whether documentation on customisation would be better
>>> than an actual script.
>>>
>>> - robert
>> Maybe it's time to split the sar generation from the phoenix-deployment.
>> This way we could have a module building the sar and another module that
>> takes the sar and place it in the phoenix distribution to create a
>> binary build. The ant script used for this last action could be almost
>> the same used by the binary distribution to create custom sar.
>> I don't know if the api-library-function-deployment layers are enough to
>> do that.
> 
> i suppose the bigger question is how to approach binary distributions
> once JAMES supports multiple containers: do we issue an distribution
> per container or one distribution containing multiple artifacts?
> 
> - robert

Interesting question.

I think that, at the moment, the spring deployment is more developer
oriented than user oriented.

Spring is not a container but a framework and we can compare it to
avalon and not to phoenix. Bernd wrote a simple startup class and not a
full "server" kernel for the spring based solution. We could have
written a simple startup class also for the avalon components (in fact
what Bernd wrote is an avalon-to-spring wrapper and a simple container
for spring, so it is in the end a simple container for avalon applications)

So, currently, I think that the spring deployment option is more about
downloading the right jars and follow documentation for specific use
cases, but the official deployment will remain phoenix for a while.
Developers will probably want to look at the startup method to
understand how to invoke it within their own application and how to get
references to our components so to be able to interact with them.

In the phoenix deployment we bundle everything in a sar, while a spring
distribution would need that jars/xmls exploded.

As a "next step" we could have a "raw" binary distribution including all
of our modules jars and configurations files and the deployment options.
In addition to this we can then provide the current phenix distribution
starting from this one.

This way we have a "binaries" distribution and a "phoenix-deployment".

The more the components will be de-avalonized the more likely we'll move
to different configuration/management options, too.

IMHO in the long terms we will have to keep choosing a single container
for our main distribution while trying to keep core components easy to
be ported to different environments/containers.

I would avoid having an osgi distribution, a spring distribution, a
phoenix distribution, a j2ee distribution a plexus distribution and so
on. This would mean having to test too much environments, having to
provide documentations and support for each one of them: IMHO we won't
be able to afford this in the "near" (1-2 years) future.

Btw, in the end, most of this depends on the community reaction to the
spring support: let's see what they ask and what they do with that
module and we'll know what is better to do in the next release.

Stefano


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

Re: ext directory [WAS Re: Imap Function]

[Robert Burrell Donkin <ro...@gmail.com>]

On 8/1/07, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:

<snip>

> >> In fact it does not build anything from source: it only has to take the
> >> original SAR, replace the config.xml and add some library.
> >>
> >> Maybe the tool (another ant script) would also be useful to people
> >> downloading the binary distribution (well, in fact it is only a zip
> >> file, but I saw some user has problems working with it).
> >
> > i agree that a SAR manipulation tool would be useful for the binary
> > distribution. IIRC pheonix ships an ant task for this. would need to
> > think about whether documentation on customisation would be better
> > than an actual script.
> >
> > - robert
>
> Maybe it's time to split the sar generation from the phoenix-deployment.
> This way we could have a module building the sar and another module that
> takes the sar and place it in the phoenix distribution to create a
> binary build. The ant script used for this last action could be almost
> the same used by the binary distribution to create custom sar.
> I don't know if the api-library-function-deployment layers are enough to
> do that.

i suppose the bigger question is how to approach binary distributions
once JAMES supports multiple containers: do we issue an distribution
per container or one distribution containing multiple artifacts?

- robert

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

Re: ext directory [WAS Re: Imap Function]

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> On 8/1/07, Stefano Bagnara <ap...@bago.org> wrote:
>> Then, wouldn't it be better to have this sar packager also in the binary
>> build?
> 
> i was planning to take the easy route and implement by just adding a
> copy from a directory into the SAR when it's created

Don't worry, I understood this. I suggested the idea because it seemed
more useful to me, and I know you are very comfortable with ant: and
sometimes others have simple solutions to our complex ideas ;-)

>> In fact it does not build anything from source: it only has to take the
>> original SAR, replace the config.xml and add some library.
>>
>> Maybe the tool (another ant script) would also be useful to people
>> downloading the binary distribution (well, in fact it is only a zip
>> file, but I saw some user has problems working with it).
> 
> i agree that a SAR manipulation tool would be useful for the binary
> distribution. IIRC pheonix ships an ant task for this. would need to
> think about whether documentation on customisation would be better
> than an actual script.
> 
> - robert

Maybe it's time to split the sar generation from the phoenix-deployment.
This way we could have a module building the sar and another module that
takes the sar and place it in the phoenix distribution to create a
binary build. The ant script used for this last action could be almost
the same used by the binary distribution to create custom sar.
I don't know if the api-library-function-deployment layers are enough to
do that.

Just another thought out of the box,
Stefano


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

Re: ext directory [WAS Re: Imap Function]

[Robert Burrell Donkin <ro...@gmail.com>]

On 8/1/07, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On 7/31/07, Stefano Bagnara <ap...@bago.org> wrote:
> >> Robert Burrell Donkin ha scritto:
> >>> On 7/31/07, norman <no...@apache.org> wrote:
> >>>> Hi Paulo,
> >>>>
> >>>> I think it whould be enough to put the jars
> >>>> in /path/to/james/apps/james/SAR-INF/lib/ directory ( You need to create
> >>>> the lib after james was started once)
> >>> IMHO it would be useful to have an extensions directory whose contents
> >>> would be automatically copied into the SAR. can anyone think of any
> >>> good reasons for me not to just go ahead and add it to the code?
> >>>
> >>> - robert
> >> What is the use case for this need?
> >>
> >> Ironically I ask this question because adding a folder to be packaged in
> >> the sar was the first thing I did in my local JAMES Server 3 years ago
> >> when I started using it. I then removed it because it did not save me
> >> from any manual task ;-)
> >>
> >> I'm no more able to figure an application of such "directory": whenever
> >> you add a jar you also have to change the config and the config most
> >> time have to be changed in the deployed folder once the sar has been
> >> exploded. When you do this you can also copy the needed jars.
> >
> > ATM to produce a completely configured alternative SAR, the
> > configuration and the build file need to be edited. with an ext
> > directory only the configuration files would need to be altered.
> >
> > - robert
>
> Then, wouldn't it be better to have this sar packager also in the binary
> build?

i was planning to take the easy route and implement by just adding a
copy from a directory into the SAR when it's created

> In fact it does not build anything from source: it only has to take the
> original SAR, replace the config.xml and add some library.
>
> Maybe the tool (another ant script) would also be useful to people
> downloading the binary distribution (well, in fact it is only a zip
> file, but I saw some user has problems working with it).

i agree that a SAR manipulation tool would be useful for the binary
distribution. IIRC pheonix ships an ant task for this. would need to
think about whether documentation on customisation would be better
than an actual script.

- robert

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

Re: ext directory [WAS Re: Imap Function]

[Stefano Bagnara <ap...@bago.org>]

Paulo Sergio ha scritto:
> thanks for the answers
> 
> the automated process would copy all the external files and build the binary
> distribution using the new jars.
> but i can change only the build.xml file to include my jars file.. but where
> in the sar should i put the jars, so that when deployed they stay at
> /path/to/james/apps/james/SAR-INF/lib/ ?

There is no way to obtain this: SAR-INF/lib in the deployed directory
structure for phoenix is an extension folder and is not where
sarfile/SAR-INF/lib files end up.
They are copied to the work dir and are anyway present in your
classpath, so there is no need to search them in the SAR-INF/lib folder.

Stefano



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

Re: ext directory [WAS Re: Imap Function]

[Paulo Sergio <pa...@gmail.com>]

thanks for the answers

the automated process would copy all the external files and build the binary
distribution using the new jars.
but i can change only the build.xml file to include my jars file.. but where
in the sar should i put the jars, so that when deployed they stay at
/path/to/james/apps/james/SAR-INF/lib/ ?

Cheers,
Paulo F.

On 8/1/07, Stefano Bagnara <apache@bago.org > wrote:
>
> Robert Burrell Donkin ha scritto:
> > On 7/31/07, Stefano Bagnara < apache@bago.org> wrote:
> >> Robert Burrell Donkin ha scritto:
> >>> On 7/31/07, norman < norman@apache.org> wrote:
> >>>> Hi Paulo,
> >>>>
> >>>> I think it whould be enough to put the jars
> >>>> in /path/to/james/apps/james/SAR-INF/lib/ directory ( You need to
> create
> >>>> the lib after james was started once)
> >>> IMHO it would be useful to have an extensions directory whose contents
>
> >>> would be automatically copied into the SAR. can anyone think of any
> >>> good reasons for me not to just go ahead and add it to the code?
> >>>
> >>> - robert
> >> What is the use case for this need?
> >>
> >> Ironically I ask this question because adding a folder to be packaged
> in
> >> the sar was the first thing I did in my local JAMES Server 3 years ago
> >> when I started using it. I then removed it because it did not save me
> >> from any manual task ;-)
> >>
> >> I'm no more able to figure an application of such "directory": whenever
> >> you add a jar you also have to change the config and the config most
> >> time have to be changed in the deployed folder once the sar has been
> >> exploded. When you do this you can also copy the needed jars.
> >
> > ATM to produce a completely configured alternative SAR, the
> > configuration and the build file need to be edited. with an ext
> > directory only the configuration files would need to be altered.
> >
> > - robert
>
> Then, wouldn't it be better to have this sar packager also in the binary
> build?
>
> In fact it does not build anything from source: it only has to take the
> original SAR, replace the config.xml and add some library.
>
> Maybe the tool (another ant script) would also be useful to people
> downloading the binary distribution (well, in fact it is only a zip
> file, but I saw some user has problems working with it).
>
> This is not an argument against the folder, just my 2 cents about the
> issue being analyzed.
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>

Re: ext directory [WAS Re: Imap Function]

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> On 7/31/07, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On 7/31/07, norman <no...@apache.org> wrote:
>>>> Hi Paulo,
>>>>
>>>> I think it whould be enough to put the jars
>>>> in /path/to/james/apps/james/SAR-INF/lib/ directory ( You need to create
>>>> the lib after james was started once)
>>> IMHO it would be useful to have an extensions directory whose contents
>>> would be automatically copied into the SAR. can anyone think of any
>>> good reasons for me not to just go ahead and add it to the code?
>>>
>>> - robert
>> What is the use case for this need?
>>
>> Ironically I ask this question because adding a folder to be packaged in
>> the sar was the first thing I did in my local JAMES Server 3 years ago
>> when I started using it. I then removed it because it did not save me
>> from any manual task ;-)
>>
>> I'm no more able to figure an application of such "directory": whenever
>> you add a jar you also have to change the config and the config most
>> time have to be changed in the deployed folder once the sar has been
>> exploded. When you do this you can also copy the needed jars.
> 
> ATM to produce a completely configured alternative SAR, the
> configuration and the build file need to be edited. with an ext
> directory only the configuration files would need to be altered.
> 
> - robert

Then, wouldn't it be better to have this sar packager also in the binary
build?

In fact it does not build anything from source: it only has to take the
original SAR, replace the config.xml and add some library.

Maybe the tool (another ant script) would also be useful to people
downloading the binary distribution (well, in fact it is only a zip
file, but I saw some user has problems working with it).

This is not an argument against the folder, just my 2 cents about the
issue being analyzed.

Stefano


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

Re: ext directory [WAS Re: Imap Function]

[Robert Burrell Donkin <ro...@gmail.com>]

On 7/31/07, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On 7/31/07, norman <no...@apache.org> wrote:
> >> Hi Paulo,
> >>
> >> I think it whould be enough to put the jars
> >> in /path/to/james/apps/james/SAR-INF/lib/ directory ( You need to create
> >> the lib after james was started once)
> >
> > IMHO it would be useful to have an extensions directory whose contents
> > would be automatically copied into the SAR. can anyone think of any
> > good reasons for me not to just go ahead and add it to the code?
> >
> > - robert
>
> What is the use case for this need?
>
> Ironically I ask this question because adding a folder to be packaged in
> the sar was the first thing I did in my local JAMES Server 3 years ago
> when I started using it. I then removed it because it did not save me
> from any manual task ;-)
>
> I'm no more able to figure an application of such "directory": whenever
> you add a jar you also have to change the config and the config most
> time have to be changed in the deployed folder once the sar has been
> exploded. When you do this you can also copy the needed jars.

ATM to produce a completely configured alternative SAR, the
configuration and the build file need to be edited. with an ext
directory only the configuration files would need to be altered.

- robert

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

Re: ext directory [WAS Re: Imap Function]

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> On 7/31/07, norman <no...@apache.org> wrote:
>> Hi Paulo,
>>
>> I think it whould be enough to put the jars
>> in /path/to/james/apps/james/SAR-INF/lib/ directory ( You need to create
>> the lib after james was started once)
> 
> IMHO it would be useful to have an extensions directory whose contents
> would be automatically copied into the SAR. can anyone think of any
> good reasons for me not to just go ahead and add it to the code?
> 
> - robert

What is the use case for this need?

Ironically I ask this question because adding a folder to be packaged in
the sar was the first thing I did in my local JAMES Server 3 years ago
when I started using it. I then removed it because it did not save me
from any manual task ;-)

I'm no more able to figure an application of such "directory": whenever
you add a jar you also have to change the config and the config most
time have to be changed in the deployed folder once the sar has been
exploded. When you do this you can also copy the needed jars.

Stefano


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

Re: ext directory [WAS Re: Imap Function]

[Robert Burrell Donkin <ro...@gmail.com>]

On 7/31/07, Paulo Sergio <pa...@gmail.com> wrote:
> On 7/31/07, Robert Burrell Donkin <ro...@gmail.com> wrote:
> >
> > On 7/31/07, norman <no...@apache.org> wrote:
> > > Hi Paulo,
> > >
> > > I think it whould be enough to put the jars
> > > in /path/to/james/apps/james/SAR-INF/lib/ directory ( You need to create
> > > the lib after james was started once)
> >
> > IMHO it would be useful to have an extensions directory whose contents
> > would be automatically copied into the SAR.
>
>
> i was just about to ask if there was another way to put the jar files
> automatically on the SAR ..

i don't know of any automatic ways but you could manually alter the
sar target in the build.xml in pheonix-deployment

- robert

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

Re: ext directory [WAS Re: Imap Function]

[Paulo Sergio <pa...@gmail.com>]

On 7/31/07, Robert Burrell Donkin <ro...@gmail.com> wrote:
>
> On 7/31/07, norman <no...@apache.org> wrote:
> > Hi Paulo,
> >
> > I think it whould be enough to put the jars
> > in /path/to/james/apps/james/SAR-INF/lib/ directory ( You need to create
> > the lib after james was started once)
>
> IMHO it would be useful to have an extensions directory whose contents
> would be automatically copied into the SAR.


i was just about to ask if there was another way to put the jar files
automatically on the SAR ..

can anyone think of any
> good reasons for me not to just go ahead and add it to the code?



i have no reasons to stop you.. :)

Thanks...

Paulo F.

- robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>