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]
