Hi Jon,
If you cache the ivy file locally in the "ivy-artifacts" repo (by having it
store artifacts locally), then there is no need to refetch the file from
the remote repo - you can just pick it up from the local cache using
repositories.getStringContent(). This will save you double downloading and
having to repeat the remote repo credentials in the plugin.
Regarding permissions - it should be enough allowing 'deploy' on 'local
repo'. The effect is somewhat similar to granting 'deploy' rights on caches
(which is, in fact, the default permissions for anonymous). Adding 'delete'
would be to too permissive.
The issue with m2eclipse is most likely because afterRemoteDownload() still
returns the original content to the requestor. A subsequent request to the
virtual repo locates the transformed pom correctly. I suspect Maven is
retrying the request upon receiving the Ivy content (assuming it's a bad
pom response) and that this retry logic is not part of the m2eclipse
resolution. Please see the end of my post for how to resolve this.
The checksum warnings may be because the initial ivy.xml checksum request
does not resolve a valid checksum from your remote Ivy repo.
My original suggestion was not to run the ivy.xml transformation on the fly
as part of the Maven build, but to have the Ivy files downloaded to the
cache by an Ant build (or by a simple script that requests them), and
transform them to poms in afterRemoteDownload(). After this step the poms
can be consumed by Maven clients. This would work for all Maven clients,
including m2eclipse; will allow you to have more strict permissions (e.g.,
by running the ivy.xml resolution as a privileged user); and resolve the
checksum warnings.
HTH,
Yoav
On Fri, Feb 17, 2012 at 11:52 AM, joncourt <[email protected]>wrote:
> I am also getting checksum warnings for the pom files on first download in
> my
> local build (i.e. when the afterRemoteDownload recieves an ivy.xml).....
> not
> second time around though. The checksums are generated by Artifactory when
> I
> deploy my pom content. Is there anything wrong with letting Artifactory do
> this? Is there a way to get the newly generated checksums passed through to
> my build when I hit the descriptor the first time around, I'm not
> particularly concerned - but it seems a little untidy to simply let the
> warnings occur.
>
> Regards,
> Jon
>
> --
> View this message in context:
> http://artifactory-users.108859.n3.nabble.com/Pure-ivy-xml-artifact-resolution-tp3709002p3753203.html
> Sent from the Artifactory - Users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Artifactory-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/artifactory-users
>
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Artifactory-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
