ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Collison <kcolli...@keithcollison.com>
Subject Re: Publishing modules that depend on local versions
Date Wed, 20 Dec 2006 02:27:22 GMT
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="ivy.target.env" 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="${ivy.target.env}.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 "ivy.target.env" property, which is passed on to Ivy:

<target name="publish.shared">
    <property name="ivy.target.env" 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 "ivy.target.env".

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  :-)

~ 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


Mime
View raw message