ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arthur Branham (JIRA)" <j...@apache.org>
Subject [jira] Commented: (IVY-600) Add ability to construct a native library path based on dependencies
Date Thu, 19 Jun 2008 16:53:45 GMT

    [ 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.


Mime
View raw message