Re: [JBoss-dev] SAR... Sucky ARchive ?

[Jason D. <ja...@pl...>]

> > But we don't do this... Jetty is part of the release, it is not a seperate
> 
> > component which users download and configure.
> 
> until the next release/important-bug-fix of Jetty. 
> I thought your whole point was that they DO configure it ?

My point was much larger than Jetty, with respect to the concept of a service 
archice and service instance configuration... which I detailed more in my 
response to Marc.

> If Jetty 4.1 comes out with some new feature that someone wants, why 
> shouldn't they just upgrade their Jetty plugin. Surely the point of a 
> plugin is that it decoupled from the core distribution. Otherwise  - why 
> bother ?

Yes, yes... I agree completly it is a plugin.  In this sence though it would 
be better if users did not have to crack open the archive.  Think if we wanted 
to start signing these & performing cert verificatrion to ensure users have 
valid plugins.  We can't have them changing the contents then.

Do you think that 2 files (.sar & .xml) is really that much more trouble to 
manage?

What are the advantages to having only .sar w/ embedded config .xml?

What are the disadvantages?

I believe that the disadvantages out weigh the advantages by a landslide when 
looking at the JBoss distribution.

Take a use case where a user downloads JBoss, needs to enable ssl, then a new 
jetty plugin is released.  You can even add flavors to the use case where one 
is the jetty config is compatible with the previous release and one where it 
is not comaptible.

Now, do you really think that 2 files (.sar & .xml) is really that much more 
trouble to manage?  Or do you now see that a single file in this case is more 
trouble?

Btw, Jetty isn't the only example of this... so I am not trying to pick on 
you.  It is a good example of user wants to change config from the current 
dist which is archived using all in one .sar.

> Jetty is still a seperate project in it's own right, as it has always 
> been (jetty.mortbay.org). It will continue to have it's own release 
> cycle and many users (particularly in the embedded and small device 
> market) who do not use JBoss.
>
> If I want to distribute important changes to Jetty to JBoss/Jetty users 
> are you saying that I should not just put out a new jetty-plugin.sar ?
> 
> I thought we were moving towards automagic upgrades from the web anyway. 
> In which case you might get a new jetty plugin anytime you restart JBoss 
> and there has been a fresh Jetty release.
> 
> What is the point in loosely coupling all these components if we are 
> then going to insist on releasing them all ONLY in one monolithic distro 

Yes, I appologize, I was getting heated at the point I was writing this.  
Agreed, but see my point above.
 
> ? We might as well just pack the whole of Jboss into one big jar.

This is basically a gross example of what .sar could turn into... what a mess 
it would be to configure that beast.

> What about simply distributing the sar with instructions to simply move 
> it into deploy/ if you use a default config, or unpack it there and edit 
> the jboss-service.xml if you need to make changes ?

Do you think that is simpiler than haveing a .sar & .xml by default?  Again 
look at the use case.  Are we expecting that the jetty config that comes with 
jboss is the one that most of our users will use un changed?  If so why are 
there comments to uncomment sections to enable ssl and such?

I think that it is very likly that most users will want to change this 
config... so rather than special case them, special case those few which want 
a single sar with config inside.
 
> Why bother to be able to run everything unpacked if we are not going to 
> do it in cases where it would be useful ?

I am not really sure what you mean here, but I am going to guess that you mean 
that the jetty .sar with nested config is useful... am I correct?

I am not saying that it isn't useful to everyone.  I am saying that it isn't 
useful to most of our users, rather it is a hinderence.

> What do I gain over running the sar unpacked by splitting the contents 
> into different directories ? This approach simply makes it more 
> difficult for me to ship users a replacement Jetty installation.

I agreed, which is why I think we should have a jetty-plugin.sar & jetty-
service.xml.  User gets new jetty-plugin.sar with new Jetty and drops it in... 
and that is that... 

No unjar/edit/rejar... 

No removed the eploded archive and reexplode the new one, then go find the 
config and change it to what it was before...

Simply download new version, copy to deploy and we are done.

Isn't this better?

--jason

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/