ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Oster" <os...@bmi.osu.edu>
Subject RE: How to use different retrieve rules for different organizations/modules?
Date Fri, 11 Jan 2008 02:14:59 GMT
I did some additional searching of the mailing lists, and found a
related thread:

http://www.mail-archive.com/ivy-user@incubator.apache.org/msg01789.html

This thread describes the same requirement, and it seems the proposed
solution was essentially what I came to (using specific confs for it).
The problem I have with this solution is the need to use revisions or
not in the filename is generally not a function of each depending
module, it's a function of the original artifacts (at least in the
context of a bunch of projects/modules sharing ivy settings).

 

For example, say I have a large product built from a large number of
modules, and I am using Ivy for my dependency management.  Across all of
these modules, there are some artifacts I don't want to use revisions in
the resolved files, and others I do.  The problem is actually not
specific to just artifact revisions, that just the most common use case.
As another example, consider the case where some artifacts are published
with a common prefix, such as the organization name.  Ivy is extremely
powerful in letting me specify artifact patterns to search my
repository, such that I can handle all these cases.  The problem is that
I don't have the same flexibility when it comes to actually retrieving
the resolved files to my local project.  That is, the information about
how the original artifact was named in the repository is lost, and I
pretty much need to use a common retrieve pattern for all my
dependencies.  I'd like "a way" to be able to say that I want to name
the files the same as they were named in the repository.  It's really
not desirable to have each module have to know which of these artifacts
have these constraints, and have to make their own configurations just
to handle these rules.  This is a "build smell" where this information
has to be replicated in every module that depends on those
modules/artifacts, even when it's for different reasons.  Worse yet, a
given module might have multiple configurations that need such
artifacts, and so would need multiple additional private configurations
just to handle these custom retrieve rules.

 

Please do let me know if there is a better way to address this.  If not,
I have two proposals, listed in order of preference:

1)     Provide a way to specify that an artifact's name in the
repository is what should be used in the retrieve.

One way to do this would be to add another artifact pattern that could
be used for retrieve.  For example, consider "module A" publishes
version 1.0 of artifact "A" as "A-1.0.jar" in one repository and "module
B" publishes version 1.0 of artifact "B" as "B.jar" in another
repository, and that I have my ivy repository settings setup such that I
can properly locate the right artifacts.   What I would like to be able
to do is specify an artifact pattern for the retrieve task that would
look something like this: 

.../[conf]/[type]s/[artifact.filename]

The new token, "artifact.filename" would be bound to the filename of the
resolved artifact as found in the repository.  So in the example, if I
resolved a configuration that had dependencies on version 1.0 of both
module A and module B, I would get a directory like this:

myconf/

               jars/

                              A-1.0.jar

                              B.jar

I also considered suggesting the ivy file syntax could be extended to
support something like "preferred.filename" as an attribute on
publications/artifact and that could be used as the retrieve pattern
token, but just using the filename in the repository should suffice.

2)     Support conditions on the retrieve task.

Retrieve currently supports limiting the retrieve on things like
organization, module, etc, but unless I'm doing something wrong it only
seems to work against the depending module (i.e. the module doing the
retrieve), not the dependencies.  I would like to be able to do multiple
retrieves, but specify the constraints on which dependencies to actually
pull.  For the example above, I could do two retrieves and specify
"module B" as one module condition with my specialized pattern (to
remove the revision), and another with my default pattern with a
condition of something like !"module B".  This seems to be what is
suggested here
http://www.mail-archive.com/ivy-user@incubator.apache.org/msg01329.html
but it doesn't seem to do what I expect.  If I try specify
organization="some organization I depend on", I get an
illegalstateexception complaining that a report file doesn't exist.  It
appears to be looking for "some organization I depend on"#"mymodule.

 

Scott

 

 

 

 

From: Scott Oster 
Sent: Thursday, January 10, 2008 5:05 PM
To: 'ivy-user@incubator.apache.org'
Subject: How to use different retrieve rules for different
organizations/modules?

 

Hi,

I have a question on how I can handle organization or module specific
rules for copying dependencies into my components.

In general I want to resolve/retrieve my artifacts with a pattern like
this:

.../[conf]/[type]s/[artifact]-[revision].[ext]

However, for compatibility with my existing system, I need to copy some
of the artifacts without the revision specified.  For example, a pattern
like this:

.../[conf]/[type]s/[artifact].[ext]

 

I cannot find a clean way to do this, short of defining specific private
configurations in my module which include the relevant
modules/organizations, and resolving these configurations separately.
This works, but its clutters up my ivy file (with all the configurations
needed just to support this) and makes the resolve/retrieve part of my
build much more complex (as I need multiple calls which specify specific
configurations).

 

Is there any way to set conditions on the retrieve pattern, or in my ivy
file such that I could handle these special cases?  The absolute ideal
would be to handle this in the repository settings (such as having the
retrieve use the same pattern used by the resolver), but I'm open to a
module specific solution.

 

Thanks for the great software and your help, 

Scott

 

Scott Oster

 

co-Director, Software Research Institute

Biomedical Informatics Department

Ohio State University

oster@bmi.osu.edu

lab:  614-292-9845

voice mail:  614-292-8680

 


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