我的想法是将jboss AS7嵌入到我的项目中并将其添加到版本控制中。另外要检查使用mvn jboss：devserver启动服务器的能力（类似于我们运行mvn appengine：devserver的方式）那么编写我自己的archtype是否有意义？
对我的客户来说，这减少了许多复杂性，因此我们可以创建自己的jboss配置以及将要开始从事Java项目开发的客户端C＃开发人员。发现更容易设置本地计算机以在本地运行其更改。使用上面提到的类似命令。（mvn jboss：devserver）我想知道是否有人有这个想法来工作？
答案 0 :(得分：2)
我可能会考虑使用类似Puppet的内容，而不是检查所有JBoss。
Puppet使用自定义声明性语言来定义系统配置。您的木偶脚本可能会执行以下操作：
Puppet比我刚才描述的简单场景强大得多，但这个场景是一个开始。
使用此解决方案，您最终只会检查您的puppet脚本以及您可能需要的任何自定义JBoss配置文件。另外，我相信它会让你的JBoss升级路径变得更加简单，因为你只需要在你的木偶剧本中更改JBoss的版本，然后重新运行puppet。
答案 1 :(得分：1)
我认为处理这类情况的理想方法是packaging。如果您的客户端部署在某种unix服务器上（我包括Linux），那么他们已经在使用软件包管理器来管理其服务器上的系统软件。软件包管理器能够安装软件，删除软件，升级软件，并且至关重要的是安装其他软件包所依赖的软件包。
因此，您可以打包JBoss，以便包管理器可以安装它，然后打包您的应用程序，指定对JBoss的依赖。当客户端安装您的应用程序包时，将自动安装JBoss。
但是，此计划仅在客户端设置了一定程度的基础结构时才有效。他们需要使用带有包管理器的系统。他们需要有一种管理包安装的方法（像Puppet，Chef，Ansible这样的配置管理工具，或者供应商专有的配置管理工具是理想的选择）。他们需要能够在其环境中分发自定义包。他们需要一种接受自定义包的方式，或者接受包构建脚本，然后自己构建包。
在任何规模的服务器环境中，系统管理员应该也可能拥有所有这些基础设施，因为它是管理一组服务器的基础。但如果您的客户没有，可能需要付出太多努力才能设置。
也就是说，这种方法的绝对最小版本是你通过电子邮件或SFTP或其他方式向他们发送应用程序和JBoss的包文件，然后让系统管理员手动安装它们（例如{{3 }}）。这并不比让他们手动安装JBoss好多了，但这是朝着正确方向迈出的一步。