avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <jvan...@zenplex.com>
Subject Re: Avalon and Turbine
Date Wed, 05 Jun 2002 12:05:35 GMT
On Wed, 2002-06-05 at 01:46, Nicola Ken Barozzi wrote:
> From: "Jason van Zyl" <jvanzyl@zenplex.com>
> 
> > Just thought I would share some preliminary good news. Informally in IRC
> > we have decided that in Turbine land we will push as much of our bean
> > type code into the commons, drop our service and component packages and
> > use Avalon instead. Five of the core people have agreed, but I'm not
> > interested in rolling another component framework in straight Java (as
> > opposed to AspectJ) so I will push for Avalon's use. The last person I
> > have to convince is Jon :-) I will be posting something to the Turbine
> > list tomorrow but things look good so far. So if there's anyone who
> > wants to join in to possibly temper the discussion feel free.
> 
> Jason, this is excellent news.
> We have been also been thinking on how to share more with Commons, and we
> can get a wonderful act together :-)

I think so.
 
> > Technically I think this is the best thing for Turbine, and hopefully it
> > will start to close some of the rifts that have formed in Jakarta over
> > the last couple of years.
> 
> What can I say...
> 
> I know that this is rushing things, but how bout Phoenix?
> I don't want to rush anything, but I would really love to see turbine and
> Velocity run in Phoenix.

I was thinking Turbine would be a parallel to Cocoon. Does Cocoon not
live at the Excalibur level?

> It could be the killer application:
> Install Phoenix, and then run Velocity, Turbine, Cocoon, James, Tomcat, etc
> in it, benefiting from all the services it gives.
> 
> Sometimes it's nice to dream...

That's more possible than anything at this point. It's taken a long time
to make the decision so I'm committed.

> > I would like to thank Vincent Massol for convincing me that it would be
> > in Turbine's best interest to use Avalon :-)
> 
> :-)
> 
> Since you are at it, I would like to ask you one more thing.
> 
> As you know, I have set up a project called Centipede as a spinoff from
> Forrest and POI.
> I have tried to get collaboration with Maven, but things went horribly
> wrong.

My fundamental problem is with the Gump descriptor which I think sucks
and I think Gump itself is not viable. I don't consider the generation
of a 35k line shell script a solution. So the primary aversion is my
doing in that I don't like the Gump descriptors and I don't like Gump.

I was one of the first people to try Gump and I am admittedly not very
good with XSL but the whole thing just didn't make any sense to me. In
the descriptors there is the muddling of dependencies where they are
repeated within projects where a project can be a different target in
the same build file or a different project in the real sense (like the
commons). I just found it confusing in addition to Gump not building
projects the way they are built by projects i.e. the classpath not being
constructed by the project but being forced from the command line. I
don't know how you're supposed to find some of real problems in Ant with
the classloader doing this.

Gump has some other people working on it now but Gump started a long
time ago and it's taken quite a while to get anyone else working on it
because I think it is so difficult to work with despite what Sam says.
I've always found it a severe PITA.

The idea is of paramount importance, I have never disagreed with that.
But I think the implementation is frankly abysmal. I've been accused of
NIH but I don't think that's entirely fair. I have gotten rid of more
code in Turbine and replaced it where I could with something better: our
pooling and factory code gone, our configuration stuff will probably
soon be gone, we are dumping our services/component framework in favor
of Avalon, I dumped the XML->bean mapper I made in favor of betwixt and
laid to rest many other pieces of code where possible. In general I try
to cooperate but there are certain cases where I won't. Torque for
example: I will help where necessary but I think OJB is superior which
is why I brought it to Jakarta and will use that instead. In the same
vein I think that Maven is hands down a better project management and
soon to be CI system then Gump.

> Just think about it, and if some sort of collaboration could make sense to
> you.

As far as using Cocoon for rendering, I'm all for it. But in Maven we
are moving toward integrating the use of Ant inside Jelly (JSTL like
tags) and using Jelly scripts for our internals and plugins. Though
Maven will be 100% integrated it won't be the primary mechanism. Ant
just really sucks for reuse. We think we can drastically simplify Maven
by using Jelly directly instead of Ant. So we're definitely not going to
be on the same wave length there.

As far as ideas, collaboration would be great. But in all honesty I
don't see any of pieces of code in Centipede being used in Maven once
Jelly is in full swing. We also think Jelly will be a better integrator
because you can easily use xsl type constructs, velocity, BSF or
whatever from inside Jelly so we think that will make more people happy.
We also use DVSL for all our transformation which doesn't make a lot of
XML folk happy and I don't have any plans on replacing what's there. If
additions are made we can accept XSL stuff I'm sure.

I never meant any of the animosity to culminate in the crap that
happened on the general list. Jon isn't a Maven developer and he wasn't
really in a position to say what he did and I didn't ask him to or
instigate his vocalization of Maven. I certainly think that unity is
essential in the arena of project management but I'm not going to
stipulate anything in the way Jon is.

Take a look at Jelly, if anything I think the use of this tool would
allow us to work together but I'm planning on proposing at some point to
nuke the gump descriptor in favor of the maven descriptor and allow
development to happen from there because I think our mechanisms for
upgrading the descriptor are there and I just think the momentum is
there. Additionally when the reactor, the CI tool I'm working on, is
complete it will do everything that Gump does with a greater degree of
control.

So I'm open to suggestions, I think my view is the one shared commonly
by the Maven folk so I don't know what to suggest.

How would you integrate the two projects? 

If Cocoon was fully integrated and XSL stuff could live along side DVSL
would that be enough to encourage more cooperation?

> --
> Nicola Ken Barozzi                   nicolaken@apache.org
>             - verba volant, scripta manent -
>    (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
-- 
jvz.

Jason van Zyl
jvanzyl@apache.org

http://tambora.zenplex.org


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message