Mark Lundquist wrote:
LOL, Reinhard suggested the same thing earlier on in this thread. I
ah true i see that now, sorry !
might end up trying to do it this way temporarily, if that's what it
takes to get some work done. The main problem with it is that because
it's not location-dependent, it's not set-and-forget, which means it's
not foolproof, which means that ML is guaranteed to cock it up within
the first 24 hours (either through confusion or sheer forgetfulness)
true, but that's how it is. Anyway I'm sure you can batch-script your
way around this.
:-/ It's also kind of a heavy-handed kluge that goes against the spirit
of Maven (IMHO alternative local repo locations should only be used for
testing purposes), but that's a secondary issue.
well that's what you were describing no? Keeping trunk for testing
purposes and a local build to tinker with without impacting the other?
Anyway [ahem]... Maven may not be perfect yet, but like Eric Raymond
said, "all bugs are shallow given enough eyeballs", and there are a lot
of eyeballs on Maven right now, so I think it will get better.
eventually yes. But for such a high profile project it surprises me that
their last release is dated almost a year now.
Also, if you cram the dependencies of 100+ modules and their version
numbers in the root pom then this can become a management bottleneck
as well as this pom will need to be managed and included in the
release process of every module.
Yes — a pain. I don't like centralizing this. Anyway, w.r.t. while
there may yet be a role for <dependencyManagement> in our build system,
it looks to me like it does not help with the intra-project
dependencies, because it only addresses the dependent side and not the
installing side. The reference [1] doesn't say anything about
<dependencyManagement> affecting the <version> of any artifact being
built. It just says "anybody that uses artifact Foo, you get version
XYZ of it". If I'm actually building Foo though, this doesn't make it
build version XYZ, it still builds whatever its <project/version> says.
Yes dependencyMgmt is all about managing the dependencies of your
project, not the artifacts it produces. Note that its usage is currently
discouraged as it doesn't really work as advertised. I think it was
scheduled to be fixed for 2.0.5, then pushed to 2.0.6 ...
Thanks for your interesting thoughts!
Jorg
