[Lift] Re: Supporting Jetty 7 Continuations
Looks like you need to open a ticket for that :P
On Oct 8, 3:50 am, Timothy Perrett wrote:
> My point exactly!
>
> To that end, why dont we just add a small matching statement or switch
> that allows using Jetty 7 - only the package structure has changed not
> the continuation API itself so it should be fairly trivial. The jetty-
> runner stuff would really get me out of jetty-wrapper-hell that im in
> right now and would mean we could create an archetype that allows Lift
> apps to be deployable as a standalone JAR with jetty built in... would
> that not be über cool?
>
> Cheers, Tim
>
> On 7 Oct 2009, at 17:30, David Pollak wrote:
>
>
>
> > On Wed, Oct 7, 2009 at 9:19 AM, Timothy Perrett > > wrote:
>
> > I know that has been the plan - but I cant help but think that Servlet
> > 3.0 is still a long way off standardisation?
>
> > It's been 3 months away from being a standard for almost 2 years. ;-)
>
> > What do you think?
>
> > Cheers, Tim
>
> > On 7 Oct 2009, at 16:53, David Pollak wrote:
>
> > > I was hoping to generically support Servlet 3.0 continuations (which
> > > should work for Jetty 7 and Glassfish). Please open a ticket for
> > it.
>
> > > On Wed, Oct 7, 2009 at 2:23 AM, Timothy Perrett > > > wrote:
>
> > > Guys,
>
> > > I just wanted to rename this thread and raise this for proper
> > > discussion. API's between J6.x and J7.x appear to be the same, its
> > > mainly the package names and structure that have changed.
>
> > > Is it feasible to add a match statement to replace the current val
> > > assignments that have essentially hardcoded dependency on J6.x?
>
> > > There's some great stuff in Jetty 7 that would really help me (and
> > > lots of others) out
>
> > > Cheers, Tim
>
> > > On Oct 5, 5:20 pm, Timothy Perrett wrote:
> > > > Id say that it would be easier to use a match statement as part of
> > > the
> > > > val assignment... The current code is just using reflection, so
> > > > factoring into a case statement shouldnt be too tough right?
>
> > > > Thoughts?
>
> > > > Cheers, Tim
>
> > > > On 5 Oct 2009, at 16:48, Indrajit Raychaudhuri wrote:
>
> > > > > On 05/10/09 5:29 PM, Timothy Perrett wrote:
>
> > > > >> So I just wrote a Jetty 6 wrapper - getting the packaging
> > > working was
> > > > >> not ideal and not as flexible as Jetty 7 jetty-runner.
>
> > > > > Yes, just took a look at jetty-runner. Feature wise, it's blows
> > > away
> > > > > the
> > > > > older mechanism man!
>
> > > > >> Any thoughts in and around altering the lift code to adjust the
> > > > >> package based on jetty version?
>
> > > > > I can think of two options basically:
>
> > > > > 1. Move to jetty 7 and be done with it.
>
> > > > > 2. Allowing user option (via -Djetty.version) during
> > > > > archetype:generate.
> > > > > jetty.version can be an overridable archetype property that
> > > defaults
> > > > > to
> > > > > (say 6) but user can do -Djetty.version=7.
>
> > > > > Depending on the jetty version, the *.scala, *.xml etc. can be
> > > > > filtered
> > > > > to make the right kind of adjustment during archetype creation.
>
> > > > > Cheers, Indrajit
>
> > > > >> Cheers, Tim
>
> > > > >> On Oct 5, 9:07 am, Timothy Perrett
> > > wrote:
> > > > >>> Indrajit,
>
> > > > >>> Your right, jetty-runner is Jetty 7. The only tie we have to
> > > Jetty 6
> > > > >>> would be this line:
>
> > > > >>> val cc = Class.forName
> > > > >>> ("org.mortbay.util.ajax.ContinuationSupport")
>
> > > > >>> It would be trivial to add a match or whatever that determined
> > > the
> > > > >>> correct type to use... The question is, why haven't we done
> > this
> > > > >>> already? I suspect its just a time / capacity issue but wanted
> > > to
> > > > >>> check.
>
> > > > >>> I know I could write a jetty 6 wrapper, but that is my
> > fallback
> > > > >>> position as something more OOTB would be preferable.
>
> > > > >>> Cheers, Tim
>
> > > > >>> On Oct 5, 8:29 am, Indrajit Raychaudhuri
> > > > >>> wrote:
>
> > > > Tim,
>
> > > > Interestingly, we are trying out something similar in a
> > project
> > > > here and
> > > > this is absolutely cool stuff.
>
> > > > In fact, Zimbra Desktop does this too. Pure Prism+Jetty
> > > bundled as
> > > > 'desktop application'.
>
> > > > That you can have 'double-click' friendly application
> > helps :-)
>
> > > > Few notes:
>
> > > > 1. Embedding Jetty server is super easy with
> > > > org.mortbay.jetty.Server.
> > > > Something that we have in Lift - well almost ;-) The
> > > RunWebApp in
> > > > the
> > > > archetypes are primitive use case of such. [1]
>
> > > > 2. Jetty Runner is available only on Jetty 7.x series I think
> > > (not
> > > > certain). But yes, looks good either way.
>
> > > > 3. Jetty has this clean and nice way of having web-app
> > specific
> > > > jetty
> > > > config tucked inside the application (war or expanded) within
> > > > WEB-INF/jetty-w
[Lift] Re: Supporting Jetty 7 Continuations
My point exactly!
To that end, why dont we just add a small matching statement or switch
that allows using Jetty 7 - only the package structure has changed not
the continuation API itself so it should be fairly trivial. The jetty-
runner stuff would really get me out of jetty-wrapper-hell that im in
right now and would mean we could create an archetype that allows Lift
apps to be deployable as a standalone JAR with jetty built in... would
that not be über cool?
Cheers, Tim
On 7 Oct 2009, at 17:30, David Pollak wrote:
>
>
> On Wed, Oct 7, 2009 at 9:19 AM, Timothy Perrett > wrote:
>
> I know that has been the plan - but I cant help but think that Servlet
> 3.0 is still a long way off standardisation?
>
> It's been 3 months away from being a standard for almost 2 years. ;-)
>
>
> What do you think?
>
> Cheers, Tim
>
>
> On 7 Oct 2009, at 16:53, David Pollak wrote:
>
> > I was hoping to generically support Servlet 3.0 continuations (which
> > should work for Jetty 7 and Glassfish). Please open a ticket for
> it.
> >
> > On Wed, Oct 7, 2009 at 2:23 AM, Timothy Perrett > > wrote:
> >
> > Guys,
> >
> > I just wanted to rename this thread and raise this for proper
> > discussion. API's between J6.x and J7.x appear to be the same, its
> > mainly the package names and structure that have changed.
> >
> > Is it feasible to add a match statement to replace the current val
> > assignments that have essentially hardcoded dependency on J6.x?
> >
> > There's some great stuff in Jetty 7 that would really help me (and
> > lots of others) out
> >
> > Cheers, Tim
> >
> > On Oct 5, 5:20 pm, Timothy Perrett wrote:
> > > Id say that it would be easier to use a match statement as part of
> > the
> > > val assignment... The current code is just using reflection, so
> > > factoring into a case statement shouldnt be too tough right?
> > >
> > > Thoughts?
> > >
> > > Cheers, Tim
> > >
> > > On 5 Oct 2009, at 16:48, Indrajit Raychaudhuri wrote:
> > >
> > >
> > >
> > >
> > >
> > > > On 05/10/09 5:29 PM, Timothy Perrett wrote:
> > >
> > > >> So I just wrote a Jetty 6 wrapper - getting the packaging
> > working was
> > > >> not ideal and not as flexible as Jetty 7 jetty-runner.
> > >
> > > > Yes, just took a look at jetty-runner. Feature wise, it's blows
> > away
> > > > the
> > > > older mechanism man!
> > >
> > > >> Any thoughts in and around altering the lift code to adjust the
> > > >> package based on jetty version?
> > >
> > > > I can think of two options basically:
> > >
> > > > 1. Move to jetty 7 and be done with it.
> > >
> > > > 2. Allowing user option (via -Djetty.version) during
> > > > archetype:generate.
> > > > jetty.version can be an overridable archetype property that
> > defaults
> > > > to
> > > > (say 6) but user can do -Djetty.version=7.
> > >
> > > > Depending on the jetty version, the *.scala, *.xml etc. can be
> > > > filtered
> > > > to make the right kind of adjustment during archetype creation.
> > >
> > > > Cheers, Indrajit
> > >
> > > >> Cheers, Tim
> > >
> > > >> On Oct 5, 9:07 am, Timothy Perrett
> > wrote:
> > > >>> Indrajit,
> > >
> > > >>> Your right, jetty-runner is Jetty 7. The only tie we have to
> > Jetty 6
> > > >>> would be this line:
> > >
> > > >>> val cc = Class.forName
> > > >>> ("org.mortbay.util.ajax.ContinuationSupport")
> > >
> > > >>> It would be trivial to add a match or whatever that determined
> > the
> > > >>> correct type to use... The question is, why haven't we done
> this
> > > >>> already? I suspect its just a time / capacity issue but wanted
> > to
> > > >>> check.
> > >
> > > >>> I know I could write a jetty 6 wrapper, but that is my
> fallback
> > > >>> position as something more OOTB would be preferable.
> > >
> > > >>> Cheers, Tim
> > >
> > > >>> On Oct 5, 8:29 am, Indrajit Raychaudhuri
> > > >>> wrote:
> > >
> > > Tim,
> > >
> > > Interestingly, we are trying out something similar in a
> project
> > > here and
> > > this is absolutely cool stuff.
> > >
> > > In fact, Zimbra Desktop does this too. Pure Prism+Jetty
> > bundled as
> > > 'desktop application'.
> > >
> > > That you can have 'double-click' friendly application
> helps :-)
> > >
> > > Few notes:
> > >
> > > 1. Embedding Jetty server is super easy with
> > > org.mortbay.jetty.Server.
> > > Something that we have in Lift - well almost ;-) The
> > RunWebApp in
> > > the
> > > archetypes are primitive use case of such. [1]
> > >
> > > 2. Jetty Runner is available only on Jetty 7.x series I think
> > (not
> > > certain). But yes, looks good either way.
> > >
> > > 3. Jetty has this clean and nice way of having web-app
> specific
> > > jetty
> > > config tucked inside the application (war or expanded) within
> > > WEB-INF/jetty-web.xml which is basically an XmlConfiguration
> > > instance
> > > applied on the specific WebApplicationContext instead of the
> > > Container
>
[Lift] Re: Supporting Jetty 7 Continuations
On Wed, Oct 7, 2009 at 9:19 AM, Timothy Perrett wrote:
>
> I know that has been the plan - but I cant help but think that Servlet
> 3.0 is still a long way off standardisation?
>
It's been 3 months away from being a standard for almost 2 years. ;-)
>
> What do you think?
>
> Cheers, Tim
>
>
> On 7 Oct 2009, at 16:53, David Pollak wrote:
>
> > I was hoping to generically support Servlet 3.0 continuations (which
> > should work for Jetty 7 and Glassfish). Please open a ticket for it.
> >
> > On Wed, Oct 7, 2009 at 2:23 AM, Timothy Perrett > > wrote:
> >
> > Guys,
> >
> > I just wanted to rename this thread and raise this for proper
> > discussion. API's between J6.x and J7.x appear to be the same, its
> > mainly the package names and structure that have changed.
> >
> > Is it feasible to add a match statement to replace the current val
> > assignments that have essentially hardcoded dependency on J6.x?
> >
> > There's some great stuff in Jetty 7 that would really help me (and
> > lots of others) out
> >
> > Cheers, Tim
> >
> > On Oct 5, 5:20 pm, Timothy Perrett wrote:
> > > Id say that it would be easier to use a match statement as part of
> > the
> > > val assignment... The current code is just using reflection, so
> > > factoring into a case statement shouldnt be too tough right?
> > >
> > > Thoughts?
> > >
> > > Cheers, Tim
> > >
> > > On 5 Oct 2009, at 16:48, Indrajit Raychaudhuri wrote:
> > >
> > >
> > >
> > >
> > >
> > > > On 05/10/09 5:29 PM, Timothy Perrett wrote:
> > >
> > > >> So I just wrote a Jetty 6 wrapper - getting the packaging
> > working was
> > > >> not ideal and not as flexible as Jetty 7 jetty-runner.
> > >
> > > > Yes, just took a look at jetty-runner. Feature wise, it's blows
> > away
> > > > the
> > > > older mechanism man!
> > >
> > > >> Any thoughts in and around altering the lift code to adjust the
> > > >> package based on jetty version?
> > >
> > > > I can think of two options basically:
> > >
> > > > 1. Move to jetty 7 and be done with it.
> > >
> > > > 2. Allowing user option (via -Djetty.version) during
> > > > archetype:generate.
> > > > jetty.version can be an overridable archetype property that
> > defaults
> > > > to
> > > > (say 6) but user can do -Djetty.version=7.
> > >
> > > > Depending on the jetty version, the *.scala, *.xml etc. can be
> > > > filtered
> > > > to make the right kind of adjustment during archetype creation.
> > >
> > > > Cheers, Indrajit
> > >
> > > >> Cheers, Tim
> > >
> > > >> On Oct 5, 9:07 am, Timothy Perrett
> > wrote:
> > > >>> Indrajit,
> > >
> > > >>> Your right, jetty-runner is Jetty 7. The only tie we have to
> > Jetty 6
> > > >>> would be this line:
> > >
> > > >>> val cc = Class.forName
> > > >>> ("org.mortbay.util.ajax.ContinuationSupport")
> > >
> > > >>> It would be trivial to add a match or whatever that determined
> > the
> > > >>> correct type to use... The question is, why haven't we done this
> > > >>> already? I suspect its just a time / capacity issue but wanted
> > to
> > > >>> check.
> > >
> > > >>> I know I could write a jetty 6 wrapper, but that is my fallback
> > > >>> position as something more OOTB would be preferable.
> > >
> > > >>> Cheers, Tim
> > >
> > > >>> On Oct 5, 8:29 am, Indrajit Raychaudhuri
> > > >>> wrote:
> > >
> > > Tim,
> > >
> > > Interestingly, we are trying out something similar in a project
> > > here and
> > > this is absolutely cool stuff.
> > >
> > > In fact, Zimbra Desktop does this too. Pure Prism+Jetty
> > bundled as
> > > 'desktop application'.
> > >
> > > That you can have 'double-click' friendly application helps :-)
> > >
> > > Few notes:
> > >
> > > 1. Embedding Jetty server is super easy with
> > > org.mortbay.jetty.Server.
> > > Something that we have in Lift - well almost ;-) The
> > RunWebApp in
> > > the
> > > archetypes are primitive use case of such. [1]
> > >
> > > 2. Jetty Runner is available only on Jetty 7.x series I think
> > (not
> > > certain). But yes, looks good either way.
> > >
> > > 3. Jetty has this clean and nice way of having web-app specific
> > > jetty
> > > config tucked inside the application (war or expanded) within
> > > WEB-INF/jetty-web.xml which is basically an XmlConfiguration
> > > instance
> > > applied on the specific WebApplicationContext instead of the
> > > Container
> > > Context. [2]
> > >
> > > 4. An archetype that does self deploying is something that I
> > have
> > > on my
> > > todo-list. Do you think this would make sense?
> > >
> > > 5. Maven assembly plugin would do. I haven't tried this
> > myself, but
> > > Maven shade plugin looks something close. [3]
> > >
> > > [1]http://docs.codehaus.org/display/JETTY/Embedding+Jetty
> > > [2]http://docs.codehaus.org/display/JETTY/jetty-web.xml
> > > [3]http://maven.apache.org/plugins/maven-shade-plugin/
> > >
> > > Cheers, Indrajit
[Lift] Re: Supporting Jetty 7 Continuations
I know that has been the plan - but I cant help but think that Servlet
3.0 is still a long way off standardisation?
What do you think?
Cheers, Tim
On 7 Oct 2009, at 16:53, David Pollak wrote:
> I was hoping to generically support Servlet 3.0 continuations (which
> should work for Jetty 7 and Glassfish). Please open a ticket for it.
>
> On Wed, Oct 7, 2009 at 2:23 AM, Timothy Perrett > wrote:
>
> Guys,
>
> I just wanted to rename this thread and raise this for proper
> discussion. API's between J6.x and J7.x appear to be the same, its
> mainly the package names and structure that have changed.
>
> Is it feasible to add a match statement to replace the current val
> assignments that have essentially hardcoded dependency on J6.x?
>
> There's some great stuff in Jetty 7 that would really help me (and
> lots of others) out
>
> Cheers, Tim
>
> On Oct 5, 5:20 pm, Timothy Perrett wrote:
> > Id say that it would be easier to use a match statement as part of
> the
> > val assignment... The current code is just using reflection, so
> > factoring into a case statement shouldnt be too tough right?
> >
> > Thoughts?
> >
> > Cheers, Tim
> >
> > On 5 Oct 2009, at 16:48, Indrajit Raychaudhuri wrote:
> >
> >
> >
> >
> >
> > > On 05/10/09 5:29 PM, Timothy Perrett wrote:
> >
> > >> So I just wrote a Jetty 6 wrapper - getting the packaging
> working was
> > >> not ideal and not as flexible as Jetty 7 jetty-runner.
> >
> > > Yes, just took a look at jetty-runner. Feature wise, it's blows
> away
> > > the
> > > older mechanism man!
> >
> > >> Any thoughts in and around altering the lift code to adjust the
> > >> package based on jetty version?
> >
> > > I can think of two options basically:
> >
> > > 1. Move to jetty 7 and be done with it.
> >
> > > 2. Allowing user option (via -Djetty.version) during
> > > archetype:generate.
> > > jetty.version can be an overridable archetype property that
> defaults
> > > to
> > > (say 6) but user can do -Djetty.version=7.
> >
> > > Depending on the jetty version, the *.scala, *.xml etc. can be
> > > filtered
> > > to make the right kind of adjustment during archetype creation.
> >
> > > Cheers, Indrajit
> >
> > >> Cheers, Tim
> >
> > >> On Oct 5, 9:07 am, Timothy Perrett
> wrote:
> > >>> Indrajit,
> >
> > >>> Your right, jetty-runner is Jetty 7. The only tie we have to
> Jetty 6
> > >>> would be this line:
> >
> > >>> val cc = Class.forName
> > >>> ("org.mortbay.util.ajax.ContinuationSupport")
> >
> > >>> It would be trivial to add a match or whatever that determined
> the
> > >>> correct type to use... The question is, why haven't we done this
> > >>> already? I suspect its just a time / capacity issue but wanted
> to
> > >>> check.
> >
> > >>> I know I could write a jetty 6 wrapper, but that is my fallback
> > >>> position as something more OOTB would be preferable.
> >
> > >>> Cheers, Tim
> >
> > >>> On Oct 5, 8:29 am, Indrajit Raychaudhuri
> > >>> wrote:
> >
> > Tim,
> >
> > Interestingly, we are trying out something similar in a project
> > here and
> > this is absolutely cool stuff.
> >
> > In fact, Zimbra Desktop does this too. Pure Prism+Jetty
> bundled as
> > 'desktop application'.
> >
> > That you can have 'double-click' friendly application helps :-)
> >
> > Few notes:
> >
> > 1. Embedding Jetty server is super easy with
> > org.mortbay.jetty.Server.
> > Something that we have in Lift - well almost ;-) The
> RunWebApp in
> > the
> > archetypes are primitive use case of such. [1]
> >
> > 2. Jetty Runner is available only on Jetty 7.x series I think
> (not
> > certain). But yes, looks good either way.
> >
> > 3. Jetty has this clean and nice way of having web-app specific
> > jetty
> > config tucked inside the application (war or expanded) within
> > WEB-INF/jetty-web.xml which is basically an XmlConfiguration
> > instance
> > applied on the specific WebApplicationContext instead of the
> > Container
> > Context. [2]
> >
> > 4. An archetype that does self deploying is something that I
> have
> > on my
> > todo-list. Do you think this would make sense?
> >
> > 5. Maven assembly plugin would do. I haven't tried this
> myself, but
> > Maven shade plugin looks something close. [3]
> >
> > [1]http://docs.codehaus.org/display/JETTY/Embedding+Jetty
> > [2]http://docs.codehaus.org/display/JETTY/jetty-web.xml
> > [3]http://maven.apache.org/plugins/maven-shade-plugin/
> >
> > Cheers, Indrajit
> >
> > NB: Looks like quite a few night owl here!
> >
> > On 05/10/09 4:11 AM, Timothy Perrett wrote:
> >
> > > Viktor, you and I should not be up this late on a sunday! ;-)
> >
> > > You have to see this:http://blogs.webtide.com/janb/entry/
> > > jetty_runner
> >
> > > Im going to hash this together as a maven assembly; if it
> works,
> > > then
> > > i'll writ
[Lift] Re: Supporting Jetty 7 Continuations
I was hoping to generically support Servlet 3.0 continuations (which should
work for Jetty 7 and Glassfish). Please open a ticket for it.
On Wed, Oct 7, 2009 at 2:23 AM, Timothy Perrett wrote:
>
> Guys,
>
> I just wanted to rename this thread and raise this for proper
> discussion. API's between J6.x and J7.x appear to be the same, its
> mainly the package names and structure that have changed.
>
> Is it feasible to add a match statement to replace the current val
> assignments that have essentially hardcoded dependency on J6.x?
>
> There's some great stuff in Jetty 7 that would really help me (and
> lots of others) out
>
> Cheers, Tim
>
> On Oct 5, 5:20 pm, Timothy Perrett wrote:
> > Id say that it would be easier to use a match statement as part of the
> > val assignment... The current code is just using reflection, so
> > factoring into a case statement shouldnt be too tough right?
> >
> > Thoughts?
> >
> > Cheers, Tim
> >
> > On 5 Oct 2009, at 16:48, Indrajit Raychaudhuri wrote:
> >
> >
> >
> >
> >
> > > On 05/10/09 5:29 PM, Timothy Perrett wrote:
> >
> > >> So I just wrote a Jetty 6 wrapper - getting the packaging working was
> > >> not ideal and not as flexible as Jetty 7 jetty-runner.
> >
> > > Yes, just took a look at jetty-runner. Feature wise, it's blows away
> > > the
> > > older mechanism man!
> >
> > >> Any thoughts in and around altering the lift code to adjust the
> > >> package based on jetty version?
> >
> > > I can think of two options basically:
> >
> > > 1. Move to jetty 7 and be done with it.
> >
> > > 2. Allowing user option (via -Djetty.version) during
> > > archetype:generate.
> > > jetty.version can be an overridable archetype property that defaults
> > > to
> > > (say 6) but user can do -Djetty.version=7.
> >
> > > Depending on the jetty version, the *.scala, *.xml etc. can be
> > > filtered
> > > to make the right kind of adjustment during archetype creation.
> >
> > > Cheers, Indrajit
> >
> > >> Cheers, Tim
> >
> > >> On Oct 5, 9:07 am, Timothy Perrett wrote:
> > >>> Indrajit,
> >
> > >>> Your right, jetty-runner is Jetty 7. The only tie we have to Jetty 6
> > >>> would be this line:
> >
> > >>> val cc = Class.forName
> > >>> ("org.mortbay.util.ajax.ContinuationSupport")
> >
> > >>> It would be trivial to add a match or whatever that determined the
> > >>> correct type to use... The question is, why haven't we done this
> > >>> already? I suspect its just a time / capacity issue but wanted to
> > >>> check.
> >
> > >>> I know I could write a jetty 6 wrapper, but that is my fallback
> > >>> position as something more OOTB would be preferable.
> >
> > >>> Cheers, Tim
> >
> > >>> On Oct 5, 8:29 am, Indrajit Raychaudhuri
> > >>> wrote:
> >
> > Tim,
> >
> > Interestingly, we are trying out something similar in a project
> > here and
> > this is absolutely cool stuff.
> >
> > In fact, Zimbra Desktop does this too. Pure Prism+Jetty bundled as
> > 'desktop application'.
> >
> > That you can have 'double-click' friendly application helps :-)
> >
> > Few notes:
> >
> > 1. Embedding Jetty server is super easy with
> > org.mortbay.jetty.Server.
> > Something that we have in Lift - well almost ;-) The RunWebApp in
> > the
> > archetypes are primitive use case of such. [1]
> >
> > 2. Jetty Runner is available only on Jetty 7.x series I think (not
> > certain). But yes, looks good either way.
> >
> > 3. Jetty has this clean and nice way of having web-app specific
> > jetty
> > config tucked inside the application (war or expanded) within
> > WEB-INF/jetty-web.xml which is basically an XmlConfiguration
> > instance
> > applied on the specific WebApplicationContext instead of the
> > Container
> > Context. [2]
> >
> > 4. An archetype that does self deploying is something that I have
> > on my
> > todo-list. Do you think this would make sense?
> >
> > 5. Maven assembly plugin would do. I haven't tried this myself, but
> > Maven shade plugin looks something close. [3]
> >
> > [1]http://docs.codehaus.org/display/JETTY/Embedding+Jetty
> > [2]http://docs.codehaus.org/display/JETTY/jetty-web.xml
> > [3]http://maven.apache.org/plugins/maven-shade-plugin/
> >
> > Cheers, Indrajit
> >
> > NB: Looks like quite a few night owl here!
> >
> > On 05/10/09 4:11 AM, Timothy Perrett wrote:
> >
> > > Viktor, you and I should not be up this late on a sunday! ;-)
> >
> > > You have to see this:http://blogs.webtide.com/janb/entry/
> > > jetty_runner
> >
> > > Im going to hash this together as a maven assembly; if it works,
> > > then
> > > i'll write a blog and stuff it on the wiki... this could really
> > > make
> > > self deploying apps very nice indeed. I'll check with DavidB,
> > > but im
> > > fairly sure it would also be trivial to make a little maven plugin
> > > that builds a single
