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.
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.
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.
On Thu, Aug 19, 2010 at 12:03 PM, Bailey, Darragh <dbai...@hp.com> wrote:
>
>
> I have a JNI library, dynamic libraries and dynamic & static build
> libraries for a software component that are all platform specific.
>
> This is causing 2 problems for me:
>
> 1) artifact filename clashing. While the dll's and libs used to compile
> against on windows and linux are all named differently, the jar files are
> not. Additionally the component is released with the same version, so
> there's nothing to distinguish with platform the jar files came from.
> Additionally we've found out that the code in the jar files on the different
> platforms even with the same release number is not identical, and while we
> can compile java components using the jar file from one or the other, we
> have to make sure that the jar file we use at runtime is the one that was
> shipped with the dll or so file.
>
> Windows:
> component.dll <-- dynamic library
> component.lib <-- library to compile against to use dll
> component_static.lib <-- static library for standalone
> component.jar <-- jar file
>
> Linux:
> libcomponent.so <-- dynamic library, used to compile against
> libcomponent_static.a <-- static library for standalone
> component.jar <-- jar file, oh look same name, oh fun!
>
> Right now, I'm not publishing these components to our internal artifact
> repository, however I plan to in order to shift fully over to using ivy for
> dependency management. In doing so I'll have to handle the fact that when
> developers are building for windows or linux, that they get the correct
> ones, particularly if we want to run any unit tests :/ (developers always
> run those, right?...).
>
> My only thoughts for a solution at the moment is to modify either the name
> or path of the jar file when publishing it to include an os specifier. This
> is the only solution I can really see working, unless of course the team
> that built the jar file could built it so that it would work wit the native
> library on either platform, but I doubt that would succeed. Any other
> suggestions?
>
>
> 2) configurations. I need OS specific configurations to distinguish the
> artifacts when ivy retrieves them so that the correct set is retrieved for
> building against whether on linux or windows. Ideally I'll like to be able
> to specify a 'build' configuration and just have ivy retrieve the correct
> dependencies depending on the target OS, however, I don't see how that is
> possible. It looks like to me, that I have to change which configuration I
> retrieve by relying on some conditionals in the ant scripts.
>
> That's possible for the ant builds, but I'm not sure how to handle this
> correctly for the eclipse builds and ivyde.
>
> Would it be possible to have a build configuration that extends a variable
> configuration i.e.
>
> <conf name="build" visibility="public" extends="build-${target.os}"
> description="--> libraries for build time depending on value of os.target
> property" />
> <conf name="build-linux" visibility="private" description="--> libraries
> for building for linux targets" />
> <conf name="build-windows" visibility="private" description="--> libraries
> for building for windows targets" />
>
> Then use a property file in ivyde to define target.os? If it's not defined
> by eclipse by default. I haven't checked.
>
>
> I haven't tried anything on this just yet, hoping to as soon as I get some
> time to work on it, but hoping that someone may have already have a solution
> and will stop me from going down a dead end before I get around to these
> problems.
>
> --
> Regards,
> Darragh Bailey
>
