Niclas Hedhman wrote:
On Wednesday 20 October 2004 16:23, Antonio Gallardo wrote:
I knew about that. But again the balance would a hard task: Xalan and
Xerces need to move to JAXP 1.3. I already saw the post on the xml-commons
list.
What surprises me about it is that the source of the problem isn
Le 20 oct. 04, à 16:43, Ralph Goers a écrit :
I like that a lot as it should guarantee the correct source. Assuming
a
project is using SVN of course
The same is true with CVS, as discussed before [1]
Even if the CVS snapshot cannot be done against a specific CVS tag, a
snapshot using "cvs ex
I like that a lot as it should guarantee the correct source. Assuming a
project is using SVN of course.
Ralph
Nicola Ken Barozzi said:
>
> In fact AFAIK we had decided that we had to keep the sources only if the
> source was not easy to get. We can simply append the SVN version of the
> snapsho
Stefano Mazzocchi wrote:
Ralph Goers wrote:
Antonio,
This subject has come up many times. I'll restate what I've always said.
If we must release a snapshot jar then the source that was used to build
it must be available for download from Cocoon's website, or another
documented location (i.e. cocoo
On Wednesday 20 October 2004 16:23, Antonio Gallardo wrote:
> I knew about that. But again the balance would a hard task: Xalan and
> Xerces need to move to JAXP 1.3. I already saw the post on the xml-commons
> list.
What surprises me about it is that the source of the problem isn't educated
abo
Niclas Hedhman dijo:
> Your reasons are highly valid, no doubt, just like the unstable days of
> Cocoon, when matching versions of xerces, xalan and other XML technologies
> was a balance act one hardly want to go through again.
I knew about that. But again the balance would a hard task: Xalan and
On Wednesday 20 October 2004 05:39, Antonio Gallardo wrote:
> At the end, it a big shame to me that my work is being used against our
> community. Seems that I need to be more careful.
I am sorry that your work end up being an example;
"One should not throw stones while in a glass house."
i.e. d
Ralph Goers wrote:
Antonio,
This subject has come up many times. I'll restate what I've always said.
If we must release a snapshot jar then the source that was used to build
it must be available for download from Cocoon's website, or another
documented location (i.e. cocoondev, ibiblio, etc.). I
Ralph Goers dijo:
> Antonio,
>
> This subject has come up many times. I'll restate what I've always said.
> If we must release a snapshot jar then the source that was used to build
> it must be available for download from Cocoon's website, or another
> documented location (i.e. cocoondev, ibiblio,
Thanks for jogging my memory Sylvain. Yes, the rule was followed. As much
as I'd like the actual source, the name does allow me to get it myself.
BTW - weren't the rules for release numbering, the guarantees about
compatibility as well as how snapshots would be named supposed to be on
the website
Antonio,
This subject has come up many times. I'll restate what I've always said.
If we must release a snapshot jar then the source that was used to build
it must be available for download from Cocoon's website, or another
documented location (i.e. cocoondev, ibiblio, etc.). I've had too much
t
Sylvain Wallez dijo:
> Antonio Gallardo wrote:
>
>
>
>>At the end, it a big shame to me that my work is being used against our
>>community. Seems that I need to be more careful.
>>
>>
>
> Nope. You committed that unreleased version for a valid reason and you
> followed that naming rule that allows
Antonio Gallardo wrote:
At the end, it a big shame to me that my work is being used against our
community. Seems that I need to be more careful.
Nope. You committed that unreleased version for a valid reason and you
followed that naming rule that allows to find the corresponding sources
if ev
Stefano Mazzocchi dijo:
> Niclas Hedhman wrote:
>
>> On Saturday 16 October 2004 04:55, Stefano Mazzocchi wrote:
>>
>>
>>>Because they have been around forever *AND* they don't change their
>>>contracts overnight.
>>
>>
>> Your talk is not entirely reflected by the actions of the community. I
>> ju
Hi Ralph:
AFAIK, we can release without problems. But if a xalan version is needed
we can request the xalan project for a release.
I already requested for a release to the commons-lang project. They
promised a release, but I will remeber them about that.
WDYT?
Best Regards,
Antonio Gallardo.
Niclas Hedhman dijo:
> On Saturday 16 October 2004 04:55, Stefano Mazzocchi wrote:
>
>> Because they have been around forever *AND* they don't change their
>> contracts overnight.
>
> Your talk is not entirely reflected by the actions of the community.
> I
> just
> did a svn up on the 2.1 branch;
>
Vadim Gritsenko dijo:
>> Hmm, I actually don't know what's best. What do others think?
>
> The best plan IMHO would be:
>
> 1. Remove ECM - implementation of Avalon container. Keep re-usable
> components
> code (XSLT, Source, Store, etc).
> 2. Drop in the container which replaces it.
> 3. Write bri
Pier Fumagalli wrote:
On 19 Oct 2004, at 11:45, Torsten Curdt wrote:
The serializers in XALAN are just _VERY_ broken... Why don't we
switch the default to work on the serializers block? At least it's a
simple-enough code that we can't fix without too much hassle.
the serializer still has some na
Well, that's a bug related to the Xalan serializers, not to the Cocoon
"serializers" block, and AFAICS, it was fixed in CVS in July...
Pier
On 19 Oct 2004, at 17:57, Jorg Heymans wrote:
30142
Pier Fumagalli wrote:
On 19 Oct 2004, at 11:45, Torsten Curdt wrote:
The serializers in XALAN are
30142
Pier Fumagalli wrote:
On 19 Oct 2004, at 11:45, Torsten Curdt wrote:
The serializers in XALAN are just _VERY_ broken... Why don't we
switch the default to work on the serializers block? At least it's a
simple-enough code that we can't fix without too much hassle.
the serializer still has s
On 19 Oct 2004, at 11:45, Torsten Curdt wrote:
The serializers in XALAN are just _VERY_ broken... Why don't we
switch the default to work on the serializers block? At least it's a
simple-enough code that we can't fix without too much hassle.
the serializer still has some namespace issues.
but not
On 19 Oct 2004, at 17:35, Sylvain Wallez wrote:
Torsten Curdt wrote:
The serializers in XALAN are just _VERY_ broken... Why don't we
switch the default to work on the serializers block? At least it's a
simple-enough code that we can't fix without too much hassle.
the serializer still has some na
Torsten Curdt wrote:
The serializers in XALAN are just _VERY_ broken... Why don't we
switch the default to work on the serializers block? At least it's a
simple-enough code that we can't fix without too much hassle.
the serializer still has some namespace issues. but nothing that
cannot be fix
Ugo Cei wrote:
Pier Fumagalli wrote:
The serializers in XALAN are just _VERY_ broken... Why don't we switch
the default to work on the serializers block? At least it's a
simple-enough code that we can't fix without too much hassle.
I'm sure you meant "can" instead of "can't" ;-) but anyway, here'
Pier Fumagalli wrote:
The serializers in XALAN are just _VERY_ broken... Why don't we switch
the default to work on the serializers block? At least it's a
simple-enough code that we can't fix without too much hassle.
I'm sure you meant "can" instead of "can't" ;-) but anyway, here's my +1.
The serializers in XALAN are just _VERY_ broken... Why don't we switch
the default to work on the serializers block? At least it's a
simple-enough code that we can't fix without too much hassle.
the serializer still has some namespace issues.
but nothing that cannot be fix in a few hours.
--
Tors
On 18 Oct 2004, at 17:03, Sylvain Wallez wrote:
A lib/endorsed/xalan-2.6.1-dev-20041008T0304.jar
D lib/endorsed/xalan-2.6.0.jar
Why does the 2.1 branch require a timestamped/snapshot version of
Xalan, if everything is so fine and dandy with it?
Damn, I am *NOT*. I missed that. We must not depen
Carsten Ziegeler dijo:
> So, a big +1 for not depending on someone else, regardless who they
> are or how brilliant the project seems today.
I thought that was already agreed at the hackthon. But seems things are
not clear so here is my +1 too. ;-)
Best Regards,
Antonio Gallardo
Stefano Mazzocchi wrote:
Niclas Hedhman wrote:
On Saturday 16 October 2004 04:55, Stefano Mazzocchi wrote:
Because they have been around forever *AND* they don't change their
contracts overnight.
Your talk is not entirely reflected by the actions of the community.
I just did a svn up on the 2.1
Niclas Hedhman wrote:
On Saturday 16 October 2004 04:55, Stefano Mazzocchi wrote:
Because they have been around forever *AND* they don't change their
contracts overnight.
Your talk is not entirely reflected by the actions of the community. I just
did a svn up on the 2.1 branch;
A lib/endorsed
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Add your reasons.
Since Avalon came to life and I came to love it, I've had long fights
with some of my colleagues at work to convince them to use it, in
order to have robust architectures. Their argument was that they
didn't want to use Avalon bec
Niclas Hedhman wrote:
>
>
> Yes. As a user, that is the essence. What are the 'Dates of
> RoadMap Milestones" and who are driving those besides Pier,
> Sylvain and Ugo?
> So, we can get some birds-eye view, and avoid another "2.x
> styled delays".
>
We agreed that the new core (or the blocks
On Monday 18 October 2004 16:27, Reinhard Poetz wrote:
> Thanks Daniel for speaking it out loudly: Who wants to get his hands dirty
> with the two implementations
>
> - kernel (inter-block communication, classloader shielding)
> - new Cocoon core engine
>
> and which time frames are those peop
Daniel Fagerstrom wrote:
components and property DI for optional components might be a good
approach. However, IMHO, it would not give enough advantages to be worth
any back compatibillity, a prolonged period of instabillity or (at least
for me), the effort.
Thanks Daniel for speaking it out lo
Ugo Cei wrote:
Il giorno 17/ott/04, alle 17:22, Daniel Fagerstrom ha scritto:
data. In Spring you must as well supply wiring information about how
the component is connected to other components thru setters. You need
to describe the life cycle, if there are any initialization and
destruction met
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
What I would like us to do, is to write some kind of (prioritized)
requirement list on what problems we would like to solve for
intra-block component handling. Then it would be possible to evaluate
different technical solutions with respect to our
Il giorno 17/ott/04, alle 17:22, Daniel Fagerstrom ha scritto:
data. In Spring you must as well supply wiring information about how
the component is connected to other components thru setters. You need
to describe the life cycle, if there are any initialization and
destruction methods of the com
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
While I agree with your concerns, I think a DI container can
_potentially_ bring a lot in this area. The current problem with
Cocoon's xconf file is that it is really free-form, and the variety of
the components makes writing an XML grammar to chec
Daniel,
I didn't quote everything in your post in the interest of space, but I
agree with everything in it. Frankly, I'd be happy if every block had
it's own equivalent to cocoon.xconf that could be loaded along with the
block. If any wiring is needed, it should be between the Cocoon core
and
Daniel Fagerstrom wrote:
Guido Casper wrote:
Ralph Goers wrote:
In short, the fact that Cocoon is just a bunch of parts that get
configured is one of Cocoon's major strengths. However, the current
configuration is pretty easy to understand and modify. If the
replacement container makes the con
Pier Fumagalli wrote:
As I personally need the kernel, I will personally invest some more
time into it, Cocoon or not (frankly, I could care less at this point).
I think that the current kernel code is wrong, as it's based on
implementation of interfaces a-la Avalon, and you showed me a way to
Guido Casper wrote:
Ralph Goers wrote:
In short, the fact that Cocoon is just a bunch of parts that get
configured is one of Cocoon's major strengths. However, the current
configuration is pretty easy to understand and modify. If the
replacement container makes the configuration more complex a
Guido Casper wrote:
Sorry, I thought what's being discussed is wether or not to use Spring
as an intra-block container and that Tani as inter-block container is
set. Am I wrong?
Nope, you're totally right. Tani already provides classloader isolation,
and we just need to add a thin DI layer on t
Ralph Goers wrote:
In short, the fact that Cocoon is just a bunch of parts that get
configured is one of Cocoon's major strengths. However, the current
configuration is pretty easy to understand and modify. If the
replacement container makes the configuration more complex and less
understanda
Sorry, I thought what's being discussed is wether or not to use Spring
as an intra-block container and that Tani as inter-block container is
set. Am I wrong?
Guido
Il giorno 16/ott/04, alle 20:51, Pier Fumagalli ha scritto:
And that said, I close this whole discussion as I think it's entirely
pointless, I'll let Stefano re-iterate why class loading isolation is
required to achieve blocks polymorphism.
I don't think it is entirely pointless. For one thing, s
On 16 Oct 2004, at 13:31, Ugo Cei wrote:
Il giorno 16/ott/04, alle 13:28, Carsten Ziegeler ha scritto:
For a long time I was against writing our own container as I
saw it simply as a waist of time/resources. But after just
talking five minutes with Pier at the GT, I changed my
opinion :) (Sometimes
I must admit, I have issues with this whole discussion. I understand
that there are problems with the Avalon community and that the current
code base is making implementing real blocks difficult. But I have also
used Spring and have issues with that. To summarize:
1. Figuring out what is going
Ugo Cei wrote:
>
> > Now, if we build the core on Spring now we have the same problem
> > again. What if someone wants to use Avalon (uh!) for his
> application?
>
> He'll instantiate some kind of Avalon container and maybe
> bind it to the servlet context, so that any other component
> that
Ugo Cei wrote:
>
> Sigh, I though I had shown in my presentation that it is
> quite easy and straightforward indeed :(.
>
Sure, you succeeded in this point, don't worry about it!
It's possible to use Spring in Cocoon and it's easy but
it's not really integrated.
> We should not make that easy
Il giorno 16/ott/04, alle 13:28, Carsten Ziegeler ha scritto:
For a long time I was against writing our own container as I
saw it simply as a waist of time/resources. But after just
talking five minutes with Pier at the GT, I changed my
opinion :) (Sometimes Pier can be really convincing).
Pier sho
Ugo Cei wrote:
Il giorno 16/ott/04, alle 13:52, Sylvain Wallez ha scritto:
Configuration file format may change, but providing an XSL to migrate
it should be a piece of cake should it ever happen.
As an aside, Spring's BeanFactory is completely decoupled from the XML
format. The BeanFactory rel
Il giorno 16/ott/04, alle 13:52, Sylvain Wallez ha scritto:
That's the whole goal of turning Cocoon components into POJOs: have
our code become totally independent on the container that hosts them.
Let's use Tani for inter-blocks and Spring for intra-block. I one day
we're not satified with them
Bertrand Delacretaz wrote:
The point that I was trying to make is that I really like the idea of
considering the "cocoon core" container separately from the "cocoon
applications" one, as much for marketing reasons as for technical ones.
I too like the idea.
Guido
Guido Casper wrote:
Bertrand Delacretaz wrote:
Le 16 oct. 04, à 11:14, Guido Casper a écrit :
...for a start it would be the easiest to just drop in
spring-core.jar. But we would have to make sure, that this cannot be
interpreted as an invitation to introduce other dependencies
Dependencies
Le 16 oct. 04, à 13:28, Sylvain Wallez a écrit :
Folks, look at what I just found in my junk mail folder. Hopefully,
everyone in Cocoon-land runs the same spam filter...
hmmyour spam filter looks really powerful, but make sure it doesn't
feed the trolls when it thinks it sees one...
(but sti
Il giorno 16/ott/04, alle 11:14, Guido Casper ha scritto:
Ugo, can you explain what exactly are the dependencies on Spring? My
rather limited) understanding is, that we primarily would use Spring's
BeanFactory. As the BeanFactory is:
a) designed to not introduce any dependency for your components
Vadim Gritsenko wrote:
Ugo Cei wrote:
Il giorno 15/ott/04, alle 13:01, Vadim Gritsenko ha scritto:
The best plan IMHO would be:
1. Remove ECM - implementation of Avalon container. Keep re-usable
components code (XSLT, Source, Store, etc).
2. Drop in the container which replaces it.
3. Write bridge
Drains people's energy towards destructive fights
Original Message ----
Subject: RE: [RT] Some notes about the "Real Blocks" issue
Date: Fri, 15 Oct 2004 23:19:45 +0200
From: Stephen McConnell <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: <[E
Bertrand Delacretaz wrote:
>
> Le 16 oct. 04, à 12:51, Guido Casper a écrit :
>
> > ...Please don't be dogmatic about this. You have to depend on
> > something! Just make sure you control your dependencies
> (the quality
> > and the quantity of them) and they don't get out of control...
>
> Y
Le 16 oct. 04, à 12:51, Guido Casper a écrit :
...Please don't be dogmatic about this. You have to depend on
something! Just make sure you control your dependencies (the quality
and the quantity of them) and they don't get out of control...
You're right, and anyway I'm not working on these contai
Guido Casper wrote:
Don't you like Spring's way of DI?
Sorry Bertrand, ignore that, of course you already told you like it.
May mail wasn't (only) addressed at you :-)
Guido
Bertrand Delacretaz wrote:
Le 16 oct. 04, à 11:14, Guido Casper a écrit :
...for a start it would be the easiest to just drop in
spring-core.jar. But we would have to make sure, that this cannot be
interpreted as an invitation to introduce other dependencies
Dependencies on Spring in the Coc
Reinhard Poetz wrote:
>
> Pier Fumagalli wrote:
> > On 14 Oct 2004, at 16:18, Stefano Mazzocchi wrote:
> >
> >>
> >> My point remains: we've been burned too much before already in
> >> depending on frameworks we don't control.
> >>
> >> I still think it would be better to write our own entirely
Le 16 oct. 04, à 11:14, Guido Casper a écrit :
...for a start it would be the easiest to just drop in
spring-core.jar. But we would have to make sure, that this cannot be
interpreted as an invitation to introduce other dependencies
Dependencies on Spring in the Cocoon core are certainly not a
Ugo, can you explain what exactly are the dependencies on Spring? My
rather limited) understanding is, that we primarily would use Spring's
BeanFactory. As the BeanFactory is:
a) designed to not introduce any dependency for your components
b) rather trivial to re-implement
for a start it would b
I'm curious about this for a completely different reason. It has been
the stated policy that every attempt will be made to use only formally
released third-party jars in formal releases of Cocoon. Does this mean
that 2.1.6 cannot be released until Xalan 2.6.1 is released? If not,
please make
On Saturday 16 October 2004 04:55, Stefano Mazzocchi wrote:
> Because they have been around forever *AND* they don't change their
> contracts overnight.
Your talk is not entirely reflected by the actions of the community. I just
did a svn up on the 2.1 branch;
A lib/endorsed/xalan-2.6.1-dev-2
Stefano Mazzocchi <[EMAIL PROTECTED]> writes:
>
> Hunsberger, Peter wrote:
>
> > Umm, I don't really see a pattern here. From everything
> I've seen the
> > communities involved with Spring and Geronimo have little in common
> > with the Avalon/Excalibur communities. (Let me qualify that
> b
> -Original Message-
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
> Because they have been around forever *AND* they don't change their
> contracts overnight.
So who is changing contracts Stefano?
Hunsberger, Peter wrote:
Umm, I don't really see a pattern here. From everything I've seen the
communities involved with Spring and Geronimo have little in common with
the Avalon/Excalibur communities. (Let me qualify that by saying I
haven't looked that closely.) More-over, they both have the adv
Stefano Mazzocchi <[EMAIL PROTECTED]> writes:
> Hunsberger, Peter wrote:
>
> > Maybe I'm
> > just too optimistic in believing there should be container
> > implementations mature enough for Cocoon to depend on?
>
> What *really* bothers me about this thread is the fact that very few
> seem to
Il giorno 15/ott/04, alle 20:18, Vadim Gritsenko ha scritto:
Ugo Cei wrote:
Il giorno 15/ott/04, alle 13:01, Vadim Gritsenko ha scritto:
The best plan IMHO would be:
1. Remove ECM - implementation of Avalon container. Keep re-usable
components code (XSLT, Source, Store, etc).
2. Drop in the contai
Hunsberger, Peter wrote:
> Maybe I'm
just too optimistic in believing there should be container
implementations mature enough for Cocoon to depend on?
What *really* bothers me about this thread is the fact that very few
seem to realize that "maturity" for dependencies means "stability of the
cont
>>ho ho ho
Sorry,
replied to the wrong email
Doh !!!
G
-Original Message-
From: Garry Munro
Sent: 15 October 2004 13:30
To: '[EMAIL PROTECTED]'
Subject: RE: [RT] Some notes about the "Real Blocks" issue
-Original Message-
From: Ugo Cei [mailto:
Ugo Cei wrote:
Il giorno 15/ott/04, alle 13:01, Vadim Gritsenko ha scritto:
The best plan IMHO would be:
1. Remove ECM - implementation of Avalon container. Keep re-usable
components code (XSLT, Source, Store, etc).
2. Drop in the container which replaces it.
3. Write bridge code between container
Pier Fumagalli wrote:
On 14 Oct 2004, at 16:18, Stefano Mazzocchi wrote:
Ugo Cei wrote:
Il giorno 14/ott/04, alle 16:50, Stefano Mazzocchi ha scritto:
real block kernel and Rickard Oberg's AOP framework, this would be
modern.
Too bad he has not open-sourced it yet, or has he?
No, and he will not.
On 14 Oct 2004, at 16:18, Stefano Mazzocchi wrote:
Ugo Cei wrote:
Il giorno 14/ott/04, alle 16:50, Stefano Mazzocchi ha scritto:
real block kernel and Rickard Oberg's AOP framework, this would be
modern.
Too bad he has not open-sourced it yet, or has he?
No, and he will not.
But the ideas are avai
Ugo Cei <[EMAIL PROTECTED]> writes:
>
> Il giorno 13/ott/04, alle 18:59, Ugo Cei ha scritto:
>
> > - [ ] Geronimo/JMX?
> > This thread:
> >
> > http://thread.gmane.org/gmane.comp.java.springframework.devel/4910
> > might provide some suggestions re
Il giorno 15/ott/04, alle 13:01, Vadim Gritsenko ha scritto:
The best plan IMHO would be:
1. Remove ECM - implementation of Avalon container. Keep re-usable
components code (XSLT, Source, Store, etc).
2. Drop in the container which replaces it.
3. Write bridge code between container in (2) and (1)
Carsten Ziegeler wrote:
Ugo Cei wrote:
The interfaces that are in Butterfly are a verbatim copy
(apart maybe from some minor changes, some time has passed
and I don't remember all the details) of the Excalibur ones.
Of course, the package names have changed (and the
o.a.butterfly will have to b
On Friday 15 October 2004 16:06, Ugo Cei wrote:
> Il giorno 15/ott/04, alle 09:43, Niclas Hedhman ha scritto:
> > However, you are requesting that the Excalibur Source is a subclass of
> > the
> > Cocoon Source. I suspect that is a typo, but if not, then you are
> > introducing
> > a cross-dependen
Il giorno 15/ott/04, alle 09:43, Niclas Hedhman ha scritto:
However, you are requesting that the Excalibur Source is a subclass of
the
Cocoon Source. I suspect that is a typo, but if not, then you are
introducing
a cross-dependency with the Excalibur project, or breaking namespace
policies
by us
On Friday 15 October 2004 15:29, Carsten Ziegeler wrote:
IMHO, generally, compatibility provided through subclassing is 'asking for
long-term trouble'. Take a deep look inside the Netbeans project for a scary
example.
Subclassing of interfaces is slightly better...
> > public interface Source e
Ugo Cei wrote:
>
>
> The interfaces that are in Butterfly are a verbatim copy
> (apart maybe from some minor changes, some time has passed
> and I don't remember all the details) of the Excalibur ones.
>
> Of course, the package names have changed (and the
> o.a.butterfly will have to be chan
Il giorno 15/ott/04, alle 08:39, Carsten Ziegeler ha scritto:
Hmm, I'm a little bit concerned about compatibility here. I know it
would be great to be independant from other projects in the core,
but if you look at the sourceresolver in excalibur, the interfaces
that are used there (SourceResolver,
Ugo Cei wrote:
>
> Il giorno 14/ott/04, alle 18:09, Vadim Gritsenko ha scritto:
>
> > Other question I have is what we are going to do with the component
> > base we developed and depend on which currently resides in
> excalibur
> > repository. Should those be copied into Cocoon repository (an
Il giorno 13/ott/04, alle 18:59, Ugo Cei ha scritto:
- [ ] Geronimo/JMX?
This thread:
http://thread.gmane.org/gmane.comp.java.springframework.devel/4910
might provide some suggestions re the
implementation of the kernel.
I just came upon
On Friday 15 October 2004 01:39, Luigi Bai wrote:
> Forking the code to Cocoon would be nice: Cocoon committers could then
> fix the bugs even if they are not Avalon/Excalibur/whatever committers.
Well, this is not what the problem has been, since Cocoon committers AFAIU has
been Avalon committe
A benefit to forking Excalibur into Cocoon would be the availability of
the source code so people can track down bugs. I'm only a "light" Cocoon
user, and I've already been frustrated a number of times tracking down a
problem, only to hit the org.apache.avalon/excalibur "black hole". There
are
Ugo Cei wrote:
Il giorno 14/ott/04, alle 18:09, Vadim Gritsenko ha scritto:
Other question I have is what we are going to do with the component
base we developed and depend on which currently resides in excalibur
repository. Should those be copied into Cocoon repository (and
springified as ne
Il giorno 14/ott/04, alle 18:09, Vadim Gritsenko ha scritto:
Other question I have is what we are going to do with the component
base we developed and depend on which currently resides in excalibur
repository. Should those be copied into Cocoon repository (and
springified as needed?)?
Things
Stefano Mazzocchi wrote:
Vadim, let me be crystal clear: I DO NOT want to depend on fortress!
I've been trying to get that fucking thing working and it depends on
things that Berin has on d-haven.org and only *HE* maintains.
We didn't want Merlin because it was a one man show, but Fortress is way
Ugo Cei wrote:
Il giorno 14/ott/04, alle 16:50, Stefano Mazzocchi ha scritto:
real block kernel and Rickard Oberg's AOP framework, this would be
modern.
Too bad he has not open-sourced it yet, or has he?
No, and he will not.
But the ideas are available and implementation doesn't scare me.
My point
Stefano Mazzocchi wrote:
>
> I don't know if Spring will be better, that's why I much
> rather would want to invent our own that to depend on
> somebody elses (writing a dep-inj container is piece of cake, c'mon)
>
*Today* I totally agree with this vision. Until recently (when
the Excalibur pro
On Thursday 14 October 2004 23:05, Ugo Cei wrote:
> Il giorno 14/ott/04, alle 16:50, Stefano Mazzocchi ha scritto:
> > real block kernel and Rickard Oberg's AOP framework, this would be
> > modern.
>
> Too bad he has not open-sourced it yet, or has he?
Last time I spoke to him, the 'new style' is
Il giorno 14/ott/04, alle 16:50, Stefano Mazzocchi ha scritto:
real block kernel and Rickard Oberg's AOP framework, this would be
modern.
Too bad he has not open-sourced it yet, or has he?
--
Ugo Cei - http://beblogging.com/
smime.p7s
Description: S/MIME cryptographic signature
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Personally, I'd favor Avalon support for chosen container. As Ralph
noted, and he is not alone, people like Avalon, and we should support
it for years to come.
Well, people will like DI containers once they start using them :-)
DI is 1% of the origina
Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:
Cocoon undergo phase transition when moving from 1.x to 2.x.
Are we doing it again?
The question on the table is: we *NEED* better class discovery and
classloading isolation. This is a must, just like the need for SAX
pipelines drove 2.x away from 1
Niclas Hedhman wrote:
Being a die-hard Avalon supporter, I am all in favour of progress, but for the
right reasons. Swapping ECM/Fortress for Spring/Pico doesn't change anything
fundamentally. Only creates a lot of work for no immediate benefit.
The real challenge as someone pointed out, is the c
1 - 100 of 121 matches
Mail list logo
