Re: [jetty-dev] Deployment manager states

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

All this being said...I wanted to take a quick step back and start the
review of the artifacts going into 7.0.1 as this has direct bearing on
that...

there are a couple of things in jetty trunk that are currently
deploying snapshot wise into jetty @ eclipse maven central artifact
space and that bears review with this.

namely the jetty-webapp-verifier and the jetty-centalized-logging bits
and pieces..

So, with the idea in mind that jetty @ eclipse is supposed to be best
of breed components and represent the _core_ of jetty I am thinking
that maybe we want to change this a bit.

I propose that maybe the above artifacts and this jetty-deployer work
all go back to codehaus trunk for stewing and to gain some community
traction.  Then if and when these artifacts gain a larger backing and
usage and we want to accept them into honest to god jetty core, we go
ahead and move them over (following whatever processes we need).

This represents a bit of backpedaling on my part (ok maybe a lot) as I
have been an advocate of just getting new development going on at
eclipse, but at least for now I am thinking that we ought to let
things stew at codehaus longer...and also focus on making sure that
eclipse side is a trim lean mean fighting machine, both code and
process wise within eclipse.

thoughts?

jesse


--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx



On Thu, Oct 22, 2009 at 22:28, Michael Gorovoy <michael@xxxxxxxxxxx> wrote:
> +1 for Jesse, and here's my 2 cents worth of thoughts on this issues.
>
> It would take a very sophisticated developer as well as a major effort right
> now to be able to re-wire the application deployment lifecycle, and I agree
> with Jesse that Jetty needs to have a way to extend the core lifecycle at
> the configuration phase to include additional arbitrary steps at any point
> in the lifecycle, as well as change the cofiguration of the existing steps.
>
> I would suggest to specify the application deployment lifecycle in terms of
> 'goals' describing where the application is in the deployment process, and
> 'transitions', that define the conditions that need to be met and actions
> that need to be performed to move the application to the next 'goal' in the
> lifecycle.
>
> Each goal would be reachable by any number of transitions, but would have
> only one exit transition associated with it. Each goal could be either
> stateful or transitional. When deployment process reaches a stateful goal,
> the lifecycle will not process the next transition until it is externally
> re-activated, whereas when deployment process reaches a transitional goal,
> the next transition will be processed immediately after reaching this goal.
> Each transition would have two possible result goals that it can bring the
> lifecycle to, one for success and the other one for failure.
>
> As long as the new architecture will be flexible enough to allow configuring
> an arbitrary deployment lifecycle using the above abstractions, with goals
> possibly represented by entries in a data structure, and transitions defined
> by classes that implement a specified interface, it would be possible to
> achieve the configurability and avoid having to create an one-size-fits-all
> solution.
>
> Michael Gorovoy / michael@xxxxxxxxxxx
>
>
> On Thu, Oct 22, 2009 at 9:08 PM, Jesse McConnell <jesse.mcconnell@xxxxxxxxx>
> wrote:
>>
>> lets see...
>>
>> I see the action of wiring up something like the webapp verifier as a
>> step in the deployment of a webapp, maybe not a full on 'STATE" but
>> certainly one step in the process
>>
>> so long as there is a simple way of arbitrarily wiring functionality X
>> to the lifecycle of deployment I am pretty happy personally
>>
>> and that functionality X should be able to run the gambit from webapp
>> verification, to mailing a mailing list that a webapp has deployed, to
>> complex scenarios involving coordination in a cluster
>>
>> I should also be able to wire those up so they execute in a simple
>> order as well...
>>
>> When I was looking at wiring up the webapp verifier previously I added
>> it as a part of webapp configuration itself which it really wasn't I
>> guess, it was more of a sanity check that this webapp was going to be
>> allowed to deploy at all, much less get configured, etc...so it really
>> should have been able to slot in somewhere prior to webapp
>> configuration even taking place....
>>
>> we can do a lot of this kinda stuff as jetty developers, but my
>> concern here is that I see definite points in here that a third party
>> could want to insert their own functionality in the deployment process
>> and it currently takes a harder core developer to implement
>>
>> anyway, I have said my bit...i like the idea of a simple framework
>> located on this part of jetty that allows third parties to implement
>> new workflows on top of (like the jetty maven plugin for example)
>>
>> jesse
>>
>> --
>> jesse mcconnell
>> jesse.mcconnell@xxxxxxxxx
>>
>>
>>
>> On Thu, Oct 22, 2009 at 18:48, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:
>> > Jesse McConnell wrote:
>> >> Core lifecycle? certainly not
>> >>
>> >> a common use case for workflow as it relates to deployment, sure
>> >
>> >
>> > If Stage is the only optional workflow state that we can think of,
>> > then I'd prefer to have it in the base state machine and avoid
>> > the hassles of a dynamically extensible state machine that would
>> > be required to optionally support extra states.
>> >
>> >
>> > cheers
>> >
>> >
>> >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe from this list, please visit:
>> >
>> >    http://xircles.codehaus.org/manage_email
>> >
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>