[jboss-as7-dev] Automatically generate AS7 module.xml files from maven poms?

[David M. Lloyd]

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