Jason Dillon wrote: >>I weighed up the pros and cons of how Jetty should be distributed and >>decided to leave it in a sar for the time being because it makes it much >>easier to redistribute and install updated versions of Jetty and Jetty >>is an independant project with a seperate release cycle, so this is a >>necessity. > > > 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 ? 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 ? > > >>The only remaining argument I could see for losing the sar was that >>someone might want to run more than one jetty instance. In which case >>packaging impl with cfg didn't make much sense - but I figured that >>anyone doing this was advanced enough to figure it out. >> >>In Jetty's case the 'ease of redistribution' angle won the day. Which is >>why it is still packaged as a SAR. > > > I don't see what you mean here... what ease of distribution? As far as I can > see user downloads jboss and then user has jetty because it is part of the > dist. 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 ? We might as well just pack the whole of Jboss into one big jar. > > All that keeping the config inside of the .sar does it make it hard to > configure. Even if the user is smart enough to figure it out... it is a pain, > when it does not need to be. > > Ideally for each locgical component we have there is one code archive and a > config xml. This seems very managable from the redist angle as well as for > easy config changes. > > So if we can .sar up the support jars and deploy that .sar and a .xml then > that would be best... but will this work for 3.0? David mentioned that it > might, but I have not tried. > > For the record I was not suggesting that we remove the ability for folks to > have config inside of a .sar, more so that we don't ship our components like > that. > > --jason > 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 ? Why bother to be able to run everything unpacked if we are not going to do it in cases where it would be useful ? 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. Jules > ------------------------------------------------- > This mail sent through IMP: http://horde.org/imp/ > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
