Re: [jboss-as7-dev] referencing jars within JBoss Modules
On 08/05/2011 02:16 AM, Max Rydahl Andersen wrote:
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 ?
Hard to tell what this has to do with the original subject, but that's
OK. :)
I think it's very important to always use the same code in the modules
repository as can be found in a public maven repository. This doesn't
necessarily mean the same JARs though. As long as we use the same code
and resources as the original (i.e. fully compilation-compatible) then
we can bundle different (say, signed) JARs without the user having to
really know the difference.
If we patch a project then the proper thing to do is publish the patched
artifact version in our public repository in as similar a way to the
original as possible, *and* make sure that patch (or an equivalent fix)
is pushed upstream; in other words, we should avoid locally patched
versions where possible (this is similar in policy to how Fedora deals
with patches).
All that said... every single JAR does in fact come from Maven so you
can already simply examine the Maven metadata present in each JAR to
know where it "comes from".
Hope I've answered your question.
--
- DML