You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2002/08/21 01:26:06 UTC
Maven, notes from XtC with James Strachan and Vincent Massol
Folks,
As promised I cornered first Vincent Massol and then James Strachan on
the subject of Maven and Jelly (though the latter is not as obviously
compelling to us). Getting close to them at the way-busier than usual
eXtreme Tuesday was difficult. It was a bit like Joseph Conrad's "Heart
of Darkness" (filmed as Apocalypse Now).
Anyway, it seems Maven is ready for prime time. My previous assumption
is that Maven is best for template solutions (Excalibur's various
sub-projects being a good example). I was wrong it is just as good for
single highly customised project builds. Virtually everyone there left
with a good impression of Maven and a mental note to use it soon in
company and open-source solutions ASAP. I'm going to compare notes with
some people who have been using it for a while and see what they think.
Essentially though, I am left with the impression that we should phase
it in real soon.
James spent quite a bit of time talking of Jelly. Way cool, check it
out: http://jakarta.apache.org/commons/sandbox/jelly/
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Maven, notes from XtC with James Strachan and Vincent Massol
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote:
>
>
> Nicola Ken Barozzi wrote:
>
>>
>> Paul Hammant wrote:
>>
>>> Stephen,
>>>
>>>>>> I'm going to compare notes with some people who have been using it
>>>>>> for a while and see what they think.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> OK, I've chatted to others at XtC last night. There seems to be
>>>>> nothing but admiration for Maven. Of those using Maven for the
>>>>> last couple of months amonsgst my contacts, there have been no
>>>>> regrets.
>>>>>
>>>>> I think we should avail of Jason (and others) help. It may be best
>>>>> to start in Avalon-Excalibur as I have spend loads of time
>>>>> harmonising the build files. If every a project-object-model was
>>>>> justifiable, Excalibur is it. There is about 50:50 split between
>>>>> Anakia and Cocoon for doc building, but flipping to one or the
>>>>> other for consitency should not be hard now.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Maybe 60:40 - Merlin has dropped Anika in favour of Cocoon.
>>>
>>>
>>>
>>>
>>> Yup, that makes me remember the thing that has been nagging me since
>>> mulling this Maven thing - We are being disloyal to Nicola Ken.
>>> He's been a loyal fan and servant of the Avalon and Cocoon community
>>> since the beginning of the year (and probably before) and we invited
>>> him into our CVS, originally with much enthusiasm to turn everything
>>> into a Centipede compatible build system. In the ideal world two
>>> projects would never have started at the same time with people from
>>> the same community, but it happened. I guess there is difference
>>> enough to preclude a merger nowadays. Nicola, this is nothing
>>> personal, it is just an inevitability given Maven is going primetime
>>> and the bleeding edge Apache projects are moving towards it.
>>
>>
>>
>> The fact is that Centipede did more than an month ago most of what
>> MAven does now, and is now continuing development.
>>
>> There is nothing in Maven that Centipede doesn't or is not going to
>> have soon.
>> The much hyped reactor is not much different from Gump, the descriptor
>> too, and Centipede does it all with much less code.
>> Well, none in fact, it just uses Ant in a clever way.
>>
>> The real difference is that Maven gets more attention and use, which
>> is due to the fact that I chose to start the project on SF rather than
>> in Apache, trying to follow our guidelines instead of stretching them.
>>
>> As I already said to the James community, wait for final releases of
>> the two, and test them.
>> Only *then* make a decision.
>
> Any indications of the timeline here ?
Centipede was ahead before, but Maven lately gained features quickly,
and we are in a similar state.
I think (as it seems) that Maven and Centipede will go final in roughly
the same period, but don't be too demanding on the actual date ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Maven, notes from XtC with James Strachan and Vincent Massol
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Paul Hammant wrote:
>
>> Stephen,
>>
>>>>> I'm going to compare notes with some people who have been using it
>>>>> for a while and see what they think.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> OK, I've chatted to others at XtC last night. There seems to be
>>>> nothing but admiration for Maven. Of those using Maven for the
>>>> last couple of months amonsgst my contacts, there have been no
>>>> regrets.
>>>>
>>>> I think we should avail of Jason (and others) help. It may be best
>>>> to start in Avalon-Excalibur as I have spend loads of time
>>>> harmonising the build files. If every a project-object-model was
>>>> justifiable, Excalibur is it. There is about 50:50 split between
>>>> Anakia and Cocoon for doc building, but flipping to one or the
>>>> other for consitency should not be hard now.
>>>
>>>
>>>
>>>
>>>
>>> Maybe 60:40 - Merlin has dropped Anika in favour of Cocoon.
>>
>>
>>
>> Yup, that makes me remember the thing that has been nagging me since
>> mulling this Maven thing - We are being disloyal to Nicola Ken.
>> He's been a loyal fan and servant of the Avalon and Cocoon community
>> since the beginning of the year (and probably before) and we invited
>> him into our CVS, originally with much enthusiasm to turn everything
>> into a Centipede compatible build system. In the ideal world two
>> projects would never have started at the same time with people from
>> the same community, but it happened. I guess there is difference
>> enough to preclude a merger nowadays. Nicola, this is nothing
>> personal, it is just an inevitability given Maven is going primetime
>> and the bleeding edge Apache projects are moving towards it.
>
>
> The fact is that Centipede did more than an month ago most of what
> MAven does now, and is now continuing development.
>
> There is nothing in Maven that Centipede doesn't or is not going to
> have soon.
> The much hyped reactor is not much different from Gump, the descriptor
> too, and Centipede does it all with much less code.
> Well, none in fact, it just uses Ant in a clever way.
>
> The real difference is that Maven gets more attention and use, which
> is due to the fact that I chose to start the project on SF rather than
> in Apache, trying to follow our guidelines instead of stretching them.
>
> As I already said to the James community, wait for final releases of
> the two, and test them.
> Only *then* make a decision.
Any indications of the timeline here ?
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Maven, notes from XtC with James Strachan and Vincent Massol
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote:
> Stephen,
>
>>>> I'm going to compare notes with some people who have been using it
>>>> for a while and see what they think.
>>>
>>>
>>>
>>>
>>> OK, I've chatted to others at XtC last night. There seems to be
>>> nothing but admiration for Maven. Of those using Maven for the last
>>> couple of months amonsgst my contacts, there have been no regrets.
>>>
>>> I think we should avail of Jason (and others) help. It may be best
>>> to start in Avalon-Excalibur as I have spend loads of time
>>> harmonising the build files. If every a project-object-model was
>>> justifiable, Excalibur is it. There is about 50:50 split between
>>> Anakia and Cocoon for doc building, but flipping to one or the other
>>> for consitency should not be hard now.
>>
>>
>>
>>
>> Maybe 60:40 - Merlin has dropped Anika in favour of Cocoon.
>
>
> Yup, that makes me remember the thing that has been nagging me since
> mulling this Maven thing - We are being disloyal to Nicola Ken. He's
> been a loyal fan and servant of the Avalon and Cocoon community since
> the beginning of the year (and probably before) and we invited him into
> our CVS, originally with much enthusiasm to turn everything into a
> Centipede compatible build system. In the ideal world two projects
> would never have started at the same time with people from the same
> community, but it happened. I guess there is difference enough to
> preclude a merger nowadays.
> Nicola, this is nothing personal, it is just an inevitability given
> Maven is going primetime and the bleeding edge Apache projects are
> moving towards it.
The fact is that Centipede did more than an month ago most of what MAven
does now, and is now continuing development.
There is nothing in Maven that Centipede doesn't or is not going to have
soon.
The much hyped reactor is not much different from Gump, the descriptor
too, and Centipede does it all with much less code.
Well, none in fact, it just uses Ant in a clever way.
The real difference is that Maven gets more attention and use, which is
due to the fact that I chose to start the project on SF rather than in
Apache, trying to follow our guidelines instead of stretching them.
As I already said to the James community, wait for final releases of the
two, and test them.
Only *then* make a decision.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Maven, notes from XtC with James Strachan and Vincent Massol
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
>>> I'm going to compare notes with some people who have been using it
>>> for a while and see what they think.
>>
>>
>>
>> OK, I've chatted to others at XtC last night. There seems to be
>> nothing but admiration for Maven. Of those using Maven for the last
>> couple of months amonsgst my contacts, there have been no regrets.
>>
>> I think we should avail of Jason (and others) help. It may be best
>> to start in Avalon-Excalibur as I have spend loads of time
>> harmonising the build files. If every a project-object-model was
>> justifiable, Excalibur is it. There is about 50:50 split between
>> Anakia and Cocoon for doc building, but flipping to one or the other
>> for consitency should not be hard now.
>
>
>
> Maybe 60:40 - Merlin has dropped Anika in favour of Cocoon.
Yup, that makes me remember the thing that has been nagging me since
mulling this Maven thing - We are being disloyal to Nicola Ken. He's
been a loyal fan and servant of the Avalon and Cocoon community since
the beginning of the year (and probably before) and we invited him into
our CVS, originally with much enthusiasm to turn everything into a
Centipede compatible build system. In the ideal world two projects
would never have started at the same time with people from the same
community, but it happened. I guess there is difference enough to
preclude a merger nowadays.
Nicola, this is nothing personal, it is just an inevitability given
Maven is going primetime and the bleeding edge Apache projects are
moving towards it.
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Maven, notes from XtC with James Strachan and Vincent Massol
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
> Folks,
>
>> I'm going to compare notes with some people who have been using it
>> for a while and see what they think.
>
>
> OK, I've chatted to others at XtC last night. There seems to be
> nothing but admiration for Maven. Of those using Maven for the last
> couple of months amonsgst my contacts, there have been no regrets.
>
> I think we should avail of Jason (and others) help. It may be best to
> start in Avalon-Excalibur as I have spend loads of time harmonising
> the build files. If every a project-object-model was justifiable,
> Excalibur is it. There is about 50:50 split between Anakia and Cocoon
> for doc building, but flipping to one or the other for consitency
> should not be hard now.
Maybe 60:40 - Merlin has dropped Anika in favour of Cocoon.
Steve.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Maven, notes from XtC with James Strachan and Vincent Massol
Posted by Paul Hammant <Pa...@yahoo.com>.
Folks,
> I'm going to compare notes with some people who have been using it for
> a while and see what they think.
OK, I've chatted to others at XtC last night. There seems to be nothing
but admiration for Maven. Of those using Maven for the last couple of
months amonsgst my contacts, there have been no regrets.
I think we should avail of Jason (and others) help. It may be best to
start in Avalon-Excalibur as I have spend loads of time harmonising the
build files. If every a project-object-model was justifiable, Excalibur
is it. There is about 50:50 split between Anakia and Cocoon for doc
building, but flipping to one or the other for consitency should not be
hard now.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] Maven as an Avalon container (Re: Maven, notes from XtC
with James Strachan and Vincent Massol)
Posted by Jason van Zyl <ja...@zenplex.com>.
On Wed, 2002-08-21 at 18:09, Peter Donald wrote:
> On Wed, 21 Aug 2002 21:18, Jeff Turner wrote:
> > On Tue, Aug 20, 2002 at 08:35:36PM -0400, Jason van Zyl wrote:
> > ...
> >
> > > I can keep making Avalon project descriptors, help others make them,
> > > help with a forrest plugin if that's what you would prefer to use for
> > > your docs and I will help keep them updated.
> >
> > FYI, I have a basic Forrest plugin working. It is *very* basic though,
> > and not yet configurable through ${maven.*} properties. Most of the work
> > involves fixing Forrest Ant scripts.
>
> Kool - want to send it to the list so we can see how it looks ? ;)
>
> > A random thought wrt. Maven and Avalon: imagine if Maven had an embedded
> > Avalon container (phoenix or something), with which plugins could
> > register Components to be deployed (eg phoenix .sars). This could have a
> > number of uses:
>
> Theres two things in the above;
>
> 1. a server that kicks of a maven process after certain events - whether they
> be time based, based on changes in external environment or due to messages
> from external processes
This is where Drools and Werkflow come in. Zenplex hired Bob McWhirter
for a while to get Werkflow going and Bob has subsequently been working
on Drools and Werkflow. So we'll be integrating a real workflow system
based a real rules engine that uses the RETE algorithm. It's described
here:
http://www.drools.org/pdf/drools-guide.pdf
None of the other OSS workflow packages that I know of use a real rules
engine.
> 2. Each maven process allows dynamic addition of services to runtime as a
> means of extensions
>
> Both are very useful things. (2) will in effect allow you to integrate into
> virtually any command/processes based activity. Someone told me that they
> used myrmidon to control their home stereo system by adding a special service
> in ;)
>
> > - Heavy plugins like Forrest could use a client/server architecture. Eg,
> > the Forrest plugin deploys a 'server' component (Cocoon), and then
> > when the user says 'maven forrest:transform', an RMI request is made
> > to the server: "render directory X". Saves lots of startup time.
> >
> > - One could have 'asynchronous' Maven targets, eg a plugin that scans
> > xdocs/* every 5s, and regenerates any docs that change, or a
> > nightly-build plugin, or other continuous integration-type things like
> > Gump.
> >
> > This could possibly be implemented with an 'avalon' plugin, plus a Jelly
> > taglib for invoking, deploying and undeploying Components. Plugins can
> > then use the jelly taglib to launch whatever stateful components they
> > want.
> >
> > As the subject says, just a RT..
>
> kool one at that.
>
> --
> Cheers,
>
> Peter Donald
> ---------------------------------------------------
> "Therefore it can be said that victorious warriors
> win first, and then go to battle, while defeated
> warriors go to battle first, and then seek to win."
> - Sun Tzu, the Art Of War
> ---------------------------------------------------
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@apache.org
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] Maven as an Avalon container (Re: Maven, notes from XtC
with James Strachan and Vincent Massol)
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>A random thought wrt. Maven and Avalon: imagine if Maven had an embedded
>>Avalon container (phoenix or something), with which plugins could
>>register Components to be deployed (eg phoenix .sars). This could have a
>>number of uses:
>>
>>
>
>Theres two things in the above;
>
>1. a server that kicks of a maven process after certain events - whether they
>be time based, based on changes in external environment or due to messages
>from external processes
>
A Maven invoking Phoenix mounted block would be cool. One that
responded to cron events could replace CruiseControl's basic features.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] Maven as an Avalon container (Re: Maven, notes from XtC with James Strachan and Vincent Massol)
Posted by Peter Donald <pe...@apache.org>.
On Wed, 21 Aug 2002 21:18, Jeff Turner wrote:
> On Tue, Aug 20, 2002 at 08:35:36PM -0400, Jason van Zyl wrote:
> ...
>
> > I can keep making Avalon project descriptors, help others make them,
> > help with a forrest plugin if that's what you would prefer to use for
> > your docs and I will help keep them updated.
>
> FYI, I have a basic Forrest plugin working. It is *very* basic though,
> and not yet configurable through ${maven.*} properties. Most of the work
> involves fixing Forrest Ant scripts.
Kool - want to send it to the list so we can see how it looks ? ;)
> A random thought wrt. Maven and Avalon: imagine if Maven had an embedded
> Avalon container (phoenix or something), with which plugins could
> register Components to be deployed (eg phoenix .sars). This could have a
> number of uses:
Theres two things in the above;
1. a server that kicks of a maven process after certain events - whether they
be time based, based on changes in external environment or due to messages
from external processes
2. Each maven process allows dynamic addition of services to runtime as a
means of extensions
Both are very useful things. (2) will in effect allow you to integrate into
virtually any command/processes based activity. Someone told me that they
used myrmidon to control their home stereo system by adding a special service
in ;)
> - Heavy plugins like Forrest could use a client/server architecture. Eg,
> the Forrest plugin deploys a 'server' component (Cocoon), and then
> when the user says 'maven forrest:transform', an RMI request is made
> to the server: "render directory X". Saves lots of startup time.
>
> - One could have 'asynchronous' Maven targets, eg a plugin that scans
> xdocs/* every 5s, and regenerates any docs that change, or a
> nightly-build plugin, or other continuous integration-type things like
> Gump.
>
> This could possibly be implemented with an 'avalon' plugin, plus a Jelly
> taglib for invoking, deploying and undeploying Components. Plugins can
> then use the jelly taglib to launch whatever stateful components they
> want.
>
> As the subject says, just a RT..
kool one at that.
--
Cheers,
Peter Donald
---------------------------------------------------
"Therefore it can be said that victorious warriors
win first, and then go to battle, while defeated
warriors go to battle first, and then seek to win."
- Sun Tzu, the Art Of War
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] Maven as an Avalon container (Re: Maven, notes from XtC
with James Strachan and Vincent Massol)
Posted by Jason van Zyl <ja...@zenplex.com>.
On Wed, 2002-08-21 at 07:24, Jason van Zyl wrote:
> > - Heavy plugins like Forrest could use a client/server architecture. Eg,
> > the Forrest plugin deploys a 'server' component (Cocoon), and then
> > when the user says 'maven forrest:transform', an RMI request is made
> > to the server: "render directory X". Saves lots of startup time.
>
> We plans for long-lived apps like consoles and the reactor will
> definitely be a long-lived process.
>
Ouch! I need the coffee infusion. That should be: we plan for tools like
a Maven console and the reactor to be long-lived processes. I've been
working on a Swing-based Maven console for a while but it will be quite
a while before I show anything. I use it but it's highly 'quirky' we'll
say. The reactor on the other hand is coming along, and is one of
priorities and it will be the basis of continuous integration processes.
--
jvz.
Jason van Zyl
jason@apache.org
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] Maven as an Avalon container
Posted by Jason van Zyl <ja...@zenplex.com>.
On Wed, 2002-08-21 at 10:12, Jeff Turner wrote:
> On Wed, Aug 21, 2002 at 07:24:18AM -0400, Jason van Zyl wrote:
> > On Wed, 2002-08-21 at 07:18, Jeff Turner wrote:
> ...
> > > A random thought wrt. Maven and Avalon: imagine if Maven had an embedded
> > > Avalon container (phoenix or something), with which plugins could
> > > register Components to be deployed (eg phoenix .sars). This could have a
> > > number of uses:
> >
> > It's not a random thought actually, I wanted plexus and Maven to share
> > the same container whatever that happens to be. Right now plexus and
> > Maven are using the same mechanis for processing plugins. Primitive, but
> > I'm waiting for things to settle down around here before flipping the
> > container in Plexus.
>
> Great! I gather Plexus is some sort of homegrown container? There's not
> much info about it. Will it end up at Jakarta?
It's a homegrown container, first based on Fortress and then on Tweety
when there were some glitches in Fortress with the move from Composable
to Serviceable. These were fixed but I just stuck with the tweety
variant as I'm really playing with components and trying to figure out
exactly how I want the overall thing to work. I hope to dump it and use
whatever you guys decide is the standard container. I have no desire to
write a full-blown container.
> > I've chatted with Peter about this too. I've made a point of not
> > mentioning it as it felt to me like a cheap tactic if I said Maven
> > might be based on Avalon.
>
> Well I just blew it for you then ;P
>
> ...
> > I think the most important thing for me to do right now is get the docs
> > back in line so people know what it planned.
>
> You must have a few forked versions of yourself working in parallel
> universes to keep up with turbine, maven, avalon and all ;) In case
> no-one's said it yet, thanks for the offers to help with the build
> system.
>
>
> --Jeff
>
> > Jason van Zyl
> > jason@apache.org
> > http://tambora.zenplex.org
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@apache.org
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] Maven as an Avalon container
Posted by Jeff Turner <je...@apache.org>.
On Wed, Aug 21, 2002 at 07:24:18AM -0400, Jason van Zyl wrote:
> On Wed, 2002-08-21 at 07:18, Jeff Turner wrote:
...
> > A random thought wrt. Maven and Avalon: imagine if Maven had an embedded
> > Avalon container (phoenix or something), with which plugins could
> > register Components to be deployed (eg phoenix .sars). This could have a
> > number of uses:
>
> It's not a random thought actually, I wanted plexus and Maven to share
> the same container whatever that happens to be. Right now plexus and
> Maven are using the same mechanis for processing plugins. Primitive, but
> I'm waiting for things to settle down around here before flipping the
> container in Plexus.
Great! I gather Plexus is some sort of homegrown container? There's not
much info about it. Will it end up at Jakarta?
> I've chatted with Peter about this too. I've made a point of not
> mentioning it as it felt to me like a cheap tactic if I said Maven
> might be based on Avalon.
Well I just blew it for you then ;P
...
> I think the most important thing for me to do right now is get the docs
> back in line so people know what it planned.
You must have a few forked versions of yourself working in parallel
universes to keep up with turbine, maven, avalon and all ;) In case
no-one's said it yet, thanks for the offers to help with the build
system.
--Jeff
> Jason van Zyl
> jason@apache.org
> http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] Maven as an Avalon container (Re: Maven, notes from XtC
with James Strachan and Vincent Massol)
Posted by Jason van Zyl <ja...@zenplex.com>.
On Wed, 2002-08-21 at 07:18, Jeff Turner wrote:
> On Tue, Aug 20, 2002 at 08:35:36PM -0400, Jason van Zyl wrote:
> ...
> > I can keep making Avalon project descriptors, help others make them,
> > help with a forrest plugin if that's what you would prefer to use for
> > your docs and I will help keep them updated.
>
> FYI, I have a basic Forrest plugin working. It is *very* basic though,
> and not yet configurable through ${maven.*} properties. Most of the work
> involves fixing Forrest Ant scripts.
>
> A random thought wrt. Maven and Avalon: imagine if Maven had an embedded
> Avalon container (phoenix or something), with which plugins could
> register Components to be deployed (eg phoenix .sars). This could have a
> number of uses:
It's not a random thought actually, I wanted plexus and Maven to share
the same container whatever that happens to be. Right now plexus and
Maven are using the same mechanis for processing plugins. Primitive, but
I'm waiting for things to settle down around here before flipping the
container in Plexus. I've chatted with Peter about this too. I've made a
point of not mentioning it as it felt to me like a cheap tactic if I
said Maven might be based on Avalon.
> - Heavy plugins like Forrest could use a client/server architecture. Eg,
> the Forrest plugin deploys a 'server' component (Cocoon), and then
> when the user says 'maven forrest:transform', an RMI request is made
> to the server: "render directory X". Saves lots of startup time.
We plans for long-lived apps like consoles and the reactor will
definitely be a long-lived process.
> - One could have 'asynchronous' Maven targets, eg a plugin that scans
> xdocs/* every 5s, and regenerates any docs that change, or a
> nightly-build plugin, or other continuous integration-type things like
> Gump.
Yes, this is the reactor.
> This could possibly be implemented with an 'avalon' plugin, plus a Jelly
> taglib for invoking, deploying and undeploying Components. Plugins can
> then use the jelly taglib to launch whatever stateful components they
> want.
>
> As the subject says, just a RT..
I think the most important thing for me to do right now is get the docs
back in line so people know what it planned.
>
> --Jeff
>
> > At any rate I am hopeful that Maven can provide what you need to make
> > things easier, generally more comprehensible for developers and
> > especially make life easier for your users.
> >
> > > James spent quite a bit of time talking of Jelly. Way cool, check it
> > > out: http://jakarta.apache.org/commons/sandbox/jelly/
> > >
> > > Regards,
> > >
> > > - Paul
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@apache.org
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[RT] Maven as an Avalon container (Re: Maven, notes from XtC with James Strachan and Vincent Massol)
Posted by Jeff Turner <je...@apache.org>.
On Tue, Aug 20, 2002 at 08:35:36PM -0400, Jason van Zyl wrote:
...
> I can keep making Avalon project descriptors, help others make them,
> help with a forrest plugin if that's what you would prefer to use for
> your docs and I will help keep them updated.
FYI, I have a basic Forrest plugin working. It is *very* basic though,
and not yet configurable through ${maven.*} properties. Most of the work
involves fixing Forrest Ant scripts.
A random thought wrt. Maven and Avalon: imagine if Maven had an embedded
Avalon container (phoenix or something), with which plugins could
register Components to be deployed (eg phoenix .sars). This could have a
number of uses:
- Heavy plugins like Forrest could use a client/server architecture. Eg,
the Forrest plugin deploys a 'server' component (Cocoon), and then
when the user says 'maven forrest:transform', an RMI request is made
to the server: "render directory X". Saves lots of startup time.
- One could have 'asynchronous' Maven targets, eg a plugin that scans
xdocs/* every 5s, and regenerates any docs that change, or a
nightly-build plugin, or other continuous integration-type things like
Gump.
This could possibly be implemented with an 'avalon' plugin, plus a Jelly
taglib for invoking, deploying and undeploying Components. Plugins can
then use the jelly taglib to launch whatever stateful components they
want.
As the subject says, just a RT..
--Jeff
> At any rate I am hopeful that Maven can provide what you need to make
> things easier, generally more comprehensible for developers and
> especially make life easier for your users.
>
> > James spent quite a bit of time talking of Jelly. Way cool, check it
> > out: http://jakarta.apache.org/commons/sandbox/jelly/
> >
> > Regards,
> >
> > - Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Maven, notes from XtC with James Strachan and Vincent Massol
Posted by Jason van Zyl <ja...@zenplex.com>.
On Tue, 2002-08-20 at 19:26, Paul Hammant wrote:
> Folks,
>
> As promised I cornered first Vincent Massol and then James Strachan on
> the subject of Maven and Jelly (though the latter is not as obviously
> compelling to us). Getting close to them at the way-busier than usual
> eXtreme Tuesday was difficult. It was a bit like Joseph Conrad's "Heart
> of Darkness" (filmed as Apocalypse Now).
>
> Anyway, it seems Maven is ready for prime time. My previous assumption
> is that Maven is best for template solutions (Excalibur's various
> sub-projects being a good example). I was wrong it is just as good for
> single highly customised project builds. Virtually everyone there left
> with a good impression of Maven and a mental note to use it soon in
> company and open-source solutions ASAP. I'm going to compare notes with
> some people who have been using it for a while and see what they think.
> Essentially though, I am left with the impression that we should phase
> it in real soon.
I am willing to provide any help necessary to make this happen. I think
that Peter found this time around that Maven was easy to build with. I
have a couple more Avalon project descriptors and I am very keen to see
more as I am now an Avalon user. Vincent is as well.
I am reworking the plug-in mechanism this week and the POM will go
through it's final phase of changes but we are estimating that these
will be the final changes as we have received quite a bit of feedback.
There's been ~1000 downloads of Maven from ibiblio so far, so we are
getting some useful feedback now.
There will be a beta-7 and probably a beta-8, after which we will enter
into the release candidate phase. There will still be some changes but
almost everything has been moved out of core so we have a small core
with a satellite of plug-ins.
I can keep making Avalon project descriptors, help others make them,
help with a forrest plugin if that's what you would prefer to use for
your docs and I will help keep them updated.
At any rate I am hopeful that Maven can provide what you need to make
things easier, generally more comprehensible for developers and
especially make life easier for your users.
> James spent quite a bit of time talking of Jelly. Way cool, check it
> out: http://jakarta.apache.org/commons/sandbox/jelly/
>
> Regards,
>
> - Paul
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@apache.org
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>