You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Serge Knystautas <se...@lokitech.com> on 2003/10/29 16:45:29 UTC
Merging plan (was Build process in maven?)
Noel J. Bergman wrote:
>>Really the biggest hurdle is a stable Avalon release. :)
>
> I would use the latest release packages from Avalon, and once we get merged,
> I think it makes sense for Stephen to add configuration files for a James
> package using Merlin as well as our Phoenix packaging.
So to just get to a merged 3.0 release, we could do the following:
1. Move to latest release packages from Avalon.
2. Discuss and resolve the mailet API changes.
3. Address any discrepancies (code changes only applied to one or other,
or otherwise require resolution).
Anything else?
Comments on feasibility:
If we have final releases from Avalon, then 1 is doable.
I think we have some consensus about 2... we originally were planning
more sweeping changes and include repository changes, but I don't know
if that is appropriate since we're still stuck on the IMAP changes.
Then 3 is just thankless grunt work.
--
Serge Knystautas
President
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
Re: Merging plan (was Build process in maven?)
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>Excalibur IO is depricated in favour of Commons IO. However, the
>>cornerstone-store package used a number of IO utilities not available
>>within the commons-io package
>>
>>
>
>So we need commons-io,
>
No - you don't need commons-io (I just mentioned that Excalibur IO
was depricated in favour of Commons-IO).
>plus the additional set of classes necessary to
>support Cornerstone Store, and you've moved the latter into the store
>implementation package.
>
Yep - for example - you have references to IOUtil. I chose to include a
copy inside Store in order to eliminate the issue. You could perhaps
include a copioes of the sources in james/util.
>
>
>
>>Keeping in mind that thought the cornerstone release process
>>I was paying a lot of attention to James and implications of
>>what I was doing
>>
>>
>
>And we thank you. :-)
>
>
>
>>However, doing a quick check its sems that a few others Excalibur io
>>classes were either missed by me or have crept into the NNTP package
>>
>>
>
>NNTP hasn't been changed in more than 6 months.
>
>
Then I missed it.
(or I spotted it but figured it was resolvable)
>>No problem - the sources for these are in avalon-excalibur/compatibility
>>so copying them locally into James should not be a problem.
>>
>>
>
>So you propose to move them into org.apache.james.util.io?
>
That's what I would do - just the classes you need. If you do a quick
scan for excalibur.io you will find about 7 or 8 utility classes that
are used across all of James. None of them are terribly interesting (or
at least I didn't find them terribly interesting) - and they seem to be
used internally within implementations.
Steve.
>
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Merging plan (was Build process in maven?)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Excalibur IO is depricated in favour of Commons IO. However, the
> cornerstone-store package used a number of IO utilities not available
> within the commons-io package
So we need commons-io, plus the additional set of classes necessary to
support Cornerstone Store, and you've moved the latter into the store
implementation package.
> Keeping in mind that thought the cornerstone release process
> I was paying a lot of attention to James and implications of
> what I was doing
And we thank you. :-)
> However, doing a quick check its sems that a few others Excalibur io
> classes were either missed by me or have crept into the NNTP package
NNTP hasn't been changed in more than 6 months.
> No problem - the sources for these are in avalon-excalibur/compatibility
> so copying them locally into James should not be a problem.
So you propose to move them into org.apache.james.util.io?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Merging plan (was Build process in maven?)
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>Everything from Avalon on which James is dependent has gone though an
>>official release.
>>
>>
>
>Your list (Freudian slip? :-)) is missing Phoenix, although I believe that
>there is a release later than we are using.
>
Woops!
Honestly - it just didn't occur to me.
Possibly Freudian.
>
>I assume that all of the new ones are currently in our MAIN branch?
>
>
Yep.
>
>
>>James is currently using the depricated Excalibur IO package. When
>>preparing the cornerstone relases I merged some of the utility
>>classes so that you would have a drop dead easy migration solution.
>>
>
>Remind me what happened to those.
>
I have to remind myself. Here is a scatch (because it was a while ago).
Excalibur IO is depricated in favour of Commons IO. However, the
cornerstone-store package used a number of IO utilities not available
within the commons-io package (IOUtil, ExtensionFileFilter,
ClassLoaderObjectInputStream and ResettableFileInputStream). So what
I did was to move these classes into the cornerstone-store impl package
under org.apache.avalon.cornerstone.blocks.masterstore and eliminated
the Excalibur IO dependency. Keeping in mind that thought the
cornerstone release process I was paying a lot of attention to James
and implications of what I was doing and from memory I made sure that
everything was covered in terms of classes I imported into the store
package.
However, doing a quick check its sems that a few others Excalibur io
classes were either missed by me or have crept into the NNTP package:
AndFileFilter
InvertedFileFilter
DirectoryFileFilter
No problem - the sources for these are in avalon-excalibur/compatibility
so copying them locally into James should not be a problem.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Merging plan (was Build process in maven?)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Everything from Avalon on which James is dependent has gone though an
> official release.
Your list (Freudian slip? :-)) is missing Phoenix, although I believe that
there is a release later than we are using.
I assume that all of the new ones are currently in our MAIN branch?
> James is currently using the depricated Excalibur IO package. When
> preparing the cornerstone relases I merged some of the utility
> classes so that you would have a drop dead easy migration solution.
Remind me what happened to those.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Merging plan (was Build process in maven?)
Posted by Stephen McConnell <mc...@apache.org>.
Serge Knystautas wrote:
> Noel J. Bergman wrote:
>
>>> Really the biggest hurdle is a stable Avalon release. :)
>>
>>
>> I would use the latest release packages from Avalon, and once we get
>> merged,
>> I think it makes sense for Stephen to add configuration files for a
>> James
>> package using Merlin as well as our Phoenix packaging.
>
>
> So to just get to a merged 3.0 release, we could do the following:
> 1. Move to latest release packages from Avalon.
> 2. Discuss and resolve the mailet API changes.
> 3. Address any discrepancies (code changes only applied to one or
> other, or otherwise require resolution).
>
> Anything else?
>
> Comments on feasibility:
> If we have final releases from Avalon, then 1 is doable.
Everything from Avalon on which James is dependent has gone though an
official release.
avalon-framework 4.1.5 (api & impl)
cornerstone-threads 1.0 (api & impl)
cornerstone-sockets 1.0 (api & impl)
cornerstone-connection 1.0 (api & impl)
cornerstone-scheduler 1.0 (api & impl)
cornerstone-datasources 1.0 (api & impl)
cornerstone-store 1.0 (api & impl)
excalibur-collections 1.0 (single)
excalibur-thread 1.1.1 (single)
excalibur-pool 1.2 (single)
excalibur-datasource-1.1.1 (single)
James is currently using the depricated Excalibur IO package. When
preparing the cornerstone
relases I merged some of the utility classes so that you would have a
drop dead easy migration
solution. I'll need to dig back into cornerstone to clarify that (but
its a minor point).
Cheers, Steve.
>
>
> I think we have some consensus about 2... we originally were planning
> more sweeping changes and include repository changes, but I don't know
> if that is appropriate since we're still stuck on the IMAP changes.
>
> Then 3 is just thankless grunt work.
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Merging plan (was Build process in maven?)
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>2. Do an api/impl split (which will make me happy)
>>
>
>Where do you see that we don't?
>
[warning - I'm probably rambling]
I'm talking about a physical split that would result in the following
artifacts:
* james-server-api-VERSION.jar
* james-server-impl-VERSION.jar
* james-mailet-api-VERSION.jar
* james-mailet-impl-VERSION.jar
There is a really big benefit in doing this seperation when looking at
how James can be used within "composite components". Lets assume that we
have classic James executing within a classloader - but instead of
thinking about James as a standalone server - think of James as just
another component. In such a scenario it is handling requests across
ports, but also providing a service to other consumer components. Those
services could be represented by James exposing the mailet interface, or
perhaps enabling a user repository to be shared between multiple
components (e.g. both James and OpenIM). These scenarios reflect a
requirement for the API classes to be in a classloader common to the
provider and consumer classloaders. If you have a single jar file
containing both api and impl - then your James implementation classes
must be declared way up hight in the classloader heirachy. Worse still
is the fact that all of the jar files that James requires must be
declared in the same or higher classloader. On the otherhand, if you
seperate you project into two seperate project - api and impl - then the
only classes you need to expose to a client is the API. The
implementation classes stay down with James.
End result is that it is massively easier to wire together components.
There are some open questions here. James has a mailet API and a
non-published internal services API. Lets ignore the question about
what is intended to be public for a moment and think about what is
happening inside Merlin. Basically merlin is wiring together service
providers (such as the DNS provider, the POP3 server, the SNTP server,
etc. in order to establish the James server component. Lets asume we
want to experiment with a shared user repository - i.e. a component that
will provide some generic facilities for managing user accounts - and
that we expect this facilities to be used by James and other components
(e.g. OpenIM). In this scenario both the James and OpenIM
implementation needs the user repository APIs - but the implementation
classes can be pushed down into the classloader running the actual
repository.
End result is that it become rather simple to build new componets from
existing components - and technically feasiblke to dynamically rewire
components over a management inerface.
If you throw into the equation an interest in build James using Maven,
then there is an implication of the physical structure of the source
repository. A maven project is basically geared around the creation of
a single artifact - e.g. james-server-impl-3.0.jar. I.e. you end up with
a lot of subprojects. The upside is that things like unit testing are
much more fine grained - version control and dependency management
become much more tangible, etc.
Now - in the James case, there are a bunch of subcomponents - each with
a potential api and impl project.
* James
* AvalonMailStore
* AvalonUserStore
* DNSServer
* FetchScheduler
* RepositoryManager
* NNTPServer
* NNTPRepositoryImpl
* POP3Server
* RemoteManager
* SMTPServer
* JamesSpoolManager
* SimpleConnectionManager
As you know - I'm not that familiar with the internals of James - but I
would guess that from the above you could probably break James down into
a number of sub-systems:
* Mailet/James (mailet api and the james impl and mail store, etc.)
* user repository and remote access
* DNS
* Fetch
* NNTP
* POP3
* SMTP
What I'm trying to in the above list is identify what are the seperate
functional testable potentially sharable components with the broader
james system. I'm not suggesting that these become publically available
services - but I am suggesting that when you consider James as just a
component - you stand to gain a lot by disecting its composition and
putting in place (a) a build model that provides good granularity on
testing and isolation of development effort, and that can be trnslated
into (b) a good composition scheme when considering the potential for
new subsystems (e.g. an LDAP user repository), or sub-system reuse (e.g.
a shared user repository).
If you take a look at avalon-framework, the meta package, and any of the
cornerstone components you will find a seperate api and impl project
(and in some cases an spi project). The Merlin build example is
probably closer to what I figure James should be - i.e. a collection of
4-6 packages, each with a seperate api and implementation subproject.
Although this may sound complex - it is actually rather simple to
adminster. You can automate the build process to include unit testing
across all subsystems, automate the generation of the final application
solution, maintain a clean seperation between James and a deployment
environment (container), etc.
>I'm not saying that there aren't such
>cases, but I'm curious as to what you see as concerns.
>
More "opportunity" than concern. Getting a breakout of james into its
component parts would make things easier for people like me to
understand what is related to what - would enable better management of
test cases, and I think would provide more flexibility for the future.
I don't know if you have looking into the ant build script in MAIN
recently but its basically generating a mailet-api, mailet-impl and
james jar files (but its a hack by yours-truly) and I would sleep better
at night if we get rid of the hack!
>>3. Use the AbstractMerlinTestCase to deploy james in a container with
>> services accessible to your unit test - you unit test would only
>> need two dependency declarations - mailet API and the merlin test
>> case.
>>
>>
>
>Nice. I do suggest (as I mentioned in a message a few moments ago), that
>you and Steve Brewin collaborate on getting BSF support. That would make
>testing easier.
>
>
Will do.
Cheers, Steve.
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Merging plan (was Build process in maven?)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 2. Do an api/impl split (which will make me happy)
Where do you see that we don't? I'm not saying that there aren't such
cases, but I'm curious as to what you see as concerns.
> 3. Use the AbstractMerlinTestCase to deploy james in a container with
> services accessible to your unit test - you unit test would only
> need two dependecy declarations - mailet API and the merlin test
> case.
Nice. I do suggest (as I mentioned in a message a few moments ago), that
you and Steve Brewin collaborate on getting BSF support. That would make
testing easier.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Merging plan (was Build process in maven?)
Posted by Stephen McConnell <mc...@apache.org>.
Serge Knystautas wrote:
>
> I think that will be messy since there has been so much changes on
> each, but I don't have a better suggestion. grunt grunt grunt.
>
> This really could expose our Archiles heel though, which is a lack of
> adequate testing to make sure the merged version works well. Have we
> made any progress/thoughts on how to automate testing?
1. Migrate to Maven (which I can help with)
2. Do an api/impl split (which will make me happy)
3. Use the AbstractMerlinTestCase to deploy james in a container with
services accessible to your unit test - you unit test would only
neew two dependecy declarations - mailet API and the merlin test
case. You can structure the deployment scenario to expose whatever
services are needed for the test (e.g. Mailet, or RemoteAdmin or
or whatever). Behind the scenes its no different to running up
James as an NT service - same system - just a different embedding
scenario.
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Merging plan (was Build process in maven?)
Posted by Shash Chatterjee <sh...@badfw.org>.
Minor typo with major impact: I meant BSF not BSH. Sorry!
Shash Chatterjee wrote:
> If it is useful for anybody, in Keel (http://www.keelframework.org) we
> have an Avalon script service, with two implementations of the service
> interface: Jelly and BSH (I have tested JavaScript, NetRexx, and TCL). I
> have attached the service interface.
>
> This interface (as I would expect other similar services to do), exposes
> arbitrary objects to the underlying script engine. Leo's concern in a
> separate post about the script causing havoc is very valid, depends on
> what is exposed!
>
> On a separate but related topic, we seem to have the same needs and
> also reinventing the wheel, given the number of Jelly service
> implementations we have. This is at least one of the major issues that
> COP was intended to solve, or so I thought! We talk about component
> repositories, but I think something that might help is an Avalon/Apache
> hosted project of Avalon service interfaces (roles), that could then be
> augmented with a directory that would point to all the available
> implementations. There are a plethora of "lightweight" IOC containers
> that can manage different components with varied configuration (i.e.
> instantiate a bean, provide different config to each instance), which
> Avalon can do as well. But Avalon containers are among a much smaller
> set that allow looking up of multiple implementations of the same
> interface, as well as configuring them differently. We should take more
> advantage of that, and avoid 1:1 relationships of
> interfaces/implementations.
>
> Shash
>
> Stephen McConnell wrote:
>
>>
>>
>> David Worms wrote:
>>
>>> I have an updated version of jelly working inside Merlin. I'll be
>>> happy to share it. From what I remember, I haven't changed the code,
>>> just added meta information, separated in to maven project (api/impl)
>>> and added a simple test to it.
>>
>>
>>
>>
>> How about we put it in the sandbox?
>> I'd like to take a loook at it.
>>
>> Steve.
>>
>
>
> ------------------------------------------------------------------------
>
> /*
> * Copyright (c) 2002, The Keel Group, Ltd. All rights reserved.
> *
> * This software is made available under the terms of the license found
> * in the LICENSE file, included with this source code. The license can
> * also be found at:
> * http://www.keelframework.net/LICENSE
> */
> package org.keel.services.script;
>
> /**
> * This is the interface for services that are able to execute some form
> * of an interpreted scripting language. Java objects can be passed
> * to the script from Keel services, and visa-versa.
> *
> * @version $Revision: 1.2 $ $Date: 2003/07/03 15:49:32 $
> * @author Shash Chatterjee
> * Created on Jun 14, 2003
> */
> public interface Script {
>
> /**
> * The Avalon role name for the Script service
> */
> public static String ROLE = Script.class.getName();
>
> /**
> * Expose a Java object to the script context
> * @param o The object to expose
> * @param name The name the object will be referred to by
> * @throws ScriptException Error when the object cannot be exposed
> */
> public void expose(Object o, String name) throws ScriptException;
>
> /**
> * Expose a java object to the script context, with a scoped name
> * @param o The object to expose
> * @param name The name the object will be referred to by
> * @param scope The scope for the name
> * @throws ScriptException Error when the object cannot be exposed
> */
> public void expose(Object o, String name, String scope) throws ScriptException;
>
> /**
> * Get an object from the script context
> * @param name The name of the object to retrieve
> * @return The retrieved object
> * @throws ScriptException Error when the object cannot be retrieved
> */
> public Object retrieve(String name) throws ScriptException;
>
> /**
> * Get an object from the script context, with a scoped name
> * @param name The name of the object to retrieve
> * @param scope The scope for the name
> * @return The retrieved object
> * @throws ScriptException Error when the object cannot be retrieved
> */
> public Object retrieve(String name, String scope) throws ScriptException;
>
> /**
> * Delete an object from the script context
> * @param name The name of the object to delete
> * @throws ScriptException Error when the object cannot be deleted
> */
> public void remove(String name) throws ScriptException;
>
> /**
> * Delete an object from the script context, with a scoped name
> * @param name The name of the object to delete
> * @param scope The scope for the name
> * @throws ScriptException Error when the object cannot be deleted
> */
> public void remove(String name, String scope) throws ScriptException;
>
> /**
> * Run the script in the named file
> * @param script The file name of the script
> * @throws ScriptException Error from the scripting engine
> */
> public void execute(String script) throws ScriptException ;
>
> }
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Merging plan (was Build process in maven?)
Posted by Shash Chatterjee <sh...@badfw.org>.
If it is useful for anybody, in Keel (http://www.keelframework.org) we
have an Avalon script service, with two implementations of the service
interface: Jelly and BSH (I have tested JavaScript, NetRexx, and TCL).
I have attached the service interface.
This interface (as I would expect other similar services to do), exposes
arbitrary objects to the underlying script engine. Leo's concern in a
separate post about the script causing havoc is very valid, depends on
what is exposed!
On a separate but related topic, we seem to have the same needs and
also reinventing the wheel, given the number of Jelly service
implementations we have. This is at least one of the major issues that
COP was intended to solve, or so I thought! We talk about component
repositories, but I think something that might help is an Avalon/Apache
hosted project of Avalon service interfaces (roles), that could then be
augmented with a directory that would point to all the available
implementations. There are a plethora of "lightweight" IOC containers
that can manage different components with varied configuration (i.e.
instantiate a bean, provide different config to each instance), which
Avalon can do as well. But Avalon containers are among a much smaller
set that allow looking up of multiple implementations of the same
interface, as well as configuring them differently. We should take more
advantage of that, and avoid 1:1 relationships of
interfaces/implementations.
Shash
Stephen McConnell wrote:
>
>
> David Worms wrote:
>
>> I have an updated version of jelly working inside Merlin. I'll be
>> happy to share it. From what I remember, I haven't changed the code,
>> just added meta information, separated in to maven project (api/impl)
>> and added a simple test to it.
>
>
>
> How about we put it in the sandbox?
> I'd like to take a loook at it.
>
> Steve.
>
Re: Merging plan (was Build process in maven?)
Posted by David Worms <da...@simpledesign.com>.
I just posted the service/implementation of Jelly:
http://www.abile.net/temp/jelly.zip
d.
On Wednesday, November 5, 2003, at 04:36 AM, Stephen McConnell wrote:
>
>
> David Worms wrote:
>
>> I have an updated version of jelly working inside Merlin. I'll be
>> happy to share it. From what I remember, I haven't changed the code,
>> just added meta information, separated in to maven project (api/impl)
>> and added a simple test to it.
>
>
> How about we put it in the sandbox?
> I'd like to take a loook at it.
>
> Steve.
>
> --
>
> Stephen J. McConnell
> mailto:mcconnell@apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Merging plan (was Build process in maven?)
Posted by Stephen McConnell <mc...@apache.org>.
David Worms wrote:
> I have an updated version of jelly working inside Merlin. I'll be
> happy to share it. From what I remember, I haven't changed the code,
> just added meta information, separated in to maven project (api/impl)
> and added a simple test to it.
How about we put it in the sandbox?
I'd like to take a loook at it.
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Merging plan (was Build process in maven?)
Posted by David Worms <da...@simpledesign.com>.
I have an updated version of jelly working inside Merlin. I'll be happy
to share it. From what I remember, I haven't changed the code, just
added meta information, separated in to maven project (api/impl) and
added a simple test to it.
d.
On Tuesday, November 4, 2003, at 07:58 PM, J Aaron Farr wrote:
>
>
> On Tue, 2003-11-04 at 23:02, Stephen McConnell wrote:
>
>>>
>>>> Just the sort of thing I should be adding to the JIRA roadmap for
>>>> Merlin!
>
> Agreed. I can't wait for JIRA roadmaps for Avalon. :)
>
>>>
>>> NEWS FLASH From Colorado Software Summit! It exists! Dion Gillard's
>>> presentation on Jelly noted to major things:
>>>
>>> 1) There is an Avalon Service for integrating Jelly
>>> into an Avalon container.
>>>
>>> 2) Jelly also has support for delegating to BSF.
>>>
>>> This means that you could pickup the Jelly service for Merlin, and
>>> integrate
>>> it at a deep level so that we can use it for component testing,
>>> using Jelly,
>>> BSF supported languages, etc.
>>>
>>> Right now the Avalon Jelly service is in Jelly's CVS module (Jakarta
>>> Commons). Depending upon what you need to do it to (I haven't
>>> looked),
>>> perhaps you might want to talk about adopting it officially into the
>>> Avalon
>>> project.
>>>
>>> --- Noel
>
> I thought about doing a generic Jelly service, but it was such a back
> burner issue I never had time to do it. This could be really cool!
>
> Couldn't this be used for some of the scriptable components Leo was
> interested in?
>
> --
> jaaron <http://jadetower.org>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Merging plan (was Build process in maven?)
Posted by J Aaron Farr <fa...@apache.org>.
On Tue, 2003-11-04 at 23:02, Stephen McConnell wrote:
> >
> >>Just the sort of thing I should be adding to the JIRA roadmap for Merlin!
Agreed. I can't wait for JIRA roadmaps for Avalon. :)
> >
> >NEWS FLASH From Colorado Software Summit! It exists! Dion Gillard's
> >presentation on Jelly noted to major things:
> >
> > 1) There is an Avalon Service for integrating Jelly
> > into an Avalon container.
> >
> > 2) Jelly also has support for delegating to BSF.
> >
> >This means that you could pickup the Jelly service for Merlin, and integrate
> >it at a deep level so that we can use it for component testing, using Jelly,
> >BSF supported languages, etc.
> >
> >Right now the Avalon Jelly service is in Jelly's CVS module (Jakarta
> >Commons). Depending upon what you need to do it to (I haven't looked),
> >perhaps you might want to talk about adopting it officially into the Avalon
> >project.
> >
> > --- Noel
I thought about doing a generic Jelly service, but it was such a back
burner issue I never had time to do it. This could be really cool!
Couldn't this be used for some of the scriptable components Leo was
interested in?
--
jaaron <http://jadetower.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Merging plan (was Build process in maven?)
Posted by Stephen McConnell <mc...@apache.org>.
Noel:
I'm cc'ing Avalon dev. Perhaps we can try to get some assistance
on this - after all, the upside is certainly interesting.
Stephen.
Noel J. Bergman wrote:
>Stephen McConnell wrote:
>
>
>>Noel J. Bergman wrote:
>>
>>
>
>
>
>>>>But something I'm still not clear on. Under a unit test
>>>>the BSF mailet would be declared under the James
>>>>configuration.
>>>>
>>>>
>
>
>
>>>I was just using those matchers as examples. For testing, I think you
>>>
>>>
>want
>
>
>>>to have similar code available within Merlin, itself, able to access
>>>whatever needs testing. Basically, able to script *Merlin*! You could
>>>develop test scripts for Merlin, not just applications contained within
>>>Merlin.
>>>
>>>
>
>
>
>>Just the sort of thing I should be adding to the JIRA roadmap for Merlin!
>>
>>
>
>NEWS FLASH From Colorado Software Summit! It exists! Dion Gillard's
>presentation on Jelly noted to major things:
>
> 1) There is an Avalon Service for integrating Jelly
> into an Avalon container.
>
> 2) Jelly also has support for delegating to BSF.
>
>This means that you could pickup the Jelly service for Merlin, and integrate
>it at a deep level so that we can use it for component testing, using Jelly,
>BSF supported languages, etc.
>
>Right now the Avalon Jelly service is in Jelly's CVS module (Jakarta
>Commons). Depending upon what you need to do it to (I haven't looked),
>perhaps you might want to talk about adopting it officially into the Avalon
>project.
>
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Merging plan (was Build process in maven?)
Posted by Stephen McConnell <mc...@apache.org>.
Noel:
I'm cc'ing Avalon dev. Perhaps we can try to get some assistance
on this - after all, the upside is certainly interesting.
Stephen.
Noel J. Bergman wrote:
>Stephen McConnell wrote:
>
>
>>Noel J. Bergman wrote:
>>
>>
>
>
>
>>>>But something I'm still not clear on. Under a unit test
>>>>the BSF mailet would be declared under the James
>>>>configuration.
>>>>
>>>>
>
>
>
>>>I was just using those matchers as examples. For testing, I think you
>>>
>>>
>want
>
>
>>>to have similar code available within Merlin, itself, able to access
>>>whatever needs testing. Basically, able to script *Merlin*! You could
>>>develop test scripts for Merlin, not just applications contained within
>>>Merlin.
>>>
>>>
>
>
>
>>Just the sort of thing I should be adding to the JIRA roadmap for Merlin!
>>
>>
>
>NEWS FLASH From Colorado Software Summit! It exists! Dion Gillard's
>presentation on Jelly noted to major things:
>
> 1) There is an Avalon Service for integrating Jelly
> into an Avalon container.
>
> 2) Jelly also has support for delegating to BSF.
>
>This means that you could pickup the Jelly service for Merlin, and integrate
>it at a deep level so that we can use it for component testing, using Jelly,
>BSF supported languages, etc.
>
>Right now the Avalon Jelly service is in Jelly's CVS module (Jakarta
>Commons). Depending upon what you need to do it to (I haven't looked),
>perhaps you might want to talk about adopting it officially into the Avalon
>project.
>
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Merging plan (was Build process in maven?)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stephen McConnell wrote:
> Noel J. Bergman wrote:
>>>But something I'm still not clear on. Under a unit test
>>>the BSF mailet would be declared under the James
>>>configuration.
>>I was just using those matchers as examples. For testing, I think you
want
>>to have similar code available within Merlin, itself, able to access
>>whatever needs testing. Basically, able to script *Merlin*! You could
>>develop test scripts for Merlin, not just applications contained within
>>Merlin.
> Just the sort of thing I should be adding to the JIRA roadmap for Merlin!
NEWS FLASH From Colorado Software Summit! It exists! Dion Gillard's
presentation on Jelly noted to major things:
1) There is an Avalon Service for integrating Jelly
into an Avalon container.
2) Jelly also has support for delegating to BSF.
This means that you could pickup the Jelly service for Merlin, and integrate
it at a deep level so that we can use it for component testing, using Jelly,
BSF supported languages, etc.
Right now the Avalon Jelly service is in Jelly's CVS module (Jakarta
Commons). Depending upon what you need to do it to (I haven't looked),
perhaps you might want to talk about adopting it officially into the Avalon
project.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Merging plan (was Build process in maven?)
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>But something I'm still not clear on. Under a unit test
>>the BSF mailet would be declared under the James
>>configuration.
>>
>>
>
>I was just using those matchers as examples. For testing, I think you want
>to have similar code available within Merlin, itself, able to access
>whatever needs testing. Basically, able to script *Merlin*! You could
>develop test scripts for Merlin, not just applications contained within
>Merlin.
>
Just the sort of thing I should be adding to the JIRA roadmap for Merlin!
:-)
>
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Merging plan (was Build process in maven?)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> But something I'm still not clear on. Under a unit test
> the BSF mailet would be declared under the James
> configuration.
I was just using those matchers as examples. For testing, I think you want
to have similar code available within Merlin, itself, able to access
whatever needs testing. Basically, able to script *Merlin*! You could
develop test scripts for Merlin, not just applications contained within
Merlin.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Merging plan (was Build process in maven?)
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>Can you fill me in on BSF?
>>
>>
>
>I'm not Steve, but ...
>
> http://jakarta.apache.org/bsf/
>
>Also:
>http://nagoya.apache.org/eyebrowse/ReadMsg?listName=james-dev@jakarta.apache.org&msgNo=9147
>
>That has a BSF matcher and a BSF mailet written by Steve. We want to get
>them into v3.
>
Thanks - penny has dropped. But something I'm still not clear on. Under
a unit test the BSF mailet would be declared under the James
configuration. Presumably the mailet will read a test-script and make
stuff happen. But this doesn't tie in with JUnit as such. In fact you
could do this sort of testing from the command line. To tie this into
JUnit would require that the unit test can invoke specific requests
against a service and the invokation would return predictable values
that we feedback into junit reports etc. This would suggest that the
mailet instance is accessible to the unit test class. Is that possible?
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Merging plan (was Build process in maven?)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Can you fill me in on BSF?
I'm not Steve, but ...
http://jakarta.apache.org/bsf/
Also:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=james-dev@jakarta.apache
.org&msgNo=9147
That has a BSF matcher and a BSF mailet written by Steve. We want to get
them into v3.
In terms of what I'm proposing, think of Phoenix's support for BeanShell,
but better (and supporting multiple languages).
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Merging plan (was Build process in maven?)
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>
>As for formal testing, we still don't have much. Bench and live testing,
>basically. For example, when I get home, I'll test Soren's patch by setting
>up a schedule, and sending mail to a dead gateway. I don't know what Avalon
>has done in terms of facilitating component testing. Stephen and Steve
>might want to talk about incorporating BSF with Merlin to allow BSF scripts
>to drive tests.
>
Steve:
Can you fill me in on BSF?
Stephen.
>
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Merging plan (was Build process in maven?)
Posted by "Noel J. Bergman" <no...@devtech.com>.
>>> So to just get to a merged 3.0 release, we could do the following
>> Are you proposing that what is currently v2.2.0 test builds be
>> released as v3?
> Err, no... I mean merge from a codebase perspective, not overwrite.
> Feature-wise, I don't believe there is much in 3.0 that isn't in 2.2.
IMAP. Jason is working on changes to use the current repository technology
with a naming convention for folders. User attributes. A lot of the reall
advanced things listed can be deferred. We do have a better mailing list
manager now, but not quite as full featured as we would want. Its primary
benefit is that it provides a framework for adding features, and that's
really good.
My question was basically whether people wanted to call the next release,
which is currently v2.2, v3.
> I think that will be messy since there has been so much changes on each,
> but I don't have a better suggestion. grunt grunt grunt.
Danny contributed the Mailet API changes. Stephen did the Avalon changes.
Other than that, I think I committed most of the changes to MAIN. And I
kept them in since until sometime this summer, IIRC. I don't know of any
features present in MAIN that are not in v2.
> This really could expose our Archiles heel though, which is a lack of
> adequate testing to make sure the merged version works well. Have we
> made any progress/thoughts on how to automate testing?
Unless I'm wrong, the major difference is picking up the updated Avalon
parts and making the interface changes, both of which have been tested in
use by Stephen. Am I missing anything?
As for formal testing, we still don't have much. Bench and live testing,
basically. For example, when I get home, I'll test Soren's patch by setting
up a schedule, and sending mail to a dead gateway. I don't know what Avalon
has done in terms of facilitating component testing. Stephen and Steve
might want to talk about incorporating BSF with Merlin to allow BSF scripts
to drive tests.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Merging plan (was Build process in maven?)
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
>>So to just get to a merged 3.0 release, we could do the following
>
> Are you proposing that what is currently v2.2.0 test builds be released as
> v3?
Err, no... I mean merge from a codebase perspective, not overwrite.
Feature-wise, I don't believe there is much in 3.0 that isn't in 2.2.
>>1. Move to latest release packages from Avalon.
>
> I think that we already have them in the MAIN branch. If not, we should.
> Steve is running James with them under Merlin, although we still still want
> to release with Phoenix for at least another set of releases, even if we
> support Merlin as well.
Yeah, I'm not much use resolving this one. I recently joined the Avalon
mailing lists but am still unclear the release state (the new web looks
great though!)
>>2. Discuss and resolve the mailet API changes.
>
>>I think we have some consensus about 2... we originally were planning
>>more sweeping changes and include repository changes, but I don't know
>>if that is appropriate since we're still stuck on the IMAP changes.
>
> I would like to defer the Mailet API changes in the MAIN branch,
> particularly the ones exposing repositories. After we the next Release, we
> can look at changes, including <mailet> configuration.
I had that in mind, and with both Danny and you saying that, I'm happy
with it. Anyone else?
>>3. Address any discrepancies (code changes only applied to one or other,
>> or otherwise require resolution).
>
> Since I was making them in parallel for quite some time, I believe that at
> this tome, such discrepancies are limited (a) improvements in v2 not yet in
> MAIN, (b) changes in MAIN that reflect Avalon changes. If anyone knows of
> anything else, please speak up.
>
> And, yes, it is just grunt work. What I would do (if I were doing it) would
> be to run a visual diff for each file from v2 and MAIN, find those
> differences, copy over into v2 the ones that we need, tag MAIN, and then
> merge the v2 code into MAIN. We'd end up using the MAIN build process,
> which should actually be the nicer one (after all the work Stephen and Leo
> did), with the v2 code updated for current Avalon.
I think that will be messy since there has been so much changes on each,
but I don't have a better suggestion. grunt grunt grunt.
This really could expose our Archiles heel though, which is a lack of
adequate testing to make sure the merged version works well. Have we
made any progress/thoughts on how to automate testing?
--
Serge Knystautas
President
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
RE: Merging plan (was Build process in maven?)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> So to just get to a merged 3.0 release, we could do the following
Are you proposing that what is currently v2.2.0 test builds be released as
v3?
> 1. Move to latest release packages from Avalon.
I think that we already have them in the MAIN branch. If not, we should.
Steve is running James with them under Merlin, although we still still want
to release with Phoenix for at least another set of releases, even if we
support Merlin as well.
> 2. Discuss and resolve the mailet API changes.
> I think we have some consensus about 2... we originally were planning
> more sweeping changes and include repository changes, but I don't know
> if that is appropriate since we're still stuck on the IMAP changes.
I would like to defer the Mailet API changes in the MAIN branch,
particularly the ones exposing repositories. After we the next Release, we
can look at changes, including <mailet> configuration.
> 3. Address any discrepancies (code changes only applied to one or other,
> or otherwise require resolution).
Since I was making them in parallel for quite some time, I believe that at
this tome, such discrepancies are limited (a) improvements in v2 not yet in
MAIN, (b) changes in MAIN that reflect Avalon changes. If anyone knows of
anything else, please speak up.
And, yes, it is just grunt work. What I would do (if I were doing it) would
be to run a visual diff for each file from v2 and MAIN, find those
differences, copy over into v2 the ones that we need, tag MAIN, and then
merge the v2 code into MAIN. We'd end up using the MAIN build process,
which should actually be the nicer one (after all the work Stephen and Leo
did), with the v2 code updated for current Avalon.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org