On 2/28/06, Ralph Goers <[EMAIL PROTECTED]> wrote:
>
> Steve,
>
> What you are proposing is to basically bypass maven and "hack" the pom's
> dynamically with the versions required.  It seems to me it would be
> easier to have a process to do that in one's local repository. Then you
> only have to do it once.  But then you don't have a real copy of what is
> at ibiblio.
>
> If this is truly the way it works than it certainly can't be claimed
> that Maven supports transitive dependencies as they will almost always
> have to be bypassed. For example, if project A includes myfaces 1.1.1 it
> has dependencies on beanutils 1.7.0 and digester 1.7.0.  What is
> interesting is that digester 1.7.0 specifies a dependency of beanutils
> 1.6.0.  Now presumably, myfaces specification will override digesters.
> But now, what if project A also specifies digester 1.7.0 as a
> dependency?  You will end up with both beanutils 1.6.0 and beanutils
> 1.7.0 in your build target, which is completely unacceptable.  The
> solution is for us to scour the pom's we are using and then look at
> their dependencies, etc.?  I don't thnik so.  Instead, everyone will be
> forced to declare all their dependencies in the parent pom.


If that's your problem, you're going to have that issue anyway, no matter
what build system you are using. Maven manages builds, its not a magic
project-hierarchy fixer. In any case, for an extention which DOES do what
you are asking, check out pomstrap:

http://pomstrap.tigris.org/

Eric

I will admit that at the moment few folks are going to run into this
> problem because 1) most maven users are still on maven 1 and 2) most
> poms at ibiblio don't specify dependencies (I would imagine this is
> incorrect).  But it only took me 5 minutes of searching to come up with
> the problem above.
>
> In which case, I have to wonder why I would ever want to go through the
> effort of rewrting all my maven 1 plugins since I won't be getting any
> benefit.
>
> Ralph
>
> Steve Loughran wrote:
> > Ralph Goers wrote:
> >> If I read you right, then I have to treat Maven 2 as if it is Maven 1
> >> and self-discover what all my project's runtime dependencies are
> >> going to be?
> >> Our configuration management dept requires that all our projects use
> >> the same versions of xerces, xalan, etc.  This is controlled via the
> >> build.properties file.  Putting it in each project's POM still leads
> >> to the possibility that other projects will use different versions.
> >>
> >> So it sounds like I have to have a dependencyManagement section in a
> >> master pom and then each project has to specify all its dependencies
> >> and this will then cause the versions specified in transitive
> >> dependencies not to be used?
> >> Ralph
> >
> > Its an interesting problem. The goal of the maven2 team is,
> > presumably, to have pom files that contain everything you need to know
> > about versions.
> >
> > Personally (and this is under Ant), I tend to create the .pom files on
> > the fly from my templates, using the <echoxml> command to generate the
> > file inline, after loading in all versions. Its kind of messy, but it
> > works. Sounds like maybe you need something similar for m2, something
> > to take a stub .pom file and expand its properties to create the pom
> > file used for that particular build, a kind of preprocessor...
> >
> > -steve
> >
> > ---------------------------------------------------------------------
> > 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]
>
>

Reply via email to