I'm a bit concerned about moving to a highly modularized build where
all the dependencies between the modules are defined as latest
SNAPSHOT dependencies.
By doing this we would solve the problem of the fragile monolothic
build, but we would create a different kind of fragility where
republication of a SNAPSHOT for one module can break the currently
published SNAPSHOTs of other modules that have dependencies on it.
This kind of fragility would show up at runtime when a combination
of incompatible latest published SNAPSHOTs is brought together in
a user's environment. The only way to prevent this from happening
is to rebuild and republish all downstream dependent SNAPSHOTs
whenever an upstream SNAPSHOT is changed and republished, which
would effectively be re-introducing tight coupling by the back door.
If the published downstream modules depend on upstream releases,
then this problem does not occur. It would still not be possible
for a user to combine all latest SNAPSHOTs and have the combination
work, but it would be possible to deduce from the dependency chain
which downstream modules were built and tested with a given release
of an upstream module, and reliably produce a working combination.
A slight modification of this scheme would be to make downstream
modules explicitly dependent on timestamped versions of upstream
SNAPSHOTs, instead of being dependent on the latest published
SNAPSHOT. Moving to a different version of an upstream dependency
would require explicit action from a downstream dependency by
modifying its pom.xml file. This requires greater version dependency
awareness on the part of Tuscany developers, with the benefit that
by making version dependencies explicit rather than implicit, it
would be possible to create a tool that allows a user to bring
together a compatible set of timestamped SNAPSHOTs. This approach
solves the problem of "latest SNAPSHOT hell" without the overhead
of creating a lot of releases for relatively minor changes.
Simon
Jeremy Boynes wrote:
On Jan 6, 2007, at 11:41 AM, Jean-Sebastien Delfino wrote:
I'm trying to understand the new modularized build scheme, and have a
few questions:
I'm not quite sure what you mean by published dependencies? releases?
snapshots?
Anything that a module depends on that is not built by the current
build run. It could be from Tuscany, it could be from another project;
it could be released (preferable) or it could be a snapshot.
Basically, if it's not built by the current run then it needs to have
been published somewhere for the build to work.
What are the criteria for deciding to re-publish a Tuscany jar?
For a release, we need to release it :-)
For a snapshot, any committer can publish one at any time and should if
there is function in there that other modules depend on. For example,
adding a new annotation to spec would be a good reason to republish the
spec snapshot.
Is the online repository going to keep multiple levels of published
dependencies?
It does. Releases generally live forever, snapshots get removed
periodically when they are deemed obsolete. Published snapshots have a
timestamp in the version so it is possible to refer to an older one if
something in the latest causes problems; referring to an obsolete
snapshot is generally problematic as at some point it will go away.
HTH
--
Jeremy
---------------------------------------------------------------------
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]
