> 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. > 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. 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 ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
