ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc De Boeck <mdeb...@gmail.com>
Subject Re: Using [conf] token in artifactPattern has unexpected behavior
Date Tue, 04 Oct 2016 06:19:45 GMT
Actually, I never had to publish to separate directories per configuration.
And also the documentation doesn't mention that it's possible.
Typically in Ivy, each artifact is published only once per revision.  The
"published" module descriptor (ivy-file) tells you which artifacts are part
of every configuration.
Is there a reason why you want to make separate copies of your artifact for
each configuration ? Maybe you want to put them all together, so you can
package them afterwards in a convenient way ? In that case, you should have
a look at the ivy:retrieve task. It's a post-resolve task which gives you
the possibility to retrieve (copy) all artifacts for a specific
configuration into a directory. Maybe this task and other post-resolve
tasks can give you a more elegant (ivy-like) solution for the problem you
want to solve.

If you really want to publish to separate directories for each
configuration, you may consider looking at the extra-attribute
functionality in ivy (see  http://ant.apache.org/ivy/
history/2.1.0/concept.html). You can use the extra-attribute on the module
level or on the artifact level. For example, we use it to publish our
source code together with the binary:

Here is an extract from an ivy-file for publishing also the sources:

     <publications>
        <artifact name="artifact1" type="jar" />
        <artifact name="artifact1" type="source" conf="sources" ext="jar"
e:classifier="sources" />
    </publications>

In your case, you could create an extra attribute per configuration:
     <publications>
        <artifact name="interfaces" e:ivy-configuration="publicRuntime"
conf="publicRuntime" />
        <artifact name="interfaces" e:ivy-configuration="publicTest"
conf="publicTest" />
     </publications>
Mind that you also need to adapt the artifactpattern in the settings of
your resolver accordingly.

HTH,
Marc


2016-10-03 18:08 GMT+02:00 Vincent Case <vincent.case@gmail.com>:

> 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
> <http://centos-7:8882/artifactory/rps-integration/%0A*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