ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Tharp <joshua-th...@alumni.calpoly.edu>
Subject Re: inline resolve mode
Date Tue, 23 Jun 2009 17:35:21 GMT
The problem with doing it all on the command line is they are going to have
to specify revisions, modules, organizations, and whatever other qualifiers
as well. That means that your users are going to have to learn some encoded
syntax for including a new dependency on the command line.

I still think having a copy of the ivy.xml file is the easiest option here.
You can use diff, you can source manage different experiments, and you can
switch between them with your command line switch -Divy.xml.file=my.ivy.xml.

The XML isn't hard to learn and you could have some comments in the original
ivy.xml file that would indicate where the users should add their own
dependencies.

Josh

On Tue, Jun 23, 2009 at 10:10 AM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> wrote:

> I could.  I am just trying to make it as easy as possible for my users
> without them having to know much about IVY.  If they copy the real ivy.xml
> file and then change the dependencies section, then run dependencies, then
> go back and change the ivy.xml file again, then run dependencies again, it
> is a little cumbersome for this type of experimentation.  It is much more
> streamlined to just change the ant command line on the fly with an ANT
> property as my example shows.
>
> It would be really cool if the ivy.xml could be macrodef'ed.  What I mean
> by this is in an ANT macro, you can specify element placeholders such that a
> caller of this macro can define the element in XML which gets dynamically
> added to the macro as if the ANT developer originally wrote it.  If the
> ivy.xml had element placeholders, then I could add a placeholder in the
> dependencies section of the real ivy.xml.  Then I could provide some
> mechanism for the end user to provide the content for this placeholder,
> thus, allowing dependencies to be specified dynamically at runtime.
>
> ---
> Shawn Castrianni
>
>
> -----Original Message-----
> From: joshua.tharp@gmail.com [mailto:joshua.tharp@gmail.com] On Behalf Of
> Joshua Tharp
> Sent: Tuesday, June 23, 2009 11:26 AM
> To: ivy-user@ant.apache.org
> Subject: Re: inline resolve mode
>
> Why not allow your users to create a second ivy.xml file and then have the
> switch point to that second ivy file? That way they can utilize the full
> feature set of Ivy and if they accidentally (or on purpose) add and commit
> the second ivy file the build will ignore it.
>
> Josh
>
> On Tue, Jun 23, 2009 at 9:18 AM, Shawn Castrianni <
> Shawn.Castrianni@halliburton.com> wrote:
>
> > I am trying to allow my users to experiment with dependencies.  I do have
> > real ivy.xml files for all of my modules.  Right now, if my users want to
> > experiment and change their dependencies of their module, they have to
> edit
> > the dependencies section of the ivy.xml file.  That is fine, however, by
> > changing the real ivy.xml file, they may accidentally commit this change
> to
> > the SVN repo by mistake.  Therefore, I would like to somehow give them a
> way
> > to add dependencies to the ones already listed in the ivy.xml file
> through
> > some ANT property or something.  Like:
> >
> > ant dependencies -DextraDependencies="A,B"
> >
> > my ant script could check if the extraDependencies property is set and
> then
> > somehow tell ivy to add these two modules (A and B) to the list of
> > dependencies found in the ivy.xml file
> >
> > ---
> > Shawn Castrianni
> >
> > -----Original Message-----
> > From: Archie Cobbs [mailto:archie.cobbs@gmail.com]
> > Sent: Tuesday, June 23, 2009 9:41 AM
> > To: ivy-user@ant.apache.org
> > Subject: Re: inline resolve mode
> >
> > Hmm....
> >
> > First of all, every module must have an ivy.xml file to describe it.
> >
> > If what you want to resolve is a module, then you can do that with the
> > inline ant tasks. Then you are specifying the module name and letting ivy
> > (using your ivy settings) locate the corresponding ivy.xml file, process
> > the
> > dependencies, etc.
> >
> > If what you want to do is define a new module inline (including one or
> more
> > dependencies) and then resolve it, then you are essentially trying to
> > "inline" and ivy.xml file and I don't think ivy currently supports that.
> I
> > don't see why you would need the ability to do this anyway... you can
> > always
> > just put the module meta-data into a local ivy.xml file and then refer to
> > it.
> >
> > Not sure what you're trying to do but I typically do this kind of thing
> for
> > software projects. Each project has it's own ivy.xml that defines
> > configurations like "compile", "test", etc. When I need to build the
> > classpath for the "javac" task, I use an inline call to <ivy:cachepath>
> or
> > whatever to get the JARs associated with the "compile" configuration,
> etc.
> >
> > Hope this helps.
> >
> > -Archie
> >
> > On Tue, Jun 23, 2009 at 1:06 AM, Shawn Castrianni <
> > Shawn.Castrianni@halliburton.com> wrote:
> >
> > > I need a way to resolve dependencies of a module WITHOUT an ivy.xml
> file.
> > >  It looks like inline mode is what I want, however, I am not sure about
> > > something.  An ivy.xml file can specify more than 1 dependency, each
> with
> > > its own revision constraint and configuration specification.  It looks
> > like
> > > the inline resolve ant task only allows 1 dependency to be specified
> with
> > 1
> > > configuration and 1 revision constraint.  Therefore, it seems that
> inline
> > > resolve is not a complete replacement for an ivy.xml file.  Am I
> supposed
> > to
> > > make multiple separate calls to inline resolve for each dependency I
> have
> > > that would normally be listed in an ivy.xml file?  If so, how does the
> > > conflict resolution work since each inline resolve operation would not
> > know
> > > about the previous inline resolve operation to properly resolve
> > conflicts??
> >
> >
> >
> > --
> > Archie L. Cobbs
> >
> > ----------------------------------------------------------------------
> > This e-mail, including any attached files, may contain confidential and
> > privileged information for the sole use of the intended recipient.  Any
> > review, use, distribution, or disclosure by others is strictly
> prohibited.
> >  If you are not the intended recipient (or authorized to receive
> information
> > for the intended recipient), please contact the sender by reply e-mail
> and
> > delete all copies of this message.
> >
>

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