[jboss-as7-dev] Fwd: Late for the train

[Andrew Dinn]

On 27/07/12 11:21, Geoffrey De Smet wrote:
> It's up to the "conflict resolution" and "classpath/modulepath" specs to
> decide how to deal with the obvious version conflict in your example.
> In a modulepath world (= a graph of dependencies, just like Maven and
> OSGi), it could run both X-1.0.0 and X-1.1.0 simultaneously (if pluginA
> and pluginB don't communicate to each other with X).

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
-----------