This is exactly what virtual repository does when maven-metadat.xml is
requested.
It merges the maven metadata from all the local and remote repositories and
returns
a unified metadata. There's been some improvements and bug fixed to this
mechanism
after version 2.2.1 which I think will solves your issue. Can you try it on
2.2.5?
Regards.
Yossi
On Wed, Sep 15, 2010 at 16:44, <[email protected]> wrote:
> [I wasn't able to find a reference defining expected behavior, so I'm
> hoping
> someone can point me in the right direction.]
>
> I have an Artifactory (version 2.2.1) instance that is being used to hold
> local
> artifacts as well as mirroring other public repositories (e.g. central).
> The
> problem I'm having is when those two realms overlap.
>
> Example Setup
> ============
> - Artifact XYZ @ version 1.0 on local Artifactory instance (because it's
> unavailable publicly -- at least I couldn't find it.)
> - Artifact XYZ @ version 2.0 on public, central repo
> - Developers settings.xml file uses local repo to mirror central (via a
> vritual
> repo URL that has access to both local and remote versions of Artifact XYZ)
>
> Problem
> ==========
> - The maven-metadata.xml file for Artifact XYZ (via the virtual repo URL)
> only
> lists the local version (i.e. 1.0) as being available
> - Developer #1 has a version range search that is satisfied by the local
> version
> -- OK
> Psuedo-POM EX1:
>
> <dependency>
> <groupId>groupid</groupId>
> <artifactId>ArtifactXYZ</artifactId>
> <version>[1.0,2.0)</version>
> </dependency>- Developer #2 has a version range search that isn't
> satisfied by the local version -- NOT OK
>
> Psuedo-POM EX2:
>
> <dependency>
> <groupId>groupid</groupId>
> <artifactId>ArtifactXYZ</artifactId>
> <version>[2.0, 3.0)</version>
> </dependency>
> Developer #2's build fails to find version 2.0 of Artifact XYZ because:
> - The artifact is being located via central, which is mirrored/routed
> through
> the local Artifactory instance
> - The local artifactory instance is providing a metadata file that only
> lists
> the local version (i.e. 1.0) of Artifact XYZ as being available
> - The build fails because it can't find version 2.0 of the artifact (even
> though
> version 2.0, pulled from central, exist in the repo already)
>
> I would have expected, perhaps naively, that the virtual repo URL would
> have
> provided a merged view of the metadata files (from "local" and "central")
> and
> provide that unified metadata file to the caller.
>
>
> One workaround is to have Developer #2 use a specific version (i.e. no
> range
> specification) which avoids the metadata lookup altogether. It works but
> isn't
> ideal.
> So, the question is whether or not this behavior is expected. If not, then
> is
> there a bug (or fixed version available)? If so, is there a specification
> document that describes how Artifactory is supposed to behave under these
> circumstances?
> Thanks,
> Bob
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Artifactory-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/artifactory-users
>
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Artifactory-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
