[ https://issues.jboss.org/browse/JBIDE-26305?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-26305: ------------------------------------- So, let's start by looking here to see when the feature was added: https://github.com/jbosstools/jbosstools-server/blame/58d87019c99ca1b5f9a... This appears to be 3 years ago for the initial feature. So it's not new. It's old. Second, the idea of a config file. In many ways, the server editor itself *is* that config file. So is the "deployment-assembly" preference page. There's no real backing file for the server editor except a hashmap of k/v pairs stored in memory representing the server. There's a config file representing the deployment-assembly in the project named org.eclipse.wst.common.component, but this file doesn't include anything like zipped or unzipped. Third: is there a way to actually customize the zipping behavior of a nested module? Yes, there is, but it's not super intuitive. In the server editor's deployment tab, you can do it. There's the server-level setting as to whether to zip or not zip, but this affects all modules in the server. Below that, you'll see a table listing modules / projects to be deployed. In the case of an ear with a nested jar, you may only see the ear listed here. So you need to use the combo box next to "Filter by: " to "All". This will make the table show all possible modules that can be deployed. When you do this, you can override the settings on a per-module (and even nested module) basis. You can set the ear to unzipped, and the lib jar to zipped. Is this a bug? I don't believe so. There's a way to change settings to properly configure your workspace and server adapter to customize the behavior. The default, I also believe, isn't wrong, because we configure everything for faster incremental deployments. In general, we've been told wildfly and eap have support for exploded nested deployments. If the current configuration breaks their app, the user has two options. First, he should file a bug with wildfly / eap and ask why his scenario doesn't work with exploded deployment and whether it can be fixed. Second, he can customize the deployment behavior as discussed above. I'm open to suggestions here, but for now this is my point of view. -- This message was sent by Atlassian JIRA (v7.5.0#75005)