I agree in that it is a good idea of treating wars as self-contained archives and if deployed on its own, this is even required, in fact. However, there is a little bit different situation when deploying war within an ear (which is pretty common). In such a case I consider the idea of "skeleton" wars (as proposed in some JIRA issue - see my first post) to be a good one - you know that your war will be bundled in ear so you don't want to explode dependencies in war but in the ear instead. These are completely two different scenarios and they should be clearly distinguished (in dependency definition by some conf property, for instance).
But back to the current status: I agree that currently any work towards solving this issue is probably not worth it. I have just one more question: might such duplicates in ear modules cause some classloader issues (or anything) or is it completely safe to have them? A simple but not handy workaround is to mark affected dependecies (those you know they are duplicated) with "provided" scope in the WAR module. However, as said, this is not handy as you have to explicitely define (=know) which dependencies they are. -- View this message in context: http://www.nabble.com/M2---Best-practice-for-common-jars-between-EJB%2CWAR-modules-in-EAR-t1325601.html#a3551104 Sent from the Maven - Users forum at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
