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

[David M. Lloyd]

On 12/19/2010 02:39 PM, David Bosschaert wrote:
> On 17/12/2010 17:17, David M. Lloyd wrote:
>> 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.
>
> This is actually quite common in OSGi as well. In some cases there is a
> 1-1 mapping between maven pom.xml files (typically when the module was
> written as an OSGi bundle in the first place) and in other cases there
> isn't such a mapping, e.g. when a bundle is created from a number of jar
> files together or portions of those jar files. When there isn't a 1-1
> mapping the way this is typically handled is by creating a maven module
> specifically to create the bundle from its various sources.

I actually experimented with this.  It takes around 6 seconds to 
repackage a module this way on my system.  If we have the AS build 
produce these (100+) modules, at 6 seconds apiece, that's adding 10 
minutes to the build time.

If we produce these modules externally, then some poor sap still has to 
go through and create these 100+ wrapper modules, and every time we do a 
release on some module it has to then be repackaged - just once for now, 
but when we have multiple live AS releases out there it may be multiple 
times.

Therefore I don't think this approach really scales.  I think that the 
most efficient option in terms of human and computer resources is to 
keep only the raw bits in maven, and have the AS build drive the 
construction of its own environment, at least for now.

Later on I envision an environment-oriented system where you have a 
single project for an environment which is versioned as a whole whenever 
any of its components are updated.  This project would be 
dual-functional as both a run-time BOM for projects running in the 
environment as well as a tool to actually construct the environment itself.

In the somewhat distant future beyond that, I think that the idea of 
using a module-oriented packaging system (sort of a "yum" for Java 
modules) is the last missing piece, which will allow partial 
installation and automatic update of a user-side environment.  It could 
use the modules dependency information (as opposed to maven info) to 
correctly locate dependent modules, which it would download from a 
distribution (non-maven) repository which is optimized for the 
dissemination of these runtime environments.

In this way, we could produce multiple runtime environment module 
repositories - a "Fedora"-like one for the community AS, which would 
allow people to update their local AS images (or even generalized Java 
images, at some point) at will using special Java-based management 
tools; and a "RHEL"-like one for EAP which is more stable and would only 
contain patches for bugs and security problems and that sort of thing. 
An upgrade from one "stable" version to another would simply mean moving 
to a new repository "branch version" and downloading just the updated 
packages that way.

The key important difference between the module repository and the 
above-mentioned OS distribution mechanisms is that we would want to at 
least consider a repository-wide versioning.  This way rather than 
dealing with ad-hoc combinations of modules, which can be difficult to 
support, we could have a single local repository version which we can 
correlate to a specific server repository version, so we can easily 
reproduce problems by simply "warping" a local repository to that 
version and running a test case in that environment.

> This way you can create as many packagings of a number of jars files as
> you want - my main point is that as much as possible of the information
> is computed (based on configuration, of course) and ideally you want
> this to happen in the same buildsystem that defines the components in
> the first place, to make sure that the developer is reminded to update
> this information as (s)he when doing any work in the area...

I agree that there is some correlation between these bits of 
information.  But I think in most cases, the person distributing the 
package into our environment(s) is not going to be the same person who 
wrote the package in the first place.  And I don't think Maven is up to 
the task of "knowing" the difference between the runtime module 
environment and the build-time environment.

Much like how Linux distributors must re-package their packages and 
re-discover dependency information, I think we will continue to have to 
do some amount of manual correlation, as we are today.  Our advantage is 
that while we do not author some of the modules we distribute, they are 
mostly in Maven, complete with dependency information that can at least 
be consumed by a human if not automatically by a build system.

-- 
- DML