Re: Can we remove the offline deployer? Please speak up now.

[Aaron Mulder <am...@alumni.princeton.edu>]

On 12/1/05, Jeff Genender <jg...@apache.org> wrote:
> What impact will this have on distributing core server functions if I
> change something in the server based plans?

Ooh, good question.  I had not thought of that.  Hopefully David has
an answer.  :)

Otherwise, I'm fine with whacking the offline deployer.  IMHO it was
way too complicated for the value it offered.

Aaron

> David Jencks wrote:
> > Currently the offline deployer is a dreadful hack.  It loads a
> > completely separate set of builder gbeans than the running server, and
> > its restricted to 2 plans.  I believe it was originally developed as the
> > bootstrap mechanism for server assembly.  We now have a maven plugin
> > based system that is simpler and does not have the drawbacks of the
> > offline deployer.
> >
> > I would like to remove the offline deployer capabilities from the
> > deployer.jar.  I believe this will significantly simplify both the code
> > and cli for this tool.  I have some hope that we could even include all
> > the classes needed in the deployer.jar so it could be moved out of the
> > geronimo server bin/ and still work.
> >
> > If there is still significant demand for a standalone offline deployer
> > tool (rather than using the maven packaging plugin) I would like this to
> > be a separate tool essentially based on the maven packaging plugin,
> > although using the "current" geronimo server rather than the local maven
> > repo.
> >
> > thanks
> > david jencks
>

Re: Can we remove the offline deployer? Please speak up now.

[Aaron Mulder <am...@alumni.princeton.edu>]

OK -- I'm definitely happy to take the offline options out of the
normal deployer.  Hopefully with config.xml, the number of situations
that cause users to need to redeploy core configurations is pretty
small.

Though, would it really be that hard to support version ranges?  In
terms of scale, it seems like it could be easier than rewriting the
offline deployment.

Aaron

On 12/1/05, David Jencks <da...@yahoo.com> wrote:
> On Dec 1, 2005, at 12:29 PM, Aaron Mulder wrote:
>
> > On 12/1/05, Jeff Genender <jg...@apache.org> wrote:
> >> What impact will this have on distributing core server functions if I
> >> change something in the server based plans?
> >
> > Ooh, good question.  I had not thought of that.  Hopefully David has
> > an answer.  :)
> >
> > Otherwise, I'm fine with whacking the offline deployer.  IMHO it was
> > way too complicated for the value it offered.
>
> I talked with jeff on IRC for a bit and he convinced me we need an
> offline deployer.  Our current idea (or at least mine :-) is to:
>
> - make the online deployer online only
> - make a separate offline deployer that uses or imitates the packaging
> plugin but uses the geronimo installation rather than the maven repo
> - put most of the configuration options in a properties file, hopefully
> leaving the command line options simple and clear
> - have the tool create car files in the geronimo installations repo
> - have the tool install car files from the geronimo repo to the
> config-store.
>
> The part I'm unhappy about is that this will more or less encourage
> users to build configurations that pretend to be ours (having the same
> configId) but are not.  I would really prefer if we could make people
> use their own configIds when they build a plan.  However, if we
> succeeded in this, our users would have to rebuild pretty much the
> entire server since we don't have version ranges for dependencies.
>
> thanks
> david jencks
>
> >
> > Aaron
> >
> >> David Jencks wrote:
> >>> Currently the offline deployer is a dreadful hack.  It loads a
> >>> completely separate set of builder gbeans than the running server,
> >>> and
> >>> its restricted to 2 plans.  I believe it was originally developed as
> >>> the
> >>> bootstrap mechanism for server assembly.  We now have a maven plugin
> >>> based system that is simpler and does not have the drawbacks of the
> >>> offline deployer.
> >>>
> >>> I would like to remove the offline deployer capabilities from the
> >>> deployer.jar.  I believe this will significantly simplify both the
> >>> code
> >>> and cli for this tool.  I have some hope that we could even include
> >>> all
> >>> the classes needed in the deployer.jar so it could be moved out of
> >>> the
> >>> geronimo server bin/ and still work.
> >>>
> >>> If there is still significant demand for a standalone offline
> >>> deployer
> >>> tool (rather than using the maven packaging plugin) I would like
> >>> this to
> >>> be a separate tool essentially based on the maven packaging plugin,
> >>> although using the "current" geronimo server rather than the local
> >>> maven
> >>> repo.
> >>>
> >>> thanks
> >>> david jencks
> >>
> >
>
>

Re: Can we remove the offline deployer? Please speak up now.

[David Jencks <da...@yahoo.com>]

On Dec 1, 2005, at 12:29 PM, Aaron Mulder wrote:

> On 12/1/05, Jeff Genender <jg...@apache.org> wrote:
>> What impact will this have on distributing core server functions if I
>> change something in the server based plans?
>
> Ooh, good question.  I had not thought of that.  Hopefully David has
> an answer.  :)
>
> Otherwise, I'm fine with whacking the offline deployer.  IMHO it was
> way too complicated for the value it offered.

I talked with jeff on IRC for a bit and he convinced me we need an 
offline deployer.  Our current idea (or at least mine :-) is to:

- make the online deployer online only
- make a separate offline deployer that uses or imitates the packaging 
plugin but uses the geronimo installation rather than the maven repo
- put most of the configuration options in a properties file, hopefully 
leaving the command line options simple and clear
- have the tool create car files in the geronimo installations repo
- have the tool install car files from the geronimo repo to the 
config-store.

The part I'm unhappy about is that this will more or less encourage 
users to build configurations that pretend to be ours (having the same 
configId) but are not.  I would really prefer if we could make people 
use their own configIds when they build a plan.  However, if we 
succeeded in this, our users would have to rebuild pretty much the 
entire server since we don't have version ranges for dependencies.

thanks
david jencks

>
> Aaron
>
>> David Jencks wrote:
>>> Currently the offline deployer is a dreadful hack.  It loads a
>>> completely separate set of builder gbeans than the running server, 
>>> and
>>> its restricted to 2 plans.  I believe it was originally developed as 
>>> the
>>> bootstrap mechanism for server assembly.  We now have a maven plugin
>>> based system that is simpler and does not have the drawbacks of the
>>> offline deployer.
>>>
>>> I would like to remove the offline deployer capabilities from the
>>> deployer.jar.  I believe this will significantly simplify both the 
>>> code
>>> and cli for this tool.  I have some hope that we could even include 
>>> all
>>> the classes needed in the deployer.jar so it could be moved out of 
>>> the
>>> geronimo server bin/ and still work.
>>>
>>> If there is still significant demand for a standalone offline 
>>> deployer
>>> tool (rather than using the maven packaging plugin) I would like 
>>> this to
>>> be a separate tool essentially based on the maven packaging plugin,
>>> although using the "current" geronimo server rather than the local 
>>> maven
>>> repo.
>>>
>>> thanks
>>> david jencks
>>
>