Jeremy Boynes wrote:
On Jan 9, 2007, at 1:27 AM, Jim Marino wrote:
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 on the general description (snipped for brevity).
+1 on Jim's general description as well. I see the key points as:
1) Downstream modules (including the current HEAD versions) will
normally depend on released versions of upstream modules, not
on SNAPSHOTs.
2) Upstream modules will release often, so that downstream modules
don't normally need to create a SNAPSHOT dependency to get important
new function.
3) Where a downstream module does introduce a SNAPSHOT dependency,
it becomes responsible for tracking that dependency and adjusting
as necessary to keep up with updated SNAPSHOT versions of the
upstream module.
4) We will use classloader isolation and multiple version support
to manage the issue of incompatible dependencies, where possible.
This won't deal with all cases, such as kernel SPI changes,
where only one copy (I presume) can be loaded.
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.
I would put less emphasis on "working" than on "released." We only use
released pieces to build released assemblies, following the normal
convention of not using SNAPSHOTs in any release.
I think "working" is the right goal to have. See points 1 and 3 in my
comments above. It's a significant overhead for a downstream module to
have a SNAPSHOT dependency on an upstream module, because of the need
to track and adjust to updated SNAPSHOTs. I would not expect developers
of downstream modules to want to have this burden unless it is necessary,
and if they do take it on then I would expect the upstream module to
create a new release soon to get back into stable dependency mode.
Simon
- 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.
I don't think you can from the build. You can install that version in
your repo as your SNAPSHOT and reference that - see the
install:install-file goal.
- 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.
I don't want to. I don't know a way in Maven to do that. It is not
common practice.
--
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]
