Thank you for your help Marc.  I understand much better now how Ivy is
intended to be used.

-Vincent

On Tue, Oct 4, 2016 at 2:19 AM, Marc De Boeck <mdeb...@gmail.com> wrote:

> 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.c...@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 <mdeb...@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.c...@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
> > > >
> > >
> >
>

Reply via email to