Sacha, >> Regarding #2, I find the current state of /deploy to be >> highly intuitive, personally. Would it be possible to make >> your scheme work by giving .sar's the ability to be nested? >> That way, /deploy/JMS.sar (a directory) could contain >> jms-foo.sar and jms-bar.sar.
>That's already possible (russian dolls), but then: > - you need a fake META-INF/jboss-service.xml > - you cannot simply re-deploy one of the element in the directory: you have to re- >deploy the whole JMS thing Cool. So /deploy/A.sar/B.sar implies that A *depends* on B and therefore should be redeployed if B.sar is modified. Perhaps it would be possible to add a line to jboss-service.xml like "<isComposite/>" that indicates that nested sar's are not dependencies. As far as the "fake" (A.K.A. empty) descriptor goes, I can't imagine this is a big deal. If it is, then perhaps the sar deployer can/should be modified to take the lack of a "jboss-service.xml" to indicate an empty configuration (perhaps with a default setting of "isComposite"). Or, maybe I just like recursion too much ;) - Matt ------------------------------------------------------- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ------------------------------------------------------- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
