> > 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/ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
