Hi Rick, Yes, that is what I have now done. I have mentioned only artifact ids for dependencies that I already find mentioned in the dependencyManagement of sca pom (axis2 kernel, axiom, wsdl4j ...). For the couple of additional Axis2 artifacts that is required by sca-tools alone I have used the sca-pom variable to specify the version.
All this builds fine now (ofcourse I had to fix a couple of things that broke). - Venkat On 11/7/06, cr22rc <[EMAIL PROTECTED]> wrote:
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]
