Hi,
Is it possible to publish SNAPSHOT jars in format of
"xyz-r123456-SNAPSHOT.jar" instead of "xyz-SNAPSHOT.jar"? Or are you
proposing to use artifact id as "xyz-r123456" instead of "xyz"?
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, January 08, 2007 9:51 AM
Subject: Re: tuscany-sca revision 493223 does not build? (mvn claims missing
jar dependency)
Simon Nash wrote:
Thanks for the pointer. I have downloaded the book and I have read
the sections describing SNAPSHOTs. I look forward to reading the
remainder.
My reference to a "user" was intended to mean anyone needing to put
together a working combination of already built SNAPSHOT modules for
the selection of sca infrastructure components that they need.
Project developers would certainly fall into this category. If they
are developing code inside one module, they can assemble a test
environment for that code from other pre-built modules that are in
a known working state. This should be the main benefit of having
a modular build.
My main point was that using SNAPSHOT dependencies between all the
separately built sca modules (kernel and extensions) leads to tight
coupling when new SNAPSHOTs of upstream modules are published,
because it is necessary to simultaneously publish matching SNAPSHOTs
of downstream modules to keep them in sync. For example, publication
of a new kernel SNAPSHOT with an SPI change would require republication
of SNAPSHOTs for all extensions that depend on the changed SPI. If
these dependent extensions are not republished as SNAPSHOTs, the
set of latest SNAPSHOTs will no longer be self-consistent. Having the
downstream components depend on a known upstream level (however
this is done) avoids this problem.
Does anyone else think this is a problem that should concern us?
Simon
Jeremy Boynes wrote:
You misunderstand the purpose of SNAPSHOTs. They do not affect users as
released code does not reference them. They provide a way for project
developers to cooperate during a release development cycle without
requiring everyone to build everything all the time (which as we have
seen does not scale). They also provide a mechanism that does not
require downstream developers to update references to every build
number/timestamp every time a new unstable build is published (which
does not scale either but for different reasons).
There's a good reference on how Maven works here: http://
www.mergere.com/m2book_download.jsp
--
Jeremy
On Jan 7, 2007, at 11:27 AM, Simon Nash wrote:
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]
Simon,
I think that what you're describing is a problem only if the jar is
published as xyz-SNAPSHOT.jar without identifying the specific level of
code in the jar. If it is published as xyz-r493223-SNAPSHOT.jar for
example (or another form of identification of a specific level) then a new
revision of the SPI will be published in a different jar
(xyz-r493224-SNAPSHOT.jar). Components that want to stay on r493223 will
continue to reference xyz-r493223-SNAPSHOT.jar, components that want to
move on to r493224 will reference xyz-r493224-SNAPSHOT.jar.
So if I understand correctly, this scheme allows the core components to
move on with changes without breaking the others that depend on the core.
These components become responsible for catching up with core changes when
they wish or can do it (and they better do it frequently to avoid
surprises when they move up levels). Whoever wants to build a working
distribution or run an end to end scenario becomes responsible for putting
the pieces together, and coordinating and working with the various
component providers to make sure that they all work on compatible levels
of the core jars.
Does that make sense?
I think it would help a lot if somebody who understands this new scheme
better than me could educate us on the steps that the various people on
the project will have to go through when a change occurs in one of the
core Jars.
--
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]
