On 2009-03-31, Ralph Goers <ralph.go...@dslextreme.com> wrote: > On Mar 31, 2009, at 1:59 AM, Stefan Bodewig wrote:
> I did not have the necessary permission to deploy to > people.apache.org, so I deployed the snapshot to the new M2 repo at > repository.apache.org. However, I commons configuration isn't looking > there because the Commons PMC hasn't discussed using that repository > for projects. I see. Once I have Gump's proxy be used for the Apache snapshot repository it shouldn't matter too much since the proxy should hand out the JAR no matter whether the proxied server knows it or not. The Java side of this seems to be done, I "only" need to change Gump's Python side now, which requires me to change development machines (hope I'll get it done early tomorrow). > I had thought that Gump wouldn't have all these problems since it > uses its own repo and builds from trunk directly. Yes, that's the theory 8-) In practice that would require strict build ordering so that there is never an artifact downloaded from an external repository that could be built by a Gump project. In practice this doesn't work because the very first run of mvn will download a lot of stuff (including BCEL and commons-lang, for example) that are later built by projects that in turn require mvn to build. Therefore many projects use a local repository of their own that is created empty before they start building and destroyed after that. Since vfs and configuration don't share the same repository, configuration can not see the locally built vfs version. configuration's dependency on commons-lang will prevent us from ever having it use the same local repository as the projects built later as long as these "built later" project are supposed to find commons-lang 3.0 when they ask for any version of commons-lang. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
