You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Vincent Case <vi...@gmail.com> on 2016/10/03 16:08:12 UTC
Re: Using [conf] token in artifactPattern has unexpected behavior
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 <md...@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 <vi...@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
> >
>
Re: Using [conf] token in artifactPattern has unexpected behavior
Posted by Vincent Case <vi...@gmail.com>.
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 <md...@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 <vi...@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 <md...@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 <vi...@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
> > > >
> > >
> >
>
Re: Using [conf] token in artifactPattern has unexpected behavior
Posted by Marc De Boeck <md...@gmail.com>.
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 <vi...@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 <md...@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 <vi...@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
> > >
> >
>