changing the topic ever so slightly.
The problem is that the modules directory is a concept which applies
to
the AS, and there may be more than one, or there may be none at all if a
different module loading scheme is used.
The ServerEnvironment should have no direct knowledge of the module
system or its filesystem representation. The only interface with the
module system should be through the modules API.
I'm curious if you want that to apply for users wanting to build against the JBoss AS
runtime jars swell.
i.e. those who want the *exact* possibly bug fix patched jars in the runtime and not
"just" what can
be returned from a maven repo.
Currently in jboss tools we refer to specific locations inside the modules repo to refer
to these jars
and were planning/pondering on starting to read the module metadata to get a more precise
representation
of the actual jars used (and then map the notion of an Eclipse Facet (i.e. jpa facet) to
one or more modules (i.e. javax.persistence.api for API and org.hibernate.* for
implementation)
Is this a dead end road to follow ?
/max
http://about.me/maxandersen