I know very little about Maven except to follow how it expects
projects to be structured and behave or it will inflict untold
amounts of pain (which is probably fair given its goal of trying to
standardize project build structures) :-) Here is how I picture
things will work:
1. We decided that modules are either independent or grouped by
function. For example, the Axis2 binding extension and the WSDL to
Java tool if it is specific to Axis. Modules are grouped
independently from their dependencies. For example, the JPA extension
is independent from the Geronimo transaction manager since the two
are not inherently tied together (the former only requires a JTA
implementation).
2. We also decided that modules will be organized in the source tree
by how they are released. For example, the Axis2 binding extension
will be grouped with the WSDL to Java tool. This will have the side
effect of solving the problem of specifying versions of common
dependencies.
3. The above assumes modules will be developed independently or by
how they are grouped. Consequently, most of the time, they will never
reference a SNAPSHOT version of a dependency. Instead, modules will
reference a released version. This hold whether the dependency is on
another Tuscany Java SCA module or third-party software. For example,
the kernel, SDO, Spring, or ActiveMQ. Another way of viewing this is
that dependencies on other Tuscany modules are treated as if they
were third-party software. Sometimes a module may choose to work off
a SNAPSHOT version. If that is the case, the developers of the module
are responsible for keeping up with changes as the SNAPSHOT version
is updated. Consequently, relying on a SNAPSHOT version may result in
instability. It will more often be the case that modules will upgrade
to a new released version of a dependency. From a process standpoint,
there should be no difference between upgrading Axis2 and Tuscany
kernel versions.
4. Samples will be grouped with their respective modules. For
example, the JavaScript samples would be grouped with the JavaScript
extension module. Samples which span multiple technologies will be
grouped separately and will behave the same as modules, i.e. they
will most often reference released versions of dependencies. Grouping
samples with their extensions will allow them to be released without
having to release all of the other (unrelated) samples. It will also
provide a more modular distribution as end-users will receive only
the samples they are interested in.
5. Modules will be released either independently or by grouping. They
will not be released with their dependencies. For example, the Axis2
extension and the WSDL to Java tool will be released independently
from kernel. This is the same process we have been following on a
more macro level between the SCA, SDO and DAS subprojects. This is
more of a release "caravan" as opposed to "train". Modules can choose
to provide follow on releases after a new dependency version is
published (e.g. kernel, SDO, etc.) or they may choose to wait
depending on the module lifecycle.
6. Samples may be released with their extensions or independently; it
is up to the module.
In practice, I would expect upstream modules such as kernel to
release early and often. When a downstream module is ready, it will
cutover to using the new released version of the upstream modules. If
downstream modules all rely on SNAPSHOT versions, we will wind up
with the same monolithic and unstable build we currently have since
SNAPSHOTs represent the state of HEAD. Sometimes a module will
require a new feature in a dependency. In this case, Tuscany
dependencies will work the same as third-party ones: either a new
release is cut or SNAPSHOT is used.
What happens when B and C reference incompatible versions of A and
someone wants to use them together? For end-users, in the runtime, we
will load different versions of A using SCA deployment mechanisms and
classloader isolation. Similarly, in development, their dependencies
need to be isolated by referencing different versions of A and making
sure the proper classloader isolation is in effect, otherwise they
cannot use them together.
Given this, specific comments inline...
Jim
I'm perfectly cool. Thanks for your thoughts, I'm just trying to
understand what you're saying and how this modular build scheme is
going to work, and I'm still looking for answers to some of my
questions :)
- Are we going to update snapshot Jars over time? or use a
<uniqueVersion>true</uniqueVersion> repository config to publish
unique timestamped versions (which, if I understand correctly will
not update over time)? or do we only want to use releases of pieces
of Tuscany to build working assemblies?
By their nature SNAPSHOTS evolve over time. However, "working"
assemblies should generally never reference SNAPSHOT versions as they
change causing instability. Rather, working assemblies should
reference released versions of dependencies.
- If we're going to use timestamped snapshots, does anybody know
how to reference a specific timestamp (I couldn't figure this out
from the Maven docs).
I don't think we need to reference specific timestamps. Either a
module references a released version or SNAPSHOT. If it references
the latter, it is responsible for tracking changes. If the module
developers require ongoing stability, they should not reference
SNAPSHOT.
- How do people in the group want to associate a specific SVN
revision with a published snapshot? Jeremy, do you know the
recommended Maven way to do that?
We should never need to do this.
Thanks,
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
