ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <mgit...@gmail.com>
Subject Re: Help publishing from one repository to another repository
Date Sat, 18 Sep 2010 05:25:15 GMT
Scott, if you're getting something from repository A and pushing it out to
repository B, you don't want to cut out the middleman that is the Ivy client
and the Ivy cache.

So I would recommend:
1. Do an ivy:resolve of the module you care about in repository A. I imagine
this would be with transitive="false".
2. Do an ivy:cachefileset of what you just resolved.
3. Copy the fileset to a staging location in your project, not unlike what
you'd have if your project was building the artifacts rather than just
getting them from somewhere else.
4. Do an ivy:deliver that specifies a pubrevision whereby you'd be taking
the copied ivy.xml and producing another one with the revision you want.
5. Do an ivy:publish of the delivered ivy.xml and its associated artifacts.

Note that you're going from repository A to cache and then from cache to
staging location and finally to repository B.

Now, there's one complication I've glossed over. The files obtained by
ivy:cachefileset will have the revision in their names, like
foo-2.0.235.jar. One approach is to manually strip the revision portion of
the name, but this seems a bit hacky and manual. Maybe the better approach
is to use an Ivy cache whose ivyPattern and artifactPattern leave the
revision out of the filenames.

On Fri, Sep 17, 2010 at 2:47 PM, Scott Goldstein <
Scott.Goldstein@nextlabs.com> wrote:

> I'm trying to write a java app that will publish artifacts from one
> repository to another.  The problem I'm running into seems to be caused by
> the PublishEngine behavior with respect to revision.  Specifically, in my
> first repository, the revision is the build number.  In my second
> repository, the revision is the release number.  The PublishEngine doesn't
> seems to handle this, as during the publish process when it searches for
> source artifacts, it substitutes the target revision in the source pattern
> rather than the source revision.  This happens on line 158:
>
>         md.setResolvedModuleRevisionId(pubmrid);
>
> I don't see any way around this, as there is no concept of a Source Module
> Revision and a Target module Revision.
>
> If this a bug or a limitation?
>
> I suppose that next thing to try would be to retrieve the artifacts locally
> and then try to publish.  Hopefully that will work.
>
> Thanks.
>
> Scott
>
> - --------------------------------------------------------------------
> STATEMENT OF CONFIDENTIALITY
>
> The information contained in this electronic message and any attachments to
> this message are intended for the exclusive use of the addressee(s) and may
> contain confidential or privileged information. No representation is made on
> its accuracy or completeness of the information contained in this electronic
> message. Certain assumptions may have been made in the preparation of this
> material as at this date, and are subject to change without notice. If you
> are not the intended recipient, you are hereby notified that any
> dissemination, distribution or copying of this e-mail and any attachment(s)
> is strictly prohibited. Please reply to the sender at NextLabs Inc and
> destroy all copies of this message and any attachments from your system.
> ======================================================================

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message