You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by "Arthur Branham (JIRA)" <ji...@apache.org> on 2008/06/19 18:53:45 UTC

[jira] Commented: (IVY-600) Add ability to construct a native library path based on dependencies

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

Arthur Branham commented on IVY-600:
------------------------------------

This works fine if you are only dealing with native libraries for 1 particular platform.  What if there are multiple native library builds and you need to choose .so's based on a particular build type?

I found 2 possible solutions to deal with multiple native library builds:

1) Declare a configuration for each platform type and add an artifact search path in ivysettings based on the conf name.
     <ivy pattern="${repository.dir}/[branch]/[organisation]/[module]/[revision]/native/builds/[conf]/[artifact].[ext]" />     
    You would then use your procedure above to covert from the fileset to the dirset.

2) Use the extra attributes feature to declare a jni attribute in the <info> element of the module descriptor.
    <info organisation="a" module="b" revision="c" extra:jni="/repository/org/mod/rev/native/build/lib" />
    By plugging in a custom Ivy trigger you can listen for the post-resolve and post-resolve-dependency events and process the jni attribute appending its value to a project path reference.  The problem with this is that you are restricted to a platform dependent path and only one build type.  In order for this solution to work Ivy would have to support property expansion in the module descriptors.  You could then imagine something more dynamic like:
    <info organisation="a" module="b" revision="c" extra:jni="${repository}/org/mod/rev/native/${build}/lib" />
    where ${repository} is the platform dependent path to the repository base and ${build} is the target native build
     

What are your thoughts on the second approach?


> Add ability to construct a native library path based on dependencies
> --------------------------------------------------------------------
>
>                 Key: IVY-600
>                 URL: https://issues.apache.org/jira/browse/IVY-600
>             Project: Ivy
>          Issue Type: New Feature
>          Components: Ant, Core
>            Reporter: Arthur Branham
>
> We are currently experimenting with the IVY project as the central dependency management system for our ANT build system.  So far we have achieved compile configurations and have used these to construct a dynamic classpath which is fed to the javac task.  This works perfectly for compiling projects and we have moved onto the next step of running standalone projects using our ANT system.  I know IVY is centered around being a build system, but it is very very close to being a great program launcher.  With the ability to define different configurations for projects in the dependency description file (compile, runtime) you can use a runtime configuration to build a dynamic classpath to feed to the java ant task.  The only missing piece is incorporating native library folders dynamically in a java.library.path based on the dependent modules used in bulding the classpath. 
> What I am requesting is the ability to export a path of library directories rather than artifact files.  Maybe you could possibly create a "library" element similar to artifact in the publications section and have a different "librarypath" task similar to cachepath to resolve these library folders based on a "library" pattern under the resolvers in the settings file. 

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