For various reasons, JARs that are updated by overlays provided in patches are made invalid. However these JARs maintain the same name which lots of folks find confusing.
I would suggest something like *.jar.backup as that's what they're left on the disk for...
If they were renamed (particularly to something other than *.jar), there would no longer be a reason to break them. If module.xml was also renamed the same, there wouldn't be anything preventing the new version from just being updated in place (which could quit breaking anything that references the jars from EAP -- many customers' build scripts or classpaths for client apps, IDEs including JBDS, etc).
Just want to point out it is not just humans. Compilers or IDE's looking at these jars will complain too.
btw. if we could be told if this change would be done in 6.2.x timeframe (i.e. fixed in the next CP) we would *not* have to release updates to older JBDS releases. If it won't be fixed in 6.2.x we either need to say either: A) anything beyond EAP 6.2.0 is not supported for development B) Provide full EAP 6.2 zips for downloads C) Do update release to JBDS 7.1 which would need to add a much more complex jar lookup than it currently uses. p.s. for JBDS 8+ we want to fix this properly since even if jars get renamed they moved location so we need to handle that issue anyway.
related tooling jira: https://issues.jboss.org/browse/JBIDE-17025 please note just because we can potentially fix it in our tools it does not fix the overall issue that a patched EAP contains jar that are not jars and humans as well as tools will fail on these.
This is a real issue. I'm trying to see how feasible the workaround for removing corrupt JAR's from a JBDS project is and it's not nice at all. You have to manually remove the invalid JAR's (even then doing so you get an error saying that the build patch references non existing library '/home/mmusaji/JBoss/jboss-eap-6.2.1/modules/system/layers/base/org/picketbox/main/picketbox-4.0.19.SP2-redhat-1.jar') and add the new ones manually in to your build path! This basically makes the feature of being able to add a server runtime library to your project redundant as you end up adding them manually in the end. I'm still looking in other options but wanted to share this.
From my perspective there is one think more to consider. If there are some links to this modules (i.e. JBIDE or a from a customer build) renaming might end in the same situation, the JAR is not longer available. Also if we 'save' the modules before applying the patch and place the new one into the original directory it miget be still a renaming as the version might changed i.e. jgroups-a.b.c.jar => jgroups-a.b.d.jar. A possible solution might to only modify/invalid the module.xml
We won't be able to do this in the EAP 6.3 timeframe, so i guess i should devel Nack this? In general there is no guarantee that we can rename all disabled .jars on all platforms and we cannot fail applying the patch if this happens. So it would be more of a best effort approach.
As mentioned before - this won't make it into 6.3, so I am nacking this for now. Emmanuel is going to look into getting this done for 6.4.
Upstream PR: https://github.com/wildfly/wildfly/pull/6325 6.x PR: https://github.com/jbossas/jboss-eap/pull/1398
This should be acked by Jimmy