Hi,
To better evaulate if the code base is ready to be a release, there are two
useful techiques discribed in the "Better Builds with Maven" book
(http://www.mergere.com/m2book_download.jsp):
6.9. Monitoring and Improving the Health of Your Dependencies
Run "mvn site" to create dependency and dependency convergence reports.
The report shows all of the dependencies included in all of the modules
within the project. It also includes some statistics and reports on two
important factors:
* Whether the versions of dependencies used for each module is in
alignment. This helps ensure your build is consistent and reduces the
probability of introducing an accidental incompatibility.
* Whether there are outstanding SNAPSHOT dependencies in the build,
which indicates dependencies that are in development, and must be updated
before the project can be released.
6.10. Monitoring and Improving the Health of Your Releases
An important tool in determining whether a project is ready to be
released is Clirr (http://clirr.sf.net/). Clirr detects whether the current
version of a library has introduced any binary incompatibilities with the
previous release.
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, January 09, 2007 1:27 AM
Subject: Re: tuscany-sca revision 493223 does not build? (mvn claims missing
jar dependency)
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
