ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <mgit...@gmail.com>
Subject Re: Publishing 3rd party libraries to local repo
Date Mon, 05 Oct 2009 15:25:52 GMT
Answers inline.

On Mon, Oct 5, 2009 at 5:04 AM, Troy Self <tself@bbn.com> wrote:

> Hello,
>
> I am new to Ivy and am trying to setup a repository for my software team. I
> have
> gone through all of the tutorials on the web site and have some questions.
>
> Is there a tried and true approach for quickly creating repository entries
> for
> 3rd party libraries? I have used the ivy:install command to copy items that
> are
> already in Ibiblio or ivyrep, but what is the approach when neither of
> those
> public repositories have the library you want, or they don't have the
> latest
> version? Some examples are the slf4j-api and slf4j-log4j libraries. My
> project
> depends on the latest versions, which are not published publicly, so I'd
> like to
> add them to my own repo. Do you setup a project for each library and then
> ivy:publish them? Or do you just manually create ivy.xml files and
> carefully
> establish the correct directory/file structure in your repo?
>

The most common thing I've seen people do to create third-party Ivy modules
from scratch is to effectively blur the line between a source Ivy module and
a published Ivy module. So instead of running the ivy:publish Ant task to
publish the Ivy module to the repository, they would manually add it. This
means going into the ivy.xml file and manually adding the content that would
normally distinguish a published ivy.xml from a source one. This includes
the publication and status attributes in the /ivy-module/info element. One
thing you're lacking when you do this manual "pseudo-publish" is the
creation of the .md5 and .sha1 one-way hash files for the ivy.xml and the
artifacts.

A more correct--but still simple approach--is to create a build script that
does an ad hoc Ivy publish for an Ivy module whose name and location you
pass in. The easier to use you can make this build script, the better off
you'll be.

These are the two approaches I can think of that would be accessible to
someone new to Ivy.

>
> Is there a way to query for the configurations of a repository entry? In
> setting
> up my own dependencies, I need to map my own confs to the dependency's
> confs.
> Right now that requires browsing to the repository to find the ivy.xml
> files for
> each dependency and reading them. Is there a way to query for details about
> a
> particular artifact, including its confs?
>

I think most people don't find it too onerous to go straight to the ivy.xml
itself for confs and artifacts. Beyond that, you can use the ivy:report or
ivy:repreport Ant tasks to produce an HTML representation of Ivy modules.
The HTML report is arguably more readable.

>
> Is there a best practices for defining the various confs for a project?
> There
> seems to be some inconsistency between what 'runtime' and 'default' means
> across
> different dependencies.
>

Keep in mind that Ivy confs or conf names are arbitrary. You define your
own. So my suggestion is to establish your own naming conventions and then
just stick with them. Names like runtime or default are pretty much
interchangeable. The idea, though, is not to become too tied to your
standard palette of confs so that you can create new ones as needed to
accurately describe the published artifacts or special dependency needs of a
particular module. Beyond this, I would recommend making rigorous use of the
visibility attribute and trying to clearly delineate which confs are public
and which are private.

>
> Thanks very much for any help,
>
> -- tBs
>
> Troy Self
>
>
>

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