On 27/07/12 11:21, Geoffrey De Smet wrote: Well, yes but that's the hard bit isn't it? -- what to do if they do communicate with each other? Thomas is right that it is hard to manage this by hand when you have an ecosystem the size of EE. But the tools which are supposed to automate this clearly don't work very well either. Personally, I think automation is a pipe dream but your mileage may vary. Anyway that's not really why I am responding here. There is a more important point to make here which this strand of the discussion has really brought to the surface. The real problem we are facing here is how we reconcile the different needs of JDK (and relatively small-scale) app modularization vs EE middleware and EE app modularization. Jigsaw is providing a conventional module mechanism as used by many other languages for structuring both the base runtime and components of an application. That's not only a useful thing to do it is actually vital for the health of the JDK runtime. Suggesting that this does not address the needs of EE libraries is not a valid gambit. If Jigsaw answers real requirements for structuring Java app code without dealing with the problems EE poses then it has done its job. Providing a mechanism that will support the scale and complexity of interdependence that EE and the many application libaries, components and frameworks which sit on top of EE is not a problem Jigsaw /has/ to solve. Clearly, as it currently stands it won't solve those problems because baking modules into the code means resolving conflicts requires rereleasing code and that's just not feasible on the scale of EE middleware/apps -- something will always be broken no matter how fast teh release cycles. Now there's not necessarily any problem if we just leave it at that. A conventional module system like Jigsaw provides certain capabilities for structuring and managing code components, an EE module system like OSGi or JBoss Modules provides alternative capabilities. In theory we can have and use both mechanisms. However the dangers we face if we have two ways of doing these two things are obvious: i) the two mechanisms will be conflated and the wrong mechanism selected for managing specific versioning/update requirements; and/or, worse, ii) the two different (types of) mechanism(s) will not be defined with understanding of each other's competing needs and hence use of one will invalidate or severely compromise use of the other. This is why it is critical that we get some purchase on the Jigsaw project. Not to 'correct' it and certainly not to 'derail' it. Just to make sure that we can arrive somewhere which avoids these two potential dangers. So, much as I feel this discussion is now making good forward progress the really important thing is to ensure that it feeds into the Jigsaw project. regards, Andrew Dinn -----------