ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: dynamically modifying dependency versions during resolve
Date Tue, 08 Jul 2008 09:08:50 GMT
I catch up with this thread a little bit late, but I think I understand both
points of view. Since Ivy philosophy is flexibility, I think Ivy should
support both. Hence I've created an issue about improving Ivy to support
this as a new feature:
https://issues.apache.org/jira/browse/IVY-857

The idea is to set an attribute on the resolver which should override (or
force) whatever is requested.

Something like:
            <filesystem name="local" *force="true"*>
                <ivy
pattern="${ivy.settings.dir}/local/[module]/[revision]/ivy.xml"/>
                <artifact
pattern="${ivy.settings.dir}/local/[module]/[revision]/[artifact].[ext]"/>
            </filesystem>

Xavier

On Fri, Jun 27, 2008 at 3:42 PM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> wrote:

> Exactly.  I agree with everything you said.
>
> I am using a post beta1 feature called resolveMode="dynamic".  However,
> currently for it to work smoothly, you have to turn on
> defaultResolveMode="dynamic" which essentially makes all modules get
> resolved with the latest rule regardless of any specific revision numbers a
> normal resolve would find.  With this, a chained resolver with a local
> filesystem resolver first in the chain with returnFirst="true" works nicely.
>  This works but isn't ideal because defaultResolveMode="dynamic" affects all
> modules.  Ideally, I only want the modules that have a locally published
> module to be dynamic, but all others to perform a normal "default" resolve.
>  That would require me to, at ANT buildtime, discover what modules existed
> in the locally published repo and somehow turn on only those modules to be
> resolveMode="dynamic".
>
>
> ---
> Shawn Castrianni
>
> -----Original Message-----
> From: Ernest Pasour [mailto:Ernest.Pasour@sas.com]
> Sent: Friday, June 27, 2008 8:02 AM
> To: ivy-user@ant.apache.org
> Subject: RE: dynamically modifying dependency versions during resolve
>
> I think part of the disconnect here is that I (I can't speak for Shawn) am
> approaching this from a "good enough" standpoint.  I am only concerned about
> enabling local builds/runs that developers can do; I do not want to affect
> the official (nightly) company builds, which have to be correct.  So
> developers->good enough, nightly builds->correct.
>
> There are two large classes of code changes that "good enough" can easily
> support.
> 1. behavioral changes (no api changes)
> 2. api additions
>
> It is up to developers to know when there is a breaking api change that
> will force them to build the entire affected cloud of modules.  It is common
> for developers to use even incompatible modules for testing due to their
> knowledge of the actual runtime paths needed.  The build-time
> incompatibilities don't matter as long as the developer can get the jars
> with changed API.  The alternative at our site is unpalatable: Dev1 builds a
> new jar and asks Dev2 to try it out, but doing so requires republishing 200
> jars.  Most developers will push and pray.
>
> What I want:
> 1. A way to tweak the resolver settings or provide a new resolver (I have
> some flexibility here to tweak the settings file) so that versions of
> modules in the dev area always get used.  Note that this does not imply
> "latest".  In my environment, it is entirely possible for the version of my
> locally-built module to be "latest in the system", but lose that title when
> the nightly build runs subsequently.  So I really want an "override" to the
> Ivy resolve.
> 2. I don't want to modify the ivy.xml file, due to the risk of these
> development-time changes getting pushed.
>        2a. I want to support collaborations between multiple developers in
> a test repository.  There would have to be lots of modifications to the
> ivy.xml files in this case.
>
> I am stuck on Ivy2.0Beta1 for the foreseeable future.
>
> As I mentioned in my original post, I have partially gotten this to work by
> creating my own resolver, but I haven't figured out where to insert code to
> change the version number sought.  So, the code comes in looking for C1, and
> I modify the ModuledRevisionId on the stack to point to C2.  It appears that
> the code then correctly finds my locally-built module.  However, the
> directory that gets created has the revision corresponding to C1.  So I
> think I am inserting myself into the resolve process too late.
>
> Any hints on what kind of hook (resolver, conflict manager, etc.) I can use
> to dynamically tweak explicit published revisions?
>
> Thanks,
> Ernest
>
>
> -----Original Message-----
> From: Niklas Matthies [mailto:ml_ivy-user@nmhq.net]
> Sent: Thursday, June 26, 2008 11:03 PM
> To: ivy-user@ant.apache.org
> Subject: Re: dynamically modifying dependency versions during resolve
>
> On Thu 2008-06-26 at 20:48h, Shawn Castrianni wrote on ivy-user:
> > I guess I will give up after this email because I am not getting my point
> across as to why I need this.  I will answer one of your questions and leave
> it at that.
> >
> > > What I wonder here is: After you've tested C2 with A and published
> > > it to the public repository, how can that testing be put to use?
> > > Builds of A or dependencies on A will still get the old C1, *unless*
> > > a dependency on C2 is specified somewhere by some module. Then why
> > > should the testing be able to do without specifiying that dependency?
> >
> > If C contains interfaces and A contains implementations of those
> > interfaces, I want to make sure my interface changes in C do not break
> > the build of A before I checkin my changes to C.
>
> Well, a build of A will only get these interface changes if the dependency
> of B to C changes, right? Which means that this won't happen unless and
> until there's a new revision of B. If there is to be a new revision of B now
> depending on the new C, the new C will also have to be tested with the new
> B. So why can't the test of A wait until that new revision of B, without
> which there can't be any build of A that would break due to the new C?
> And given a new revision of B, A has to be tested against that anyway, so
> you can simply test against C at the same time in one go.
>
> Depending on whether the maintainer of B and C is the same or not, we
> handle such cases by testing B with C and then A with B and C by either
> publishing B and C locally (same maintainer) or publishing in the shared
> repository but with status=testing (different maintainers). An alternative
> to the latter would be to publish to a shared "testing" repository which is
> chained between the local and the regular shared repository.
>
> [...]
> > I can't believe Ernest Pasour and myself are the only ones needing this
> behavior.
>
> If I understand you correctly, you would want the newest revision of
> *any* transitive dependency. This is something I certainly wouldn't want,
> as bumping up all dependencies throughout the dependency tree can have all
> sorts of effects and cause breakage for reasons totally unrelated to what
> actually needs to be tested. I would only want to update the dependencies
> for what I plan to transitively depend on (C, in the above case), and that
> means specifying somewhere in test build environment of A that a newer
> revision of (specifically) C should be used. And this is nothing different
> than a build dependency of A on C.
> One can use a dedicated "testbuild" conf to play safe.
>
> -- Niklas Matthies
>
> ----------------------------------------------------------------------
> 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.
>



-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

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