ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Franzen <Nathan.Fran...@mmodal.com>
Subject RE: OS specific artifacts
Date Fri, 20 Aug 2010 13:11:52 GMT

I think the difficulty is that ivy does not, out of the box, provide enough flexibility to
distinguish native artifacts.  There are lots of axes you might want to use in differentiating
libraries, for example release vs debug, windows vs linux, 32 bit vs 64 bit and so on.  And
I believe that for one codebase it is appropriate to have a one ivy project.  

So what to do?  "extra" parameters can help some:

ivy.xml:
  <publications>
       <artifact name="libX"   type="linux/icc11.32" ext="so" extra:os="linux"  extra:platform="32"
 conf="linux32-dynamic"/> 

       <artifact name="libX"   type="linux/icc11.64" ext="so" extra:os="linux"  extra:platform="64"
conf="linux64-dynamic"/> 

       <artifact name="X" conf="windows32-dynamic"
                                 extra:os="windows"  extra:platform="32" 
                                 type="winnt_vc90/Release"
                                 ext="dll"  
                                 />
       <artifact name="X" conf="windows32-dynamic"
                                 extra:os="windows"  extra:platform="32"                 
               type="winnt_vc90/Release"
                                 ext="lib"  
                                 

And then use those os + platform tags in the ivy resolve task:

<ivy:retrieve       conf="${conf.retrieve}"
                         pattern="${artifact.retrieve.dir}/([os])([platform])/[artifact].[ext]"
 
                      ivypattern="${ivyfile.retrieve.dir}/[organization].[module]/ivy.xml"
                            file="${basedir}/ivy/ivy.xml"  revision="${version}" refresh="true"
 />
 
* actually, ([os])([platform]/) is probably better in order to avoid cases of "//" if those
tags are not defined.

I don't have all this working beautifully in our heterogeneous environment yet, but there
seem to be enough pieces to put it all together.  Notice of course that the configuration
has mutated a little from the ivy traditional sense of conf=>"downstream usage" into conf=>"upstream
categorization"   And I've used "type" just to represent part of compilation original path,
i.e. an alternate (but less meaningful) way of disambiguating the artifacts.  I know that's
a little ugly.

A solution to conflicting names exists, so if you are willing to set the configuration outside
of ivy somehow, then it can work.

-Nate

> -----Original Message-----
> From: Bailey, Darragh [mailto:dbailey@hp.com]
> Sent: Friday, August 20, 2010 5:49 AM
> To: ivy-user@ant.apache.org
> Subject: RE: OS specific artifacts
> 
> 
> 
> 
> > -----Original Message-----
> > From: Mitch Gitman [mailto:mgitman@gmail.com]
> > Sent: 19 August 2010 21:44
> > To: ivy-user@ant.apache.org
> > 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 platform.
> 
> 
> --
> Regards,
> Darragh Bailey

Mime
View raw message