ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Archie Cobbs" <archie.co...@gmail.com>
Subject Re: Packager Resolver: Simple and Complete example please.
Date Wed, 31 Dec 2008 03:16:07 GMT
On Tue, Dec 30, 2008 at 4:30 PM, Eric Berry <elberry@gmail.com> wrote:

> > Here are some ant macros that I use for this stuff:
> >
> > ...
> > This assumes your ivy.xml is in src/ivy/ivy.xml and you have defined a
> > configuration named "javac" with the appropriate dependencies.
>
> Are the macros really necessary? Will the resultant jar artifacts not be in
> the cachepath? If not, do you know if the ivy.organisation, and ivy.module
> variables are available to the packager.xml file? I'd like to avoid using
> these macros and just extracting the jar files into a directory for my
> project.
>

You don't have to use macros. They just show you how to do it. You can
"expand" them yourself if you want. In other words, I was just showing an
example.

The organisation and module names are pre-defined as
${ivy.packager.organisation} and ${ivy.pacakger.module} in packager.xml. See
the packager resolver
documentation<http://ant.apache.org/ivy/history/latest-milestone/resolver/packager.html>for
details.

To actually copy the artifacts into a specified location, use
<ivy:retrieve>.


> Out of curiousity, the packager.xml is the "artifact" defined in the
> resolver configuration, is that what is in the cachepath?
>

Not sure what you mean by "cachepath" but I'm pretty sure the answer is "no"
:-) The packager.xml is used by the packager resolver only; the rest of ivy
is completely unaware of this file. Ivy in general only knows about modules,
which contain artifacts.

When you use those ant macros to build a classpath containing a bunch of JAR
files, the packager.xml is long gone by that point.


> > Here's a src/ivy/ivy.xml example from one of my random projects:
> >
> >        <dependency name="gwt" org="com.google" rev="1.5m2"
> > conf="javac,gwtcompile->compile;runtime->runtime"/>
>
> So, the gwt dependency is actually packaged as a tgz.bz2, as defined in
> it's
> packager.xml right?
> <resource url="
> http://google-web-toolkit.googlecode.com/files/${archive}.tar.bz2<http://google-web-toolkit.googlecode.com/files/$%7Barchive%7D.tar.bz2>
> "
> sha1="aa7dbd652a78fd16256306e1a4c18a2b909fd427">
>

It depends. The ivy.xml file is independent of the particular resolver you
may happen to be using.

If you happen to be using the packager resolver to resolve the "gwt" module,
and you happen to be pointing it at Ivy RoundUp's respository, then the
answer is yes. Otherwise, ??


> Your classpath uses your provided macros to add the jars within the bz2 to
> your projects classpath?
>

Yes... more precisely, the macros simply ask ivy to fetch the jars from the
module. Because I happen to be using the packager resolver, those jars do in
fact get downloaded to my machine as part of a .tar.bz2 file before being
extracted.


> > This is just the SHA1 checksum of the thing you are downloading. On Linux
> > compute this using "openssl sha1 filename".
>
> Ah, ok. So it is absolutely required? A bit more work and it requires you
> have something like openssl to get the sha1, but guess that's how it goes.
>

Yes it is required, because there are some important security implications
if you don't verify the checksum.

-Archie

-- 
Archie L. Cobbs

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message