ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincent Case <vincent.c...@gmail.com>
Subject Re: Using [conf] token in artifactPattern has unexpected behavior
Date Mon, 03 Oct 2016 16:08:12 GMT
Thanks for your reply Marc.

I have updated my settings as described (shown below) but am still
observing that my jar is published to a single conf of "default" rather
than to my two confs of "publicRuntime" and "publicTest".  Note that I
tried it with and without a "conf" attribute in the ant publish task. In
order to understand what Ivy is doing, I have built Ivy 2.4 locally and
added log messages that show the following.

In PublishEngine:Publish method line 287 I logged:
   Publishing artifact=interfaces   file=main\lib\interfaces.jar  with
confs= [publicRuntime, publicTest]

In RepositoryResolver:put(artifact, src, *dest,* overwrite) method line
 234, I logged
    putting *dest=*http://centos-7:8882/artifactory/rps-integration/
*default*/interfaces/1.0/interfaces-1.0.jar

Importantly, in computing "dest" in RespositoryResolver:publish, the call
to IvyPatternHelper.substitute(pattern, mrid, artifact) does not pass any
[conf] argument (which would have been the fouth argument.  This results in
the IvyPatternHelper.substitue method using "default" as the conf.

I appreciate your help and do not with to use a lot of  your time.  If it
is easier, please feel free to provide a trivial working example of
publishing a single jar to multiple configurations.  Thanks so much for
your help.

-Vincent


*Ivy Version: 2.4*

*From the Ivy File*

    <publications>
        <artifact conf="publicRuntime,publicTest" />
    </publications>

*From Ant Build File*
<ivy:publish settingsRef="ivysettings.publish"
artifactspattern="[artifact].[ext]"
resolver="${pub-resolver}"
pubrevision="publish-integration"
forcedeliver="true"
status="integration"
overwrite="true"
conf="publicRuntime,publicTest"

*From ivysettings.publish*
<resolvers>
<url name="publish-integration" cache="internal" >
<artifact pattern="[conf]/[module]/[revision]/[artifact]-[revision].[ext]"
/>
<ivy      pattern="[conf]/[module]/[revision]/ivy-[revision].xml" />
</url>
</resolvers>



On Fri, Sep 30, 2016 at 3:55 PM, Marc De Boeck <mdeboec@gmail.com> wrote:

> The publications section of the ivy-file (module descriptor) of your module
> specifies for which configuration you publish the artifact(s) which are
> part of your module:
>
> <publications>
>   <artifact name="myjar.jar" conf="confA,confB" />
> </publications>
>
> Normally the ivy-file is checked-in in your source control system, and
> during the build you will create a "resolved" ivy-file. The resolved
> ivy-file (also called "delivered" ivy-file)  will then be published
> together with your artifact. This delivered ivy-file will also contain the
> fixed revision number for that built module.
>
> Related to the location where the artifacts are created and where they will
> be published:
> the artifactspattern in the settings of your resolver specifies the
> location where the artifact will be copied to when published. You don't
> have to mimic that pattern in your build directory. It's only relevant that
> its location in the build-directory maps to the artifactpattern you specify
> in your publish task.
>
> Regards,
> Marc
>
>
> 2016-09-30 17:18 GMT+02:00 Vincent Case <vincent.case@gmail.com>:
>
> > Goal:
> >
> > I wish to publish the same artifact to multiple Confs using a url based
> > resolver and the ivy:publish ant task.
> >
> > Steps Taken:
> >
> > 1- Build an artifact named my.jar
> >
> > 2- Copy it to folders matching the artifacts pattern of the publish task
> > [conf]/[artifact].[ext]
> >
> >    -
> >
> >    pub/confA/my.jar
> >    -
> >
> >    pub/confB/my.jar
> >
> > 3- Invoke <ivy:publish> task specifying
> >
> >    -
> >
> >    artifactspattern="pub/[conf]/[artifact].[ext]"
> >    -
> >
> >    resolver="URL resolver with pattern
> >    [conf]/[module]/[revision]/[artifact]-[revision].[ext]"
> >    -
> >
> >    conf="confA,confB"
> >
> >
> > Observed Results:
> >
> >    -
> >
> >    The <ivy:publish> task attempts to publish using a single conf named “
> >    default”
> >    -
> >
> >    If the artifact is not present in pub/default/my.jar, nothing is
> >    published
> >    -
> >
> >    If the artifact is copied to pub/default/my.jar, the jar is
> successfully
> >    published to the “default” [conf] in the url based respository.
> >
> >
> > Source Code investigation:
> >
> > The relevant source code for the <ivy:publish> tasks seems reside in the
> > PublishEngine class’s publish method
> >
> > public Collection publish(
> >
> > ModuleDescriptor md,
> >
> > Collection srcArtifactPattern,
> >
> > DependencyResolver resolver,
> >
> > PublishOptions options)
> >
> > This method contain two relevant loops.
> >
> > The first loop builds a hashSet of artifacts by iterating over each conf
> > (confA, confB).  Only the first artifact is added because the equals
> method
> > of the AbstractArtifact class considers the second to be identical to the
> > first - as it does not incorporate“conf” as a differentiator.  This may
> be
> > OK since the one added artifact does specify both confs in its
> > “configurations” member.
> >
> > The second loop builds a list of files for each artifact by iterating
> over
> > each artifact’s srcPattern (i.e., artifact pattern).  In my case there is
> > one artifact pattern that includes a [conf] token.  I was expecting this
> to
> > result in two separate files, one each for confA and confB.  It doesn’t.
> > Conf is not passed to the parser (IvyPatternHelper) so it defaults to a
> > conf of “default”.
> >
> > Ivy does consider the [conf] token in my artifact pattern when searching
> > for the associated file, but uses “default”.  It also only publishes this
> > to the default conf in the remote repository.
> >
> > I am pretty sure I am making incorrect assumptions about expected ivy
> > behavior.   Any advice on accomplishing the above goal would be
> > appreciated.
> >
> > Thanks for your help.
> >
> > Vincent
> >
>

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