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 Oleg Sakharov <ka...@gmail.com> on 2007/12/17 17:54:49 UTC

Configuration substitution in artifact pattern during publication.

Hello.

We try to use Ivy in our build process. This is really amazing product, but
unfortunately we have some troubles with it.


We publish some artifacts under certain configurations.

For instance, we have a described artifact pattern in our IvySetting.xml:

    <resolvers>
        <sftp name="remote">
            <ivy pattern="sftp://user:password@host
:port/repository/[module]/[conf]/[module]-[revision]-[branch].xml"/>
            <artifact pattern="sftp://user:password@host
:port/repository/[module]/[conf]/[artifact]-[revision]-[branch].[ext]"/>
        </sftp>
    </resolvers>

In our ivy.xml we have one configuration and only one artifact publication:

     <configurations>
        <conf name="configA" />
    </configurations>
    <publications>
        <artifact name="IvyTest" type="txt" ext="txt" conf="configA" />
    </publications>

After publication we expect that a full path name to the artifact in our
repository will be looks like
repository/IvyTest/configA/IvyTest-1.2.3.4-trunk.txt

However, we get
repository/IvyTest/default/IvyTest-1.2.3.4-trunk.txt

Question: Is it predefined behavior or not? Probably this is our mistake or
misunderstanding of Ivy configuration concept.
We look through the code and found that RepositoryResolver.publish()
contains call of getDestination() without any passing of configuration
parameter. Is it right?

Thank you in advance for your help.
Best regards. Oleg Sakharov.

Re: Configuration substitution in artifact pattern during publication.

Posted by Xavier Hanin <xa...@gmail.com>.
On Dec 17, 2007 5:54 PM, Oleg Sakharov <ka...@gmail.com> wrote:

> Hello.
>
> We try to use Ivy in our build process. This is really amazing product,
> but
> unfortunately we have some troubles with it.
>
>
> We publish some artifacts under certain configurations.
>
> For instance, we have a described artifact pattern in our IvySetting.xml:
>
>    <resolvers>
>        <sftp name="remote">
>            <ivy pattern="sftp://user:password@host
> :port/repository/[module]/[conf]/[module]-[revision]-[branch].xml"/>
>            <artifact pattern="sftp://user:password@host
> :port/repository/[module]/[conf]/[artifact]-[revision]-[branch].[ext]"/>
>        </sftp>
>    </resolvers>
>
> In our ivy.xml we have one configuration and only one artifact
> publication:
>
>     <configurations>
>        <conf name="configA" />
>    </configurations>
>    <publications>
>        <artifact name="IvyTest" type="txt" ext="txt" conf="configA" />
>    </publications>
>
> After publication we expect that a full path name to the artifact in our
> repository will be looks like
> repository/IvyTest/configA/IvyTest-1.2.3.4-trunk.txt
>
> However, we get
> repository/IvyTest/default/IvyTest-1.2.3.4-trunk.txt
>
> Question: Is it predefined behavior or not? Probably this is our mistake
> or
> misunderstanding of Ivy configuration concept.
> We look through the code and found that RepositoryResolver.publish()
> contains call of getDestination() without any passing of configuration
> parameter. Is it right?

Yes, the problem is that one artifact can be published in several
configurations, so we don't set the configuration token during publication.
If I remember correctly you're not the first to ask for something like this,
but I really don't see how we could handle this use case whle still allowing
one artifact to be published in several confs. What you can still do is use
an extra attribute and use this extra attribute in your pattern. This should
work (and if it doesn't this can be considered as a bug and should be
fixed).

But why do you want to isolate your artifacts by configuration in your
repository? Maybe there's another way than using configurations for what you
want to achieve?

Xavier


>
>
> Thank you in advance for your help.
> Best regards. Oleg Sakharov.
>



-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/