Re: [jboss-as7-dev] Automatically generate AS7 module.xml files from maven poms?
On 12/17/2010 05:47 AM, David Bosschaert wrote:
Hi all,
Today I was looking at a module.xml somewhere down
http://github.com/jbossas/jboss-as/blob/master/build/src/main/resources/m...
and found out that a problem I was facing was caused by a dependency in
there being out of sync with the dependencies of the pom that defines
the original module.
So I was thinking, since there is a 1-1 mapping between the poms and
modules would it make sense to automatically generate the module.xml
files from the poms rather then having them in git.
You are incorrect; there is not a 1:1 mapping between POMs and modules.
There is a 1:1 mapping between artifacts and resource roots however.
Furthermore the problem is much more complex that it appears on the
surface. Maven build dependencies deal with fixed versions; module
dependencies use common versions within a runtime environment
(approximating a BOM) which do not match up with the build versions.
And of course, we do not control the POMs for many of our dependencies.
I do agree this is something that should (and will) be addressed but
unfortunately it's not as easy as tacking some stuff on to the POM. I
only want this to be done in a high-quality, correct way, and I am
definitely NOT interested in tying this to maven in this way. Maven
cannot survive the upcoming Java 8 modularity "epoch" in its current
form so it shouldn't be the basis of our modularity build strategy. On
the other hand we can and should *consume* Maven to acquire artifacts,
for the time being anyway.
You have to understand that the core of this problem is that there is no
relationship (nor should there be) between how we identify and
distribute modules within a specific environment (e.g. AS, but in the
future perhaps OS-level environments as well) and how Maven organizes
the actual bits (by name *and* by content). Look at Maven as just a
repository for JAR files and a set of instructions for how to build each
JAR repeatably and you're most of the way there. They just do not and
cannot map to the runtime dependency environment which can change
depending on who is using the JAR, and why, and how it is identified in
that particular environment (and why). This *must* be accommodated by
another layer.
Now the work that Kabir is doing doesn't cause this problem: his plugin
is purely for *building* modular environments, specifically test
environments, given the JAR resources plus extra environment
information. So in a sense, he's using Maven as a frontend to a
simplified version of this runtime environment layer.
--
- DML