ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Oulds <jonathan_ou...@mcafee.com>
Subject Best Practice for producing customised builds
Date Thu, 03 Feb 2011 11:14:55 GMT
Hello,

I am hoping that the community can give some insight into the best way 
to resolve a particular issue we have here.  Let me explain my use case 
and apologies for the simplicity of this example.

Use Case:
I have an ivy module called FooBar that produces the artefact FooBar.msi 
  FooBar depends upon the modules Foo and Bar.  Foo exports the artefact 
Foo.exe, while Bar exports Bar.h under an interface configuration and 
Bar.dll under an implementation configuration.

So to summarise my dependencies are:
FooBar -> Foo
FooBar -> Bar [impl]
Foo -> Bar [iface]

Now I want to produce a proof of concept release called FooBarPoC that 
includes BarPoc.dll, however I don't want to make any changes that will 
break my original FooBar build.  So my options seem to be.

Option1:
Create a new BarPoC module, but keep the original Foo dependency.  This 
seems wrong as the relationship between the interface and implementation 
of Bar and BarPoC are no longer explicit.  On the upside it is trivial 
to implement.

FooBarPoC -> Foo
FooBarPoC -> BarPoC [impl]
Foo -> Bar [iface]

Option2:
Publish the BarPoC.dll as part of my Bar module and create a new 
configuration.  This appears to be the "Ivy" way.  The interface and 
implementations are tightly coupled, however changes to the BarPoC 
source code will trigger a build and publish of the entire Bar module 
which may cause confusion as it will not be obvious which dll was 
changed in each revision.

FooBarPoC -> Foo
FooBarPoC -> Bar [impl-poc]
Foo -> Bar [iface]

Option3:
Do away with configurations completely and instead create BarImpl, 
BarIFace and BarPoCImpl modules.  This seems to go against the advice in 
the Ivy tutorials but it also seems to be the most flexible.  Changes to 
the BarPoCImpl module do not require a rebuild and publish of BarImpl. 
Whereas changes to the BarIFace module will require a rebuild of 
everything as expected.

FooBar -> Foo
FooBar -> BarImpl -> BarIFace
FooBarPoC -> Foo
FooBarPoC -> BarPoCImpl -> BarIFace
Foo -> BarIFace

Thank you for getting to the end of this rather long post.  So does 
anyone have any experience of these three approaches and has found any 
of them to be particularly useful or problematic in the long term.

Many thanks.
Jonathan Oulds


Mime
View raw message