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 <[email protected]> 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 <[email protected]>: > > > 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 <[email protected]> > 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 <[email protected]>: > > > > > > > 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 > > > > > > > > > >
