Re: [jboss-as7-dev] NoClassDefFoundError

On 12/7/11 3:35 PM, Bill Burke wrote: Yes there are drawbacks but it's worth it (IMO). As we saw in the past, including everything leads to "surprises" and slower classloading. An opt out model has the sames problems because you are still vulnerable to pulling in stuff you never intended. An app server update can readily conflict with your deployments and/or modules. So you spend little time up front, and potentially a lot of time later on down the road trying to fix conflicts. An opt-in model though you spend a little more time up front AND it makes you actually THINK about your dependencies, but your chances of conflicts down the road become very slim. There is of course some balance to be had, so in the case of EE deployments we try to add a set of sensible imports (which can still be opted out of). The goal is that a user only sucks in our supported APIs and not whatever random thing we used to implement them. If however you work with pure modules, as in this http client case, then you don't get this particular feature (as doing it reuires understanding what the module actually does, something known to us when its an EE deployment). Of course they could have just added the http client jar to their deployment, or they could have made it a global module, or used class-path to an extrenal ref, or used extension-list. All of which would get an SE sdk import. What would make initial generation of modules easier, for those that choose to use them, is if we had more tooling (contributions welcome anyone who is listening). For example something that takes a maven dep list and constructs a potential module definition. One last thing to add is that Java SE itself is moving to an opt-in model (Java modules). So really the days of the big-ball-of-mud approach are numbered, or as Mark Reinhold put it "the classpath is dead". -- Jason T. Greene JBoss AS Lead / EAP Platform Architect JBoss, a division of Red Hat