> > >What I don't like, really, is the SAR format. Having the files in there is a >pain in the ass, there is no way to get at the configuration simply. End of >story. It is the same nightmare with the JAR in EJB, dumb packaging. Sure >packaging is nice in some cases (I drop everything) but really having to >open the SAR is just too big pain, a bigger pain than the nice stuff, in my >mind the tradeoff is clear. SAR no, *service.xml yes. > >Don't go apeshit on me now, we will still support the SAR, and even provide >one of them in the default config, but we should NOT make it pervasive in >our distributions. > SAR is still useful for local directory support and native libs.
>The classes should go under a "classes" directory (today /lib/ext/) which is >centralized and will make central downloading of files simple. > lib/ext/ is no more, there is only lib/ Any reason why you don't want to use lib/ ? It is a very standard naming convention for archive files... a classes/ tends to indicate a directory full of package structure and .class files... >Then the question was "multiple service.xml vs one service.xml". I am >actually thinking that David was right on that one. It is nice to remove >just the service.xml file from a given config. The only problem is that >once the file is removed you need a copy of it to make it work again (as >opposed to comments in the configuration, > Can still comment the config from the file. >The final idea floating around is that of multiple configurations. I am >thinking that there are many deploy directories in the MainDeployer now (it >is capable of scanning many directories not just the /deploy one) and we >should take advantage of this. Maybe we could have >/conf/default/<bare>-service.xml >/conf/medium/<more>-service.xml >/conf/nineyards/<everything>-service.xml > Why not leave them as seperate files and simply change the configuration directory? For example, /server/default/... /server/most/... /server/everything/... Then under here are deployable snippets for groups of components rather than a single file. We can have the build system generate a default config, as it does now, then use that config as the basis for specific configs and then have modules install there non-default config somewhere other than default. --jason _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
