ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christoffer Soop (JIRA)" <j...@apache.org>
Subject [jira] Commented: (IVY-472) conf not supported as pattern filtering token
Date Wed, 06 Feb 2008 13:33:09 GMT

    [ https://issues.apache.org/jira/browse/IVY-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566128#action_12566128
] 

Christoffer Soop commented on IVY-472:
--------------------------------------

I am also using ivy for resolving a dependencies in a .NET project and *really* need to produce
artifacts with the same name for different configurations. The reason for this is that we
rely on the the Visual Studio solution file for building and that referencing a DLL is done
by exact name, unless you use the Global Assembly Cache (which won't use for other reasons).

For development releases we want to use binaries compiled with debug symbols and for production
releases we want to use binaries without such symbols. We *do not* want to update the Visual
Studio references to production binaries with a different name than used during development.

An option would be to use some kind of latest resolution in the ivy files and publish artifacts
of different revisions for the the development and production releases.  Though this is possible
it is unsatisfactory since the only difference is the debug symbols - the revision of the
software is really the same, at least in terms of major.minor and SCM revision numbers.

Now, another possibility for differentiating between the Release and Debug versions of the
DLL's would be to use the *status* instead of conf attribute as suggested in this ticket.
The argument is that in an integration build we would always want the full debug information
but in a milestone or release build we would never want them.

The integration build would always be built automatically and when we have a milstone release
candidate we would make a manual build *of the exact same version*. However, given that the
names are the same we would need to differentiate by directory in the repository, i.e. to
use the status variable in the resolver artifact pattern, something along the way of

{{[organisation]/[module]/[status]/[artifact].[ext]}}

Writing this down it becomes evident that a simple solution to this would be to use a different
milestone and release repository altogether. This said, is there a good argument why not to
make the status available as resolver attribute?

> conf not supported as pattern filtering token
> ---------------------------------------------
>
>                 Key: IVY-472
>                 URL: https://issues.apache.org/jira/browse/IVY-472
>             Project: Ivy
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: unspecified
>         Environment: WinXP x86 with Ant1.7
>            Reporter: Todd Lee
>            Priority: Minor
>
> it seems that [conf] is not currently supported for use as an artifact pattern in an
ivy:publish task or as a pattern token for use in resolvers (as raised in ivy-user list here:
http://www.nabble.com/publishing-configurations-tf3555931.html). With configurations being
such a key component of ivy, it would be nice if the [conf] pattern were better supported
across different filtering processes. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message