Leo Sutic wrote:
Niclas,
the problem I have with Merlin/Metro is this:
http://marc.theaimsgroup.com/?l=avalon-dev&m=108965397729686&w=2
Do you have ANY idea just how incredibly hard it has been
to develop for Merlin? I've been trying to get a whole platform
out the door here at S
On Thursday 12 August 2004 05:14, Stefano Mazzocchi wrote:
> I am supportive of the innovation that Merlin is proposing technically,
> but I sense strong idea ownership by some of the players and this is,
> historically, a reason to stay away from a technology, no matter how
> powerful and useful.
Niclas Hedhman wrote:
On Wednesday 11 August 2004 14:47, Guido Casper wrote:
On the surface it may be not that different from a dependency management
POV but the first is easier to unit test ...
And for the record, this whole thread is not an argument for and against
different IoC styles. That i
Hi Niclas,
we're drifting OT though, but I could not let your statement uncommented as
it gave a false impression ;-)
Niclas Hedhman wrote:
> On Thursday 12 August 2004 03:24, Jörg Schaible wrote:
>
>> Niclas Hedhman wrote:
>> > The next step ain't that far away, we are just struggling with some
On Thursday 12 August 2004 03:24, Jörg Schaible wrote:
> Niclas Hedhman wrote:
> > The next step ain't that far away, we are just struggling with some
> > semantics, especially surrounding the possibility of more than a single
> > constructor, which Pico says is a no-no, but could be a necessity.
Hi Niclas,
just to correct some things.
Niclas Hedhman wrote:
> The next step ain't that far away, we are just struggling with some
> semantics, especially surrounding the possibility of more than a single
> constructor, which Pico says is a no-no, but could be a necessity.
Pico supports multipl
Leo Sutic wrote:
...
>I'm sure Merlin/Metro has a place
somewhere, maybe inside the "blocks", maybe somewhere else, but
considering switching to it at this point in time is simply reckless.
Using a container has two advantages: using code that is already there
and tested, and hooking up with a com
Niclas,
the problem I have with Merlin/Metro is this:
http://marc.theaimsgroup.com/?l=avalon-dev&m=108965397729686&w=2
Do you have ANY idea just how incredibly hard it has been
to develop for Merlin? I've been trying to get a whole platform
out the door here at Sony and was hel
On Wednesday 11 August 2004 14:47, Guido Casper wrote:
> On the surface it may be not that different from a dependency management
> POV but the first is easier to unit test ...
And for the record, this whole thread is not an argument for and against
different IoC styles. That is very academic, a
On Wednesday 11 August 2004 14:47, Guido Casper wrote:
> On the surface it may be not that different from a dependency management
> POV but the first is easier to unit test ...
Fair enough (although the response was in respect of dep management), but also
slightly dependent on your test-support
Niclas Hedhman wrote:
Looking at the actual differences;
public AbcComponent( org.hedhman.niclas.SomeDependency some )
{
m_SomeDependency = some;
}
/** @avalon.dependency type="org.hedhman.niclas.SomeDependency"
* key = "some"
*/
public void service(ServiceManager man )
{
m_SomeDepend
On Wednesday 11 August 2004 04:22, Sylvain Wallez wrote:
> Although this is very good from a robustness point of view, I don't feel
> at ease with this as it requires to somehow manage dependencies twice:
> in the model where they have to be formally expressed, and in the code
> where actual looku
Niclas Hedhman wrote:
On Tuesday 10 August 2004 22:55, Sylvain Wallez wrote:
Niclas Hedhman wrote:
I know far too little about Spring in general (i.e. never worked with it)
and GBeans in particular (i.e. have not read enough), to be able to
provide a good answer.
As for Spring, I think the
On Tuesday 10 August 2004 22:55, Sylvain Wallez wrote:
> Niclas Hedhman wrote:
> >I know far too little about Spring in general (i.e. never worked with it)
> > and GBeans in particular (i.e. have not read enough), to be able to
> > provide a good answer.
> >
> >As for Spring, I think the apparent c
On Tuesday 10 August 2004 23:29, Pier Fumagalli wrote:
> On 10 Aug 2004, at 15:05, Niclas Hedhman wrote:
> > 2. Is the Spring/Pico/Kernel camps considering classloading mentioned
> > above
> > being a non-issue, and delegating the task to Cocoon itself to deal
> > with it?
>
> Kernel: Class re-Load
On 10 Aug 2004, at 15:05, Niclas Hedhman wrote:
2. Is the Spring/Pico/Kernel camps considering classloading mentioned
above
being a non-issue, and delegating the task to Cocoon itself to deal
with it?
Kernel: Class re-Loading already work through the conceptualization and
implementation of block
Niclas Hedhman wrote:
I know far too little about Spring in general (i.e. never worked with it) and GBeans
in particular (i.e. have not read enough), to be able to provide a good answer.
As for Spring, I think the apparent convergence between Merlin and Spring is based on two different starting po
On Tuesday 10 August 2004 22:32, Sylvain Wallez wrote:
> >FYI, planned features for Merlin in the coming 6-12month period;
> >* Better JMX integration.
> >* JMS support.
> >* JTA support.
> >* IoC Type 2 and Type 3 dependency resolution.
> >* JavaBeans/Type2 setter injection of parameter values.
>
Il giorno 10/ago/04, alle 16:32, Sylvain Wallez ha scritto:
So my personal answer is no. Other people here may have a different
opinion though.
Then please disregard the closing sentence in my previous message ;-)
Ugo
--
Ugo Cei - http://beblogging.com/
smime.p7s
Description: S/MIME cryp
Niclas Hedhman wrote:
Hi,
I have with great interest read just about everything regarding the Cocoon
sentiment of moving away from Excalibur Component Manager.
What strikes me with the proposals 'on the table';
* Spring
* Pico
* Merlin
* Fortress
* Geronimo/GBean
* Custom (Kernel)
is that A
Il giorno 10/ago/04, alle 16:05, Niclas Hedhman ha scritto:
1. Is compatibility no longer an issue, and that a Cocoon 3 will
emerge from a
clean slate? Or is a 'gradual' evolution from ECM to something new
still the
preferred approach?
It depends on who you ask. Personally, I tend to prefer a rew
Hi,
I have with great interest read just about everything regarding the Cocoon
sentiment of moving away from Excalibur Component Manager.
What strikes me with the proposals 'on the table';
* Spring
* Pico
* Merlin
* Fortress
* Geronimo/GBean
* Custom (Kernel)
is that AFAIU only Geron
22 matches
Mail list logo
