3:51 p.m.
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