We have come up with a pattern that we feel works pretty well to work
around this. We split our modules into standard jars and "j2ee" type
archives. The standard jars declare their own deps as normal. The j2ee
jars all share a parent which overrides all dependency versions so all the
wars/ears are guaranteed to have the same manifest.mf and ear lib/*.jar
contents.
When we release, standard jars are released one at a time. The j2ee jars
are all released at the same time (using one big recursive release). This
way we update the parent with the latest versions of all the standard jars
and then all the j2ee jars will pick it up.
Craig, the other thing to remember is that version ranges are key here
also. Your transitive dependency should not be specifying 1.0.4, it should
say [1.0,) so that versions are not pushed to its dependents (i.e. your
project) like you are seeing. Unfortunately M2 has several bugs wrt
version ranges but this is important to solidify for the 2.1 release IMO.
The other thing needed is to document a development process for building
J2EE artifacts. M2 works pretty well for OSS people writing jars and fat
wars but is a pain to deal with for application (EAR) authors trying to
package more than one j2ee module.
Jörg Schaible <[EMAIL PROTECTED]> wrote on 08/09/2006
01:56:58 AM:
> Hi Craig,
>
> Craig McClanahan wrote on Wednesday, August 09, 2006 8:46 AM:
>
> > On 8/8/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> >>
> >> Why should I have to declare it in the app, when I've declared it at
> >> the parent level? What's the point of transitive dependencies if
> >> they do not work the way you want, and there's no way to force them
> >> to do so?
> >>
> >
> > I should have been more clear. It is not that transitive
> > dependencies are bad ... it's that I believe inherited dependencies
> > (including version dependencies described by <dependencyManagement>
> > sections
> > should *always*
> > override transitive dependencies on the same artifact.
>
> This is also my PoV, struggling with the same problems. While the
> current algorithm works for simple jars, it fails badly for all
> modules gathering the transitive dependencies:
>
> - webapps
> - ears
> - all jars with the classpath in the manifest (esp. true for EJBs)
>
> Building an ear with two EJBs I have to add a dep for any of the
> EJBs as well as for the EAR. Otherwise the manifest of the two EJBs
> might reference the same artifact in different versions and the EAR
> will contain a third one - leaving me with a complete broken EAR
> (not to mension that M2 will screw up the classspaths in the
> manifests for snapshot deps anyway using a multi-module build - at
> least this one is fixed in 2.0.5: MEJB-18).
>
> > Alternatively, it would be reasonable to allow an override of
> > whatever the default behavior is for advanced cases ... but requiring
> > me to define version overrides in leaf nodes, simply because my
> > inheritance hierarchy is
> > deeper than my dependence hierarchy, encourages bad build architecture
> > design behavior -- and isn't part of the point of Maven to
> > eliminate that
> > kind of idiocy? :-)
>
> I wished MNG-1577 would not have been postponed from version to
> version ... feel the same about the idiocy part ...
>
> - Jörg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
