Vote: Remove old deployer, rename new deployer

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

	I'd like to remove the current "deployer.jar" tool, remove the
command-line processing logic from the Deployer class, rename
"new-deployer.jar" to "deployer.jar" and change the bootstrapper to build
the new one instead of the old one.  Currently there are two so we'd have
some sort of transition (fallback in case of problems), but since the
build script is pretty much only using the new one now, there are some
NPE's in the old one, and no one seems to have had any problems with the
new one, I'd like to go ahead and eliminate the old one.

	Please indicate whether you agree.

Thanks,
	Aaron

Re: Vote: Remove old deployer, rename new deployer

[Davanum Srinivas <da...@gmail.com>]

+1 from me.


On Sat, 6 Nov 2004 12:35:01 -0500 (EST), Aaron Mulder
<am...@alumni.princeton.edu> wrote:
>         I'd like to remove the current "deployer.jar" tool, remove the
> command-line processing logic from the Deployer class, rename
> "new-deployer.jar" to "deployer.jar" and change the bootstrapper to build
> the new one instead of the old one.  Currently there are two so we'd have
> some sort of transition (fallback in case of problems), but since the
> build script is pretty much only using the new one now, there are some
> NPE's in the old one, and no one seems to have had any problems with the
> new one, I'd like to go ahead and eliminate the old one.
> 
>         Please indicate whether you agree.
> 
> Thanks,
>         Aaron
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Re: Vote: Remove old deployer, rename new deployer

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

On Sun, 7 Nov 2004, Dain Sundstrom wrote:
> God I hope not.  I spend a long long long time making sure our code 
> would work with unpacked archives.  People don't want to jar up a 
> deployment during development.  Having the tool jar it up, is a bit 
> better than no support at all, but the extra coping is unbearable when 
> dealing with a large web app (100 MB).  I actually hope we soon will 
> have support unpacked in place deployment, which involves no coping to 
> the config store.

	Hmm...  Well, maybe I should rethink this.  I need to look at the 
API again.  If it just takes a File, there's no reason that couldn't be a 
directory...  Maybe I just need to adjust my assumptions.

Aaron

Re: Vote: Remove old deployer, rename new deployer

[Dain Sundstrom <da...@iq80.com>]

On Nov 7, 2004, at 7:01 AM, Aaron Mulder wrote:

> On Mon, 8 Nov 2004, Gianny Damour wrote:
>> +1
>>
>> As an aside, the new deployer can not distribute unpacked modules. Is 
>> it
>> intentional?
>
> 	JSR-88 doesn't support unpacked modules.  If you like, we could
> assume any directory is an unpacked module, JAR it, distribute the JAR,
> then delete the JAR.  To be slightly fancier would could check for one 
> of
> the standard DDs in the correct location before making that 
> assumption...

God I hope not.  I spend a long long long time making sure our code 
would work with unpacked archives.  People don't want to jar up a 
deployment during development.  Having the tool jar it up, is a bit 
better than no support at all, but the extra coping is unbearable when 
dealing with a large web app (100 MB).  I actually hope we soon will 
have support unpacked in place deployment, which involves no coping to 
the config store.

-dain



--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26

Re: Vote: Remove old deployer, rename new deployer

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

On Mon, 8 Nov 2004, Gianny Damour wrote:
> +1
> 
> As an aside, the new deployer can not distribute unpacked modules. Is it 
> intentional?

	JSR-88 doesn't support unpacked modules.  If you like, we could 
assume any directory is an unpacked module, JAR it, distribute the JAR, 
then delete the JAR.  To be slightly fancier would could check for one of 
the standard DDs in the correct location before making that assumption...

Aaron

Re: Vote: Remove old deployer, rename new deployer

[Gianny Damour <gi...@optusnet.com.au>]

+1

As an aside, the new deployer can not distribute unpacked modules. Is it 
intentional?

Thanks,
Gianny

On 7/11/2004 4:35 AM, Aaron Mulder wrote:

>	I'd like to remove the current "deployer.jar" tool, remove the
>command-line processing logic from the Deployer class, rename
>"new-deployer.jar" to "deployer.jar" and change the bootstrapper to build
>the new one instead of the old one.  Currently there are two so we'd have
>some sort of transition (fallback in case of problems), but since the
>build script is pretty much only using the new one now, there are some
>NPE's in the old one, and no one seems to have had any problems with the
>new one, I'd like to go ahead and eliminate the old one.
>
>	Please indicate whether you agree.
>
>Thanks,
>	Aaron
>
>  
>

Re: Vote: Remove old deployer, rename new deployer

[Jeremy Boynes <jb...@gluecode.com>]

Aaron Mulder wrote:
> 	I'd like to remove the current "deployer.jar" tool, remove the
> command-line processing logic from the Deployer class, rename
> "new-deployer.jar" to "deployer.jar" and change the bootstrapper to build
> the new one instead of the old one.  Currently there are two so we'd have
> some sort of transition (fallback in case of problems), but since the
> build script is pretty much only using the new one now, there are some
> NPE's in the old one, and no one seems to have had any problems with the
> new one, I'd like to go ahead and eliminate the old one.
> 
> 	Please indicate whether you agree.
> 

I played with this briefly in online mode and in package mode and 
everything looked good. I still feel it is a little early as others may 
not have had chance yet but here's my +1

I do have a couple of suggestions for minor improvements. AIUI there is 
no option to package without installing in the deployer's config store; 
I think this would be a useful option to add. I would suggest making the 
default not to install and then add a --install option to the package 
command which would do that.

The other is that in the old one if you did not specify --install or 
--outfile then it effectively validated that the config could be built 
but did not do anything with it. This was useful if a little obscure. I 
would suggest added a "validate" command that did just that. I think 
this can work both online and in package mode although doing it online 
may mean working around JSR-88 limitations. We should also be clear that 
validate just means that the config can be built (which will catch 90% 
of common deployment problems) but will not actually try to start the 
config.

Thanks Aaron, I think this is a good improvement over what we had before.

--
Jeremy