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. The
maven-bundle-plugin uses the Bnd tool [1] under the covers which has
quite a rich vocabulary of commands for creating a bundle from a number
of sources, computing the Export-Package/Import-Package headers etc.
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...
Cheers,
David
[1]
http://www.aqute.biz/Bnd