Ok, so all we need to do is remove the specific version being listed in the
tooling pom.xml since that should be sync with the Axis binding we're shipping.
Jeremy Boynes wrote:
On 11/6/06, Rick <[EMAIL PROTECTED]> wrote:
Hello,
Currently there are identical artifact dependencies listed throughout
the SCA Java maven hierarchy that can be changed to different versions
either intentionally or accidentally. For example axis2-kernel is
specified in two levels of maven pom.xml At the sca level there is
dependencyManagement element that uses the axis2Version property and
there is also a reference in sca/tools/pom.xml that is hard coded to
SNAPSHOT. This brings about the following questions:
Is this a good practice? I this weekend changed one and didn't catch
the other so my opinion is no, I think until the need arises that they
require to be different this should be set in one place.
If we agree what's the best solution? Use maven property values to
keep them in sync, or just list the version at the top level
(sca/pom.xml) under the dependencyManagement?
If we take the latter approach, do we list ALL external dependencies
there to be consistent?
If we feel this should change should we still do this for M2 release?
I have tried to use <dependencyManagement> where practical but Axis
provides a different challenge in that there are many Axis artifacts
that all need to be at the same version level. For that, I used a
property to define the common version and then attempted to reference
that everywhere rather than restate; this would apply to <dependency>
elements in both <dependencyManagement> and <dependencies> sections.
I do not think we should list ALL external dependencies in a single
<dependencyManagement> section as that couples all modules to that
parent pom through the version information it contains. If modules are
independent, then they should each list their dependencies to avoid
that coupling; if they are not independent then we should organize the
tree (and the release packaging) to reflect that coupling.
Venkat's approach to that sounds reasonable.
--
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]
