ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: Publishing modules that depend on local versions
Date Wed, 20 Dec 2006 07:55:36 GMT
On 12/20/06, Keith Collison <> wrote:
> I'm familiar with this problem.  Here's what I did to prevent it.
> I'm assuming your ivy configuration had a resolver chain that includes
> both shared and local repositories.  Probably something like so:
> <chain name="default" returnFirst="true">
>             <resolver ref="local"/>
>             <resolver ref="shared"/>
> </chain>
> At least, that's how mine was configured.  The first thing I did was to
> have a ivy property defined at the beginning of my ivyconf.xml:
> <property name="" value="local" override="false"/>
> The name and value of this property are arbitrary, but it is important
> that it has "override='false'".
> In the <conf> node, I use this property to define the default resolver
> like so:
> <conf defaultResolver="${}.chain"/>
> Then I made two chains -- one which included the local resolver and one
> which did not.
> <chain name="local.chain" returnFirst="true">
>             <resolver ref="local"/>
>             <resolver ref="shared"/>
> </chain>
> <chain name="shared.chain" returnFirst="true">
>             <resolver ref="shared"/>
> </chain>
> Finally, in the projects' build.xml, I had a target named
> "publish.local" and "publish.shared".  The first thing "publish.shared"
> would do is define the "" property, which is passed on to
> Ivy:
> <target name="publish.shared">
>     <property name="" value="shared"/>
>     <!-- the usual ant-ivy code -->
> </target>
> No such property definition is needed in the "publish.local" target,
> because of the default value assigned to "".
> I should mention that I wasn't particularly happy with this approach,
> even though it worked as desired.  I ended up reverting it -- instead I
> made it policy that only our "buildmaster" unix account could publish to
> the shared repository (and that account did not have a local
> repository).  Although the above approach prevented local-dependencies
> in publications, it did not prevent developers from publishing to the
> shared repository without having first committed their code (or, worse
> yet, publishing without having first updated their code from the VCS!).
> I'm not sure of the size of your team though, so it may be more suitable
> to your needs.
> I should also mention that I believe if you make good use of the
> "status" attribute of publications (integration/milestone/release), you
> can achieve the same results.  For example, if all the modules in your
> local repository have a status of "integration", publishing a module as
> "milestone" will ensure that no integration modules are resolved,
> *provided* you are using statuses in your dependency declarations (i.e.
> <dependency module="commons-lang" rev="latest.integration"/>.  Xavier
> will have to confirm that -- I never explored that avenue.
> Hope this helps.  At this point Xavier will probably demonstrate a much
> easier way to achieve what you're after  :-)

No, I have no such easier way to achieve what you're after, your solution is
good in the sense that it works. Using statuses to assure that you always
have your dependencies in the shared repository is also possible, either by
using latest.<status> in your dependencies declaration, or by using the
deliver task to do recursive delivery (which is not that simple to set up,
but it's worth the work). But this require that you have no integration
versions in your shared repository, only milestone or release one.


~ Keith
> John Williams wrote:
> > I've had a problem recently with accidentally publishing modules to a
> > shared repository that depend on other modules that only exist in the
> > local repository.  Is there some easy way to prevent this from
> > happening by accident?
> >
> > --jw

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