ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bailey, Darragh" <>
Subject RE: OS specific artifacts
Date Fri, 20 Aug 2010 09:49:10 GMT

> -----Original Message-----
> From: Mitch Gitman [] 
> Sent: 19 August 2010 21:44
> To:
> Subject: Re: OS specific artifacts
> 1) It sounds like what you "want" to do is create two 
> different files in the
> same Ivy module and give them the same name, even though they are two
> different files. This doesn't make sense.

They may be OS specific but they are being delivered to me with the same name. I've also no
idea how the team providing the jar file managed to make them different. One would expect
that the jar file should have been created to load either the dll or the so based on what
platform it's being run on. Although I have to admit my understanding of JNI libraries is
still pretty limited.

> I would suggest, instead of trying to find a way to work 
> around your current
> state of things, think about what makes the most sense 
> conceptually. From my
> limited understanding of your situation, this means either of 
> two choices:
> A. Create one Ivy module for the Windows deployment and 
> another Ivy module
> for the Linux deployment. The two component.jar files can 
> have the same name
> since they don't get deployed to the same location.
> B. Keep everything in one Ivy module and use a Windows Ivy 
> conf and a Linux
> Ivy conf. In this scenario you would have to name the 
> component.jar files
> something different, but they are different files. This 
> choice presumes that
> you're versioning and releasing your Windows and Linux deployments in
> concert, using a single version.
> Forgive me for resisting your premise.

You're forgiven, I didn't ask for alternative suggestions any expect to get the response that
said "yeap your solution is the right one" ;-)

I suspect that there will be no way for IvyDE to automatically select the right config using
this approach, and not requiring the other developers to have to manually change which conf
is selected based on OS, would be better.

> 2) Instead of using a ${target.os} placeholder, control the 
> choice between
> the Linux and Windows Ivy confs outside of ivy.xml. In your 
> build scripts,
> the ivy:resolve would specify one conf or another. In IvyDE, you would
> choose one conf or another or both. This brings you back to 
> the problem of
> conflicting names.

This gives me the result that the developers will have to modify the eclipse project settings
any time they switch OS.

Ideally this is what I want to avoid. I want that whenever the developer opens eclipse, if
he's on linux, IvyDE retrieves the linux dependencies, and if he's on windows, IvyDE retrieves
the windows dependencies. If it's being run via an Ant script, I have a lot more flexibility
at my finger tips in retrieveing configurations.

Thinking on it a little more, I suspect that a method for handling the jar file will fall
out from a solution that allows IvyDE to automatically retreive the correct deps for the current

Darragh Bailey

View raw message