Mailing-List: contact turbine-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Turbine Users List" <turbine-user@jakarta.apache.org>
Message-ID: 
 <6F31394D002AD611BB520002A5417D28F67E18@prod-slo-exh01.aniteps.com>
From: "Courcoux Peter, Slough" <Peter.Courcoux@anite.com>
To: 'Turbine Users List' <turbine-user@jakarta.apache.org>
Subject: RE: AW: Dependency hell in 2.4 (was AW: troubles migrating to tur
	bine 2.3)
Date: Fri, 6 Aug 2004 13:15:44 +0100 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C47BAF.19066800"

------_=_NextPart_001_01C47BAF.19066800
Content-Type: text/plain

Hi Toby,

Eric is talking about cutting a 'milestone' release of 2.4 this weekend for
people who wish to use a cut of cvs with the pipeline (for example the
antelope project).

Having done it a couple of times, I think turbine 2.3 --> turbine 2.4
migration is pretty straight forward at present.

Having spoken at length with Eric recently, we are both tending towards
proposing Excalibur-Fortress as the default container for Avalon style
components in turbine 2.4. If anyone has anything to contribute on this
topic, please do so. It would be great to get opinions...

SOC and IOC work for me and I find the Avalon framework interfaces very
convenient. 

Keel uses Fortress also as its container, but as you say, it should be easy
to add wrappers or adapters to allow components to work in many different
containers.

I think Eric is interested in the Spring service. Could you contribute it?

As for logging, I found the IOC approach to logging took some getting used
to, but again it works for me so I'm OK with it. It would be nice to have
options either way.

Regards,

Peter


-----Original Message-----
From: tobias rademacher [mailto:tobias.rademacher@innowake.de] 
Sent: 06 August 2004 10:48
To: Turbine Users List; hps@intermeta.de
Subject: AW: AW: Dependency hell in 2.4 (was AW: troubles migrating to
turbine 2.3)

Hi Henning,

> >BTW Any roadmap ideas? ;)
> 
> Only for 2.3. I plan to CfV for 2.3.1 very soon now. I was hoping that
> the Torque guys would get their act together for 3.1.1 but it doesn't
> seem that they will.

Unfortunaly it the Antilope Application does not work with 2.3.x as
the Antilope folks already use the Pipline. New users are told to look into
that Application. Flux is not longer supported. So this where 
I see some problems when 2.4 stay unreleased over a long time ;).


> [1] Personally I always had an ambient look at those "end all, rule
> all, do all" frameworks like Avalon, HiveMind or Spring.

Peter already told me the troubles and nigthmares with Avalon Containers.
Fulcurm is really not bad -  With a small set of modifications the
services should work independently in every IoC Container.

I personally unterstand the "eat your own dogfoot" philosophy and
so the descision of using Avalon. 

HiveMind seems to be not very stable for production. IMHO is really
to overconfigurable, not marture and I personally stay way from 
non standard configuration files (the HiveMinders seem to promote there
non-xml syntax but I think configuration with go into the Annoation
direction
for most cases and XML will stay where Annotations don't work).

Spring is a very invasive framework. The services are deployable in every
IoC 2 or IoC 3 Type Container. In Spring you have not to use the
DAO Framework or the Spring-MVC but you may. With some code teaks and
clue code we currently run Turbine 2.4 on top of Spring not on Avalon.

I personally guess that IoC is just 
desing technique and Depencendy Injection is quite cool but if the
containers change too frequently  is not worth a pence.


> The endless
> in-fighting around Avalon, the Avalon PMC, the Merlin project, the new
> proposed top-level Metro project are not building trust in their code
> (in my eyes).

If this is really the case it could be the death of the hole project.
What about the Keel Container? Is Keel more stable?

> 
> And I think, that the IoC metaphor is already overrated, dragged
> around too much and (also IMHO) not really feasible for some aspects
> of a project. Just another buzzword.

Yes definitely. Some certain rumors about the new EJB Standard 3.0
shows that the hole IoC carousel influences the next
standards. No matter if you personally use EJB or not this shows
the great impact of all this leightweight container rank growth
of the last couple of month.

> 
> I was never really able to figure out how to translate e.g. our
> logging approach with log objects and logging into categories into an
> IoC approach.

IMHO logging belongs in the AOP world, definelty not all kind of logging,
but the main part of course. Seperation of Context is fine, but there
are more elegant techniques for certain things available.

Personally the thing bothers me a lot about Avalon: You "pollute" your own
code
with container dependenies (avalon xxx.jar) as you have do resolve the
depending services on
our own. The same is true about the thousands Naming Lookup you have to do
whenever you want to use services of a Session or a Entity Bean.

Toby

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org


Scanned for viruses by MessageLabs


Scanned for viruses by MessageLabs. The integrity and security of this message cannot be guaranteed. This email is intended for the named recipient only, and may contain confidential information and proprietary material. Any unauthorised use or disclosure is prohibited.
------_=_NextPart_001_01C47BAF.19066800--