subject:"Switch to Loom 1.0RC3"

  I'm not sure I would like to use phoenix-trunk: does any 
 other project 
  use it?
 
 Does anyone use LOOM?
 
 From what Peter Royal told me, I understood that development 
 on LOOM is dead.  And we don't have access to the code.  I'd 
 like to hear from Peter regarding Loom vs Phoenix, but he 
 seemed willing to help us update the container.

Well, LOOM had a release cycle in the last year and we have access to
sourcecode, buglist, feature, documentation, and an 1.0RC3 distribution
For Phoenix we have a repository trunk that does not run james, no feature
list, no documentation and no official distribution.

I Just tested the 2 distributions Peter sent to me today. One runs under the
same conditions of Loom (needed to change the data-sources configuration),
the other one (the one he's using) does not find a package that I've not
been able to find anywhere (java.lang.NoClassDefFoundError:
org/apache/avalon/excalibur/packagemanager/impl/DefaultExtensionManager).

 And I never proposed that we precipitously dump the Avalon 
 interfaces.  I am suggested that we not add MORE 
 dependencies, and start to incrementally drop the one's we have.

I already explained this: IMHO the change removed avalon specific source
code in favor of avalon specific configuration. BTW this is an useless
discussion: we can deploy our dbcp class by removing/changing the schema.xml
file from the just released cornerstone-datasources-impl-2.1.jar.
This exact problem does exists with both Phoenix-LatestFromPeterRoyal and
Loom-1.0RC3 (1).

Now that I looked to it better phoenix-trunk didn't work for the same exact
issues Loom didn't: simply Loom gave me better error and I found the
problems and fixed them.

Now our codebase is compatible with phoenix-trunk, phoenix-4.0.4 and
loom-1.0RC3.

Our config.xml is not valid but the important thing is that the code is
compliant.
Both phoenix-trunk and loom-1.0RC3 should correctly handle the classpath for
the contained application (they add any jar in SAR-INF/lib to the
classpath).

Stefano

(1) Just look at this file:
lib\cornerstone-datasources-impl-2.1.jar\org\apache\avalon\cornerstone\block
s\datasources\DefaultDataSourceSelector-schema.xml 

It validates the data-souces element only when its class attribute contain
the org.apache.avalon.excalibur.datasource.JdbcDataSource line.

element name=data-source
attribute name=name/
attribute
name=classvalueorg.apache.avalon.excalibur.datasource.JdbcDataSource/v
alue/attribute 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3

2005-09-08 Thread Ahmed Mohombe


(my idea was a little different but I saw the first reaction and I changed
my mind).

But no commiter gave a -1 till yet. Why shouldn't we switch if it works for you?
Did anyone proved the contrary or had any founded with tests argument - except 
FUD?

After that we could still investigate that 'space problem'.
You are waiting for minimum 3 + votes? But are there so many active comitters 
on this list?
If yes, than make another thread, called [vote] and count only the arguments of 
commiters.


IMHO the container is not part of our application (James) and james should
run fine in each container using the pros and cons of each container. 

AFAIK this was planned for 3.0 with that POJO strategy :).


People
that need functional classloaders will need to use loom. People that need to
do hot deploy/undeploy of applications will use loom.

But will the users be able to switch to loom? I suspect not.

Wouldn't be better to switch officially for the coming alphas so that everybody
can test it?

Thanks in advance,

Ahmed.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3

 Good! Attach some dates and we have a release plan!

Right, but we are not a company and we advance with sparetime so we can
simply decide the order of steps in the cycle and not dates.

 [...]
 The alpha phase can be shortened if there are less features 
 still being put in. I think it is important to have a first 
 alpha release soon, along with a plan of what's still going 
 in and when.

All of us agreed on this. We'll have an alpha release soon.

 As for Loom, I am curious about the white space issue -- 
 whether it can be fixed before the James release. There might 
 be other 'little' issues like this that may turn out to be 
 nasty. So it should be thoroughly tested.

I think that the container issue is MINOR and somewhat unrelated to the
release.

When you release a war application you declare the servlet containers that
are able to run it but you don't bind your application to a specific
container.

I simply think that we should not add workarounds in our code to avoid bugs
in the phoenix version we are currently distributing with james. I would
prefer to bundle a newer container.

And about phoenix being well-known: can you provide links of software
currently using an unreleased phoenix release (either 4.0.4 we currently
bundle or the trunk)?

 Would it be an idea to release James with both Phoenix (not 
 perfect but well known) and Loom (better but more unknown), 
 with Phoenix the default?

I personally don't like this option: people would start asking why we bundle
2 container, what are the differences and we don't have good answers.

Stefano


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3

2005-09-08 Thread Ahmed Mohombe


Does anyone use LOOM?

If it does the job we need, why shouln't we use it till
the 'great POJO-fication' that might(or not) come in the far future.


From what Peter Royal told me, I understood that development on LOOM is
dead.  

Judging from the source code, if LOOM is dead than Avalon could be called 
'rotten' :).


I am
suggested that we not add MORE dependencies, and start to incrementally drop
the one's we have.

As I understood, using LOOM doesn't add MORE dependencies, cause it's 
replacement
is simple. So if there will be a better alternative, to drop it will be an
equal work as to drop Avalon.

Thanks in advance,

Ahmed.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3

  (my idea was a little different but I saw the first reaction and I 
  changed my mind).
 But no commiter gave a -1 till yet. Why shouldn't we switch 
 if it works for you?

I didn't run a vote ;-)

 Did anyone proved the contrary or had any founded with tests 
 argument - except FUD?

IMHO we still have the problem with spaces in the config.xml: this is a real
problem.
Probably phoenix-trunk is the solution but I'm not sure it's stable and I
don't know what the features of phoenix-trunk are: probably I should build
the phoenix-trunk website from trunk to find more informations.

 After that we could still investigate that 'space problem'.
 You are waiting for minimum 3 + votes? But are there so many 
 active comitters on this list?
 If yes, than make another thread, called [vote] and count 
 only the arguments of commiters.

No. I started a discussion thread and not a vote thread because I, in
first place, want to discuss differences between containers. I want to know
the personal considerations of other committers about this kind of changes
as I had time to test different containers and I wanted to report back my
first impressions.

  IMHO the container is not part of our application (James) and james 
  should run fine in each container using the pros and cons 
 of each container.
 AFAIK this was planned for 3.0 with that POJO strategy :).

Sorry, I was referring to Avalon containers. Loom, Metro, Merlin, Phoenix,
Fortress are all Avalon containers. James should run fine in all of them.

  People
  that need functional classloaders will need to use loom. 
 People that 
  need to do hot deploy/undeploy of applications will use loom.
 But will the users be able to switch to loom? I suspect not.

You will just need to download loom, place your james.sar (latest trunk will
create a james.sar compatible with loom/phoenix-trunk) in its apps folder
and remove spaces in your config.xml.
Just execute run.bat or run.sh and it works.

Stefano


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3

2005-09-08 Thread Ahmed Mohombe


IMHO we still have the problem with spaces in the config.xml: this is a real
problem.

But isn't there any simple solution to this 'space problem'?

I always thought(me naive) that such issues are just a matter of parser 
configuration,
cause we talk about XML here :).


Probably phoenix-trunk is the solution but I'm not sure it's stable and I
don't know what the features of phoenix-trunk are: probably I should build
the phoenix-trunk website from trunk to find more informations.

Wouldn't take far less time to investigate the 'space problem' instead?
Considering that you have at least the fact that LOOM WAS working for you,
except that space? I think this is a big argument.


You will just need to download loom, place your james.sar (latest trunk will
create a james.sar compatible with loom/phoenix-trunk) in its apps folder
and remove spaces in your config.xml.
Just execute run.bat or run.sh and it works.

This seems OK, but I still think that if LOOM is good, it should be used
by default, and those with FUD should just investigate/test,
and bring proofs, not just FUD, period :).

Thanks in advance,

Ahmed.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3

  IMHO we still have the problem with spaces in the 
 config.xml: this is 
  a real problem.
 But isn't there any simple solution to this 'space problem'?
 
 I always thought(me naive) that such issues are just a matter 
 of parser configuration, cause we talk about XML here :).

Yes and no.
Avalon containers provide their own Confiuguration objects to the
contained application.
This means that the config.xml is a container file  and not an application
file and IS container specific.
We include a phoenix specific config.xml that works fine when read by
phoenix NamespacedSAXConfigurationParser.
Loom use the same name config.xml and the same notation to configure the
applications but use it's own jar to handle the parsing.
This is not configurable and we would have to change the loom source code to
alter it.

  Probably phoenix-trunk is the solution but I'm not sure it's stable 
  and I don't know what the features of phoenix-trunk are: probably I 
  should build the phoenix-trunk website from trunk to find 
 more informations.
 Wouldn't take far less time to investigate the 'space 
 problem' instead?
 
 Considering that you have at least the fact that LOOM WAS 
 working for you, except that space? I think this is a big argument.

phoenix-trunk is also working for me now that Loom helped me fixing
james.sar incompatibilities.
And we don't want to distribute an application that works for me: we want
to distribute an application that just works for most people.

  You will just need to download loom, place your james.sar (latest 
  trunk will create a james.sar compatible with 
 loom/phoenix-trunk) in 
  its apps folder and remove spaces in your config.xml.
  Just execute run.bat or run.sh and it works.
 This seems OK, but I still think that if LOOM is good, it 
 should be used by default, and those with FUD should just 
 investigate/test, and bring proofs, not just FUD, period :).

I don't know if LOOM is better than phoenix-trunk.

I started this discussion with a question should we move to loom? and I
haven't made a proposal because I need a more clear scenario to make any
proposal around this issue.

I just currently think that the space issue is blocking. I don't
understand why most of the replies have been around the data-source issue
and the fact the loom is dead that IMHO are non-existing issues, but the
whole thread is helping me.

Stefano


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3

  - I've not been able to run james in Phoenix trunk
 
 Peter Royal indicated that he would help us with any Phoenix 
 changes that we really needed.

I'm not sure I would like to use phoenix-trunk: does any other project use
it?

I feel really better with loom. It just reported good errors that pointed me
to the solution in really few time while with phoenix-trunk I've lost a lot
of time with no solution.

Stefano


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3

2005-09-07 Thread Soren Hilmer

I am with Noel on this. We should not do anything that means we get tied more 
to Avalon/Excalibur. 
On the other hand I liked the advantages a lot, as I have experienced massive 
classloader problems with Phoenix, I do a lot of dynamic reloading of .sar's 
and on Windows this leads to lost handles :-(

Maybe we can do some code that enables the use of 
org.apache.james.util.dbcp.JdbcDataSource with Loom (just thinking aloud 
here, as I have not investigated the problem).

--Søren

On Wednesday 07 September 2005 04:37, Noel J. Bergman wrote:
  Should we move to Loom?

 Not if it means some of the things you noted.  I am particularly not keen
 to start using more excalibur code instead of Jakarta Commons code.

  we could avoid using DBCP at all.

 But we want to use DBCP.  It is well-tested, supported and broadly used.

 And I really don't want to tie us more tightly to Avalon.  Rather, we
 should incrementally detach the remaining bits, so that we can move to
 another container architecture.

   --- Noel


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

-- 
Søren Hilmer, M.Sc.
RD manager Phone:  +45 72 30 64 00
TietoEnator IT+ A/S Fax:+45 72 30 64 02
Ved Lunden 12   Direct: +45 72 30 64 57
DK-8230 Åbyhøj  Email:  soren.hilmer at tietoenator.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3

  Should we move to Loom?
 
 Not if it means some of the things you noted.  I am 
 particularly not keen to start using more excalibur code 
 instead of Jakarta Commons code.

IMHO this is not more dependency on excalibur code! We already using that
jar: using that class we could remove our dbcp wrapper (avalon specific). So
we REMOVE avalon specific code.

BTW I'm sure it's only a validation issue and that we can make it working
with our dbcp class by changing the schema file bundled with the newest
cornerstore/excalibut-datasources so we can easily fix this.

  we could avoid using DBCP at all.
 
 But we want to use DBCP.  It is well-tested, supported and 
 broadly used.
 
 And I really don't want to tie us more tightly to Avalon.  
 Rather, we should incrementally detach the remaining bits, so 
 that we can move to another container architecture.

I've already said this a lot of time: it will take A LOT of time to move
away from avalon/cornerstone/excalibur. IMHO it would be really a big
mistake to continue to think to that move as a near move. I'm almost sure
that james will continue depending at least on one of the discussed
libraries for at lease 1 or 2 years. IMHO we should try moving step by step.

Stefano


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3

2005-09-07 Thread Serge Knystautas

On 9/7/05, Stefano Bagnara [EMAIL PROTECTED] wrote:
   - I've not been able to run james in Phoenix trunk
 
  Peter Royal indicated that he would help us with any Phoenix
  changes that we really needed.
 
 I'm not sure I would like to use phoenix-trunk: does any other project use
 it?
 
 I feel really better with loom. It just reported good errors that pointed me
 to the solution in really few time while with phoenix-trunk I've lost a lot
 of time with no solution.

IMO good error messages is worth 100 times all the other issues
mentioned on both sides.  It consider moving away from DBCP a plus,
but that along with all the other advantages/disadvantages are eh
issues to me.

That said, the removing whitespace issue is a show stopper.  If we
could get around that, I would +1 the change.

-- 
Serge Knystautas
Lokitech  software . strategy . design  http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3

2005-09-07 Thread Serge Knystautas

On 9/7/05, Stefano Bagnara [EMAIL PROTECTED] wrote:
 I've already said this a lot of time: it will take A LOT of time to move
 away from avalon/cornerstone/excalibur. IMHO it would be really a big
 mistake to continue to think to that move as a near move. I'm almost sure
 that james will continue depending at least on one of the discussed
 libraries for at lease 1 or 2 years. IMHO we should try moving step by step.

+1.  Just because we don't like our situation and want an entirely new
architecture shouldn't exclude improvements/changes to our existing
solution.

Again to me, if we get rid of the whitespace issue so we can basically
use the same configuration file, this seems like a change worth
discussing.

-- 
Serge Knystautas
Lokitech  software . strategy . design  http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3

 Again to me, if we get rid of the whitespace issue so we can 
 basically use the same configuration file, this seems like a 
 change worth discussing.

I think we should first discussing then try to make it work.
I don't want to loose time hacking loom and then stop against a -1.

I will work on the dbcp issue and whitespace issue ONLY if there is
consensus that the change is a good thing (I will do other tests only if I
see at least 3 +1 to test it and no -1)

I've already done the proof of concept by running my james with NO CODE
CHANGES (the ones I already committed apart).

Stefano


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3

2005-09-07 Thread Hes Siemelink


Stefano Bagnara wrote:

Should we move to Loom?

I've tested it today and the changes I had to do in order to run inside Loom
have been:
1) remove all the spaces from XML: loom does not automatically remove spaces
so leaving the spaces in the config means misconfiguration.


This should be fixed... I have a lot of different configuration files 
with white space and some utilities that generate configuration snippets 
with white space. Revising all that by hand will be very tricky.


On the whole it sounds like a good plan, but I would not do it for the 
upcoming release.


And why is there a 1.0RC3 that hasn't seen development in six months? 
Will there be a 1.0 release at all?


Cheers,

Hes.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3

 On the whole it sounds like a good plan, but I would not do 
 it for the upcoming release.

Why?
It helps fixing current bugs (see classloader issues).

 And why is there a 1.0RC3 that hasn't seen development in six months? 
 Will there be a 1.0 release at all?

Maybe no, but I would feel better using loom 1.0RC3 released 6 months ago
than phoenix 4.0.4 from 2 years ago.

I don't wont to hack james to fix
(http://issues.apache.org/jira/browse/JAMES-418) what already is an hack
(mailet loading) because our container does not support that feature.

Stefano


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3

2005-09-07 Thread Hes Siemelink


Stefano Bagnara wrote:
On the whole it sounds like a good plan, but I would not do 
it for the upcoming release.



Why?
It helps fixing current bugs (see classloader issues).


Since this change has impact on the entire product, there might be more 
issues. It needs a to be tested thoroughly and that costs time. It 
depends on how soon you want to release the next version.


In general I prefer to do big changes just after a release, not just 
before... which in any case would not make such a difference if releases 
are made often.


Cheers,

Hes.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3

 In general I prefer to do big changes just after a release, 
 not just before... which in any case would not make such a 
 difference if releases are made often.

WE ARE just after a release as we never released an alpha of 2.3.0 release
and the last release (2.2.0) was a final.

The fact that has passed an year since the 2.2.0 does not mean we made
testing an year of tests on the current trunk. *real time* is not a variable
for trunk stability.

Stefano


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3


Hes Siemelink wrote:


Stefano Bagnara wrote:

On the whole it sounds like a good plan, but I would not do it for 
the upcoming release.




Why?
It helps fixing current bugs (see classloader issues).



Since this change has impact on the entire product, there might be 
more issues. It needs a to be tested thoroughly and that costs time. 
It depends on how soon you want to release the next version.


In general I prefer to do big changes just after a release, not just 
before... which in any case would not make such a difference if 
releases are made often.


+1

Vincenzo

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3

Not totally true, as I think that some people (like myself) has been thoroughly testing even in production the contents 
of svn. Specially after Noel's work in May, which has been a major (and potentially risky) update impacting the whole 
system ... And James looked quite stable after that.


Vincenzo

Stefano Bagnara wrote:
In general I prefer to do big changes just after a release, 
not just before... which in any case would not make such a 
difference if releases are made often.



WE ARE just after a release as we never released an alpha of 2.3.0 release
and the last release (2.2.0) was a final.

The fact that has passed an year since the 2.2.0 does not mean we made
testing an year of tests on the current trunk. *real time* is not a variable
for trunk stability.

Stefano


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3

2005-09-07 Thread Hes Siemelink


Stefano Bagnara wrote:
In general I prefer to do big changes just after a release, 
not just before... which in any case would not make such a 
difference if releases are made often.



WE ARE just after a release as we never released an alpha of 2.3.0 release
and the last release (2.2.0) was a final.

The fact that has passed an year since the 2.2.0 does not mean we made
testing an year of tests on the current trunk. *real time* is not a variable
for trunk stability.



I thought the 2.3.0 release was coming up shortly?

You mean that it is the right time to put Loom in, just before releasing 
the RCs for 2.3.0. Is it correct that your point is that real testing 
will be done with the RCs, not with the trunk?


Cheers,

Hes.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3

 Not totally true, as I think that some people (like myself) 
 has been thoroughly testing even in production the contents 
 of svn. Specially after Noel's work in May, which has been a 
 major (and potentially risky) update impacting the whole 
 system ... And James looked quite stable after that.

We also, in the last month:
- updated all of our libraries
(cornerstone/avalon/excalibur/dnsjava/javamail)
- updated phoenix (so as you can see we already changed the container)
- added derby support and we're planning to make it the default instead of
file repositories.
- changed today the mail repositories notify/synchronization

I think all of this have to be tested a lot and can impact the stability
more than the container.
BTW, this is my opinion.

The last one (notiy/synchronization) in my opinion is the most critical.

The main thing is that we are not near to a release because we don't even
have a release plan by now and we just talked about doing a release.
In the best scenario we probably will be ready to prepare the first ALPHA in
a month: probably more as we haven't agreed on the roadmap for this release.

Stefano


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3

  The fact that has passed an year since the 2.2.0 does not 
 mean we made 
  testing an year of tests on the current trunk. *real time* is not a 
  variable for trunk stability.
  
 
 I thought the 2.3.0 release was coming up shortly?
 
 You mean that it is the right time to put Loom in, just 
 before releasing the RCs for 2.3.0. Is it correct that your 
 point is that real testing will be done with the RCs, not 
 with the trunk?

RC?? I think that we should release a lot of Alphas before the RCs.
The real testing is done when we will test alphas. The trunk is only tested
by few developers (probably 2 or 3 peoples).
We need to release an alpha to have more people testing a *known* codebase.

Stefano

PS: I've seen 22 2.2.0 alphas before the 2.2.0 final.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3

Stefano Bagnara wrote:
Not totally true, as I think that some people (like myself)
has been thoroughly testing even in production the contents
of svn. Specially after Noel's work in May, which has been a
major (and potentially risky) update impacting the whole
system ... And James looked quite stable after that.

We also, in the last month:
- updated all of our libraries
(cornerstone/avalon/excalibur/dnsjava/javamail)
- updated phoenix (so as you can see we already changed the container)

For me, a container change *has a big impact* (specially because it is a partially dead container outside of our
control), and I was very nervous during Noel's work on May until my tests (better, my production system carefully
watched for weeks) showed that everything was running fine.
I'm again a little bit nervous now after the August container changes, and I would become a little bit more nervous if
another change in this area should come *before creating a new release*. If what we have now is not enough to call it
2.3.0, let's call it 2.2.x. Although I feel that all this container change makes is worth to be called 2.3.0.

- added derby support and we're planning to make it the default instead of
file repositories.
- changed today the mail repositories notify/synchronization

I think all of this have to be tested a lot and can impact the stability
more than the container.
BTW, this is my opinion.

The last one (notiy/synchronization) in my opinion is the most critical.

Agreed. I remember Noel fixing more than two years ago a bug in this area that ran me crazy for several months, very
hard to track.

The main thing is that we are not near to a release because we don't even
have a release plan by now and we just talked about doing a release.
In the best scenario we probably will be ready to prepare the first ALPHA in
a month: probably more as we haven't agreed on the roadmap for this release.

This way IMHO we will never get to a release, because we will be introducing
more bugs to fix than fixing old ones.
IMHO we should make no more architectural changes, start testing immediately and release *as soon as possible* a safe
release. The more we wait, less people around will do any *real* testing.
This is what I think is the release plan we should agree upon. And we have been talking about doing a release since
several months.
And this is why I recently said that we should stop and take a breath... :-) By stopping I mean slowing down introducing
architectural changes, that can introduce bugs very hard to track down. Any minor enhancement or feature can be
obviously added.

After that, let's go for 2.3.1, 2.4 or 3.0.

BTW, compared to the past, we haven't formally release alpha releases, but
milestones did exist although not set in svn.

Vincenzo

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3


Ok, my view is that we should release a firts and last alpha now and start the 
beta cycle :-)

Vincenzo

Stefano Bagnara wrote:

I thought the 2.3.0 release was coming up shortly?

You mean that it is the right time to put Loom in, just 
before releasing the RCs for 2.3.0. Is it correct that your 
point is that real testing will be done with the RCs, not 
with the trunk?


Cheers,



Let me explain what is the release cycle in my head:

Alpha cycle:
- add new features
- handle bug reports
- test it is working and release an alpha
- fix bugs or delay them to a following alpha/beta
- schedule feature/bug fixes for the releases

Repeat Alpha cycle until your major features are in.

Beta cycle
- handle bug reports
- fix bugs or delay them to a following beta
- test and release a new beta
- schedule bug fixes for the next release

Repeat Beta cycles until your minor features are completed and you have
fixed all the bugs you want to fix

RC cycle
- release a candidate
- wait for show-stoppers
- fix show-stoppers

Repeat RC cycles until you have showstoppers.

Final release


Currently we are in the first step of the Alpha Cycle, you can see that this
is the most distant point from the final release in the release cycle.

Note that the cycles are not binded to real/solar time: the whole process
can take years or weeks depending on too many factors.

What I would like is to do a fist alpha release as soon as possible so we
start understanding what the roadmap for following Alphas and Betas will be.
We can only plan alphas/betas.

Isn't this the common way to operate?

Stefano


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3

 Ok, my view is that we should release a firts and last alpha 
 now and start the beta cycle :-)

I agree, but I don't think we should stop and wait for a release. We should
just move forward as much as possible and when someone with rights/knowledge
to do the release (probably Noel in mid october) will have time we'll decide
wether to try to do an alpha from the trunk or from a previous snapshot or
anything else with a vote.

I'm evaluating loom for my own production environment as current trunk is
compatible with loom and I think loom is better than phoenix but we probably
should stick to phoenix because of different spaces handling in config.xml
(my idea was a little different but I saw the first reaction and I changed
my mind).

IMHO the container is not part of our application (James) and james should
run fine in each container using the pros and cons of each container. People
that need functional classloaders will need to use loom. People that need to
do hot deploy/undeploy of applications will use loom.

Stefano


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switch to Loom 1.0RC3