You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Dain Sundstrom <ds...@gluecode.com> on 2005/03/31 00:58:17 UTC
Two deployment tools
Aaron,
A while back we had a discussion about one vs. two deployment tools.
IIRC, you wanted two tools because the command line options for the
"package" command did not fit well into JSR88, and I thought having
multiple deploy tools would be confusing. After working with the
deploy code and thinking about the problem, I have come to the
conclusion that you were right and *I was wrong*.
I think we should break out the package command and merge it with the
bootstrap deployer to create a new tool that is only available via
maven and which we use to bootstrap our server during assembly. This
tool would only be capable of deploying service plan files, and could
either create an executable jar or an entry in a local config store.
In addition, I think the tool should let us specify an ant style
manifest, so we can remove all the funky arguments to the deploy
command that creates a manifest. This new tool could considerably
speed up the assembly process.
What do you think?
-dain
--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26
Re: Two deployment tools
Posted by David Blevins <da...@visi.com>.
On Wed, Mar 30, 2005 at 02:58:17PM -0800, Dain Sundstrom wrote:
[...]
> After working with the deploy code and thinking about the problem, I
> have come to the conclusion that you were right and *I was wrong*.
Wait, wait, wait. Just have to pause on this for a second...
Who are you and what have you done with Dain!
-David
PS You better knock this off or your going to set a bad precedent for the rest of us :)
Re: Two deployment tools
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, 31 Mar 2005 12:18:18 -0800, Dain Sundstrom
<ds...@gluecode.com> wrote:
> On Mar 31, 2005, at 6:08 AM, Aaron Mulder wrote:
>
> > P.S. Dain: kind words. :)
>
> No problem. When your wrong, your wrong :)
>
> I find it a lot easier to let people know when I make a complete 180 on
> an issue. Without the notice people start to think I'm schizophrenic.
Actually, we just think that anyway. ;-)
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: Two deployment tools
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Mar 31, 2005, at 6:08 AM, Aaron Mulder wrote:
> P.S. Dain: kind words. :)
No problem. When your wrong, your wrong :)
I find it a lot easier to let people know when I make a complete 180 on
an issue. Without the notice people start to think I'm schizophrenic.
-dain
Re: Two deployment tools
Posted by Jeremy Boynes <jb...@apache.org>.
Aaron Mulder wrote:
> Jeremy,
> Can you replace the tool used in the assembly module(s) with this
> plugin, so I can revise the deploy tool to take out all the server
> construction operations?
>
Sure. There will end up being two plugins: one for end users that will
focus on the packaging side; the other for integrators that want to
produce custom assemblies.
Does this mean we can simplify the deploy tool so that is pure JSR-88?
> Also, once a Geronimo is released "into the wild" can this tool be
> run at the command line without Maven? And if not, can you provide (or
> help someone else provide) a non-Maven wrapper for it?
>
Easy enough to do, but it does need a Maven repo to load dependencies
from... perhaps we can integrate with Maven's repo code?
> Thanks,
> Aaron
>
> P.S. Dain: kind words. :)
>
> On Wed, 30 Mar 2005, Jeremy Boynes wrote:
>
>>It is self bootstrapping. There is a released version in my home
>>directory that can be used to build itself or newer versions of itself.
>>Having that seed there eliminates the need to bootstrap every time.
>>
>>The plugin builds artifacts which are installed inot the maven repo and
>>which can be used to build other configuration artifacts just like jars;
>>there is no need for a "cold" config store.
>>
>>Configuration artifacts can be installed anywhere; typically they would
>>be user applications that would be installed into a running server.
>>
>>When building our distribution we just need to get enough running that
>>we can talk to its ConfigStore; that can be done by the assembly plugin
>>that is generating the final distribution (e.g. by starting a
>>LocalConfigStore in-VM pointing to the target directory).
>>
>>This separation of configuration packaging from assembly not only makes
>>things easier for our users, it also makes the build simpler. At the
>>same time it allows for multiple assemblies that can use different
>>artifacts (e.g. a Jetty assembly vs. a Tomcat assembly).
>>
>>--
>>Jeremy
>>
Re: Two deployment tools
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Jeremy,
Can you replace the tool used in the assembly module(s) with this
plugin, so I can revise the deploy tool to take out all the server
construction operations?
Also, once a Geronimo is released "into the wild" can this tool be
run at the command line without Maven? And if not, can you provide (or
help someone else provide) a non-Maven wrapper for it?
Thanks,
Aaron
P.S. Dain: kind words. :)
On Wed, 30 Mar 2005, Jeremy Boynes wrote:
> It is self bootstrapping. There is a released version in my home
> directory that can be used to build itself or newer versions of itself.
> Having that seed there eliminates the need to bootstrap every time.
>
> The plugin builds artifacts which are installed inot the maven repo and
> which can be used to build other configuration artifacts just like jars;
> there is no need for a "cold" config store.
>
> Configuration artifacts can be installed anywhere; typically they would
> be user applications that would be installed into a running server.
>
> When building our distribution we just need to get enough running that
> we can talk to its ConfigStore; that can be done by the assembly plugin
> that is generating the final distribution (e.g. by starting a
> LocalConfigStore in-VM pointing to the target directory).
>
> This separation of configuration packaging from assembly not only makes
> things easier for our users, it also makes the build simpler. At the
> same time it allows for multiple assemblies that can use different
> artifacts (e.g. a Jetty assembly vs. a Tomcat assembly).
>
> --
> Jeremy
>
Re: Two deployment tools
Posted by Jeremy Boynes <jb...@apache.org>.
Dain Sundstrom wrote:
> Sounds close, but I was proposing that we have a bootstrap version that
> we use to build the first few jars and configurations. Are you planing
> on supporting installation into a raw "cold" config store directory?
> In this case we couldn't possibly have a running server yet (since we
> are still building it :)
>
It is self bootstrapping. There is a released version in my home
directory that can be used to build itself or newer versions of itself.
Having that seed there eliminates the need to bootstrap every time.
The plugin builds artifacts which are installed inot the maven repo and
which can be used to build other configuration artifacts just like jars;
there is no need for a "cold" config store.
Configuration artifacts can be installed anywhere; typically they would
be user applications that would be installed into a running server.
When building our distribution we just need to get enough running that
we can talk to its ConfigStore; that can be done by the assembly plugin
that is generating the final distribution (e.g. by starting a
LocalConfigStore in-VM pointing to the target directory).
This separation of configuration packaging from assembly not only makes
things easier for our users, it also makes the build simpler. At the
same time it allows for multiple assemblies that can use different
artifacts (e.g. a Jetty assembly vs. a Tomcat assembly).
--
Jeremy
Re: Two deployment tools
Posted by Dain Sundstrom <ds...@gluecode.com>.
Sounds close, but I was proposing that we have a bootstrap version that
we use to build the first few jars and configurations. Are you planing
on supporting installation into a raw "cold" config store directory?
In this case we couldn't possibly have a running server yet (since we
are still building it :)
-dain
--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26
On Mar 30, 2005, at 4:14 PM, Jeremy Boynes wrote:
> This sounds like the geronimo-packaging-plugin:
>
> http://svn.apache.org/repos/asf/geronimo/trunk/plugins/geronimo-
> packaging-plugin/
>
> http://mail-archives.apache.org/mod_mbox/geronimo-dev/200503.mbox/
> %3c423E7ADB.40303@apache.org%3e
>
> I'm nearly finished with the next set of changes which includes
> support for packaging any type of module.
>
> --
> Jeremy
>
> Dain Sundstrom wrote:
>> Aaron,
>> A while back we had a discussion about one vs. two deployment tools.
>> IIRC, you wanted two tools because the command line options for the
>> "package" command did not fit well into JSR88, and I thought having
>> multiple deploy tools would be confusing. After working with the
>> deploy code and thinking about the problem, I have come to the
>> conclusion that you were right and *I was wrong*.
>> I think we should break out the package command and merge it with the
>> bootstrap deployer to create a new tool that is only available via
>> maven and which we use to bootstrap our server during assembly. This
>> tool would only be capable of deploying service plan files, and could
>> either create an executable jar or an entry in a local config store.
>> In addition, I think the tool should let us specify an ant style
>> manifest, so we can remove all the funky arguments to the deploy
>> command that creates a manifest. This new tool could considerably
>> speed up the assembly process.
>> What do you think?
>> -dain
>> --
>> Dain Sundstrom
>> Chief Architect
>> Gluecode Software
>> 310.536.8355, ext. 26
Re: Two deployment tools
Posted by Jeremy Boynes <jb...@apache.org>.
This sounds like the geronimo-packaging-plugin:
http://svn.apache.org/repos/asf/geronimo/trunk/plugins/geronimo-packaging-plugin/
http://mail-archives.apache.org/mod_mbox/geronimo-dev/200503.mbox/%3c423E7ADB.40303@apache.org%3e
I'm nearly finished with the next set of changes which includes support
for packaging any type of module.
--
Jeremy
Dain Sundstrom wrote:
> Aaron,
>
> A while back we had a discussion about one vs. two deployment tools.
> IIRC, you wanted two tools because the command line options for the
> "package" command did not fit well into JSR88, and I thought having
> multiple deploy tools would be confusing. After working with the deploy
> code and thinking about the problem, I have come to the conclusion that
> you were right and *I was wrong*.
>
> I think we should break out the package command and merge it with the
> bootstrap deployer to create a new tool that is only available via maven
> and which we use to bootstrap our server during assembly. This tool
> would only be capable of deploying service plan files, and could either
> create an executable jar or an entry in a local config store. In
> addition, I think the tool should let us specify an ant style manifest,
> so we can remove all the funky arguments to the deploy command that
> creates a manifest. This new tool could considerably speed up the
> assembly process.
>
> What do you think?
>
> -dain
>
> --
> Dain Sundstrom
> Chief Architect
> Gluecode Software
> 310.536.8355, ext. 26
>
Re: Two deployment tools
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
do you want comments from any of us?
On Mar 30, 2005, at 5:58 PM, Dain Sundstrom wrote:
> Aaron,
>
> A while back we had a discussion about one vs. two deployment tools.
> IIRC, you wanted two tools because the command line options for the
> "package" command did not fit well into JSR88, and I thought having
> multiple deploy tools would be confusing. After working with the
> deploy code and thinking about the problem, I have come to the
> conclusion that you were right and *I was wrong*.
>
> I think we should break out the package command and merge it with the
> bootstrap deployer to create a new tool that is only available via
> maven and which we use to bootstrap our server during assembly. This
> tool would only be capable of deploying service plan files, and could
> either create an executable jar or an entry in a local config store.
> In addition, I think the tool should let us specify an ant style
> manifest, so we can remove all the funky arguments to the deploy
> command that creates a manifest. This new tool could considerably
> speed up the assembly process.
>
> What do you think?
>
> -dain
>
> --
> Dain Sundstrom
> Chief Architect
> Gluecode Software
> 310.536.8355, ext. 26
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org