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

[Thomas Diesler]

I agree, its unreasonable to derive the runtime environment 
configuration from build time POMs. We do however have the "human 
wiring" dilemma, which may result in missing runtime dependencies for a 
module (this is what DavidB is seeing) but may also result in 
inconsistent wiring. In Antwerp we talked about the option of 
post-build-validation based on module capabilities/requirements. This 
could detect

* missing runtime dependencies
* split package definitions
* inconsistent class space configuration (when there are multiple slots 
per module)
* other missing requirements (i.e. on a specific platform)

For this to work it'd be necessary for a module to define its 
capabilities/requirements. At runtime, there should be a "gate keeper" 
to the modules dependency API - the Resolver. Deployments would also 
define their respective set of capabilities/requirements. The resolver 
could reject a deployment if the runtime does not provide the required 
set of capabilities. This could happen with very detailed error 
response. Currently we have various DUPs that use the modules dependency 
API. IMHO these DUPs cannot be expected to produce consistent wiring 
graphs for the non-trivial setups that we expect in future. Instead a 
single authority should be tasked to validate that a set of modules can 
be installed in an existing setup. This must happen without modifying 
the existing setup.

-thomas

On 12/19/2010 10:51 PM, David M. Lloyd wrote:
> 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.
>

-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx