So, we have two top-level Ant scripts: build.xml and deploy.xml. Our system
consists of a number of services and, right now, details of how to build,
package, deploy and start those services is scattered around these files
(and a handful of include/macro files too) which makes adding new services
and updating existing ones quite tricky.
In an effort to rationalise some of this, I am working on the concept of
"service descriptors" which will describe services - how to build, package,
deploy, start, etc.
To get this working, in both deploy.xml and build.xml we have:
<import>
<fileset dir="${basedir}"
includes="service-descriptors/*-descriptor.xml" />
</import>
And then we define a set of extension points (compile-services & build-jars
in build.xml and deploy-services & start-services in deploy.xml) that the
service descriptors can extend.
Of course, we're asking the service descriptors to extend extension points
from two different master scripts here, and that's where our trouble starts.
We cannot reverse the relationship such that the service descriptors
include/import the master scripts for two reasons:
1) On a deployed system outside of the dev environment, build.xml won't be
present
2) We don't want to just be able to start/stop/package a single service;
instead we want the master script(s) to import all descriptors that they
find and allow the descriptors to hook into points in the build/deploy
process.
We could, of course, write two descriptors for each service - one for build
and one for deploy, but there is a lot of shared stuff between the two -
properties, paths, etc. and that would lead us to having a third file for
each service which represents the common bits, and then we're getting away
from having a centralised definition of a service and not really
gaining/saving anything.
Hence my request to be able to say that if an extension point doesn't exist,
we just ignore that fact. When we're running the build, none of the deploy
extension points will be available, so, as things stand right now, the build
fails. Ditto the build extension points won't be available during a
deployment.
In essence, you describe the build file which uses "extensionOf"
importing/including the build file which has the extension-points, but we're
trying to work the other way around and throwing two "master" build files
into the mix!
I hope that's a bit clearer?
Thanks,
Danny.
On 23 June 2010 15:07, Dominique Devienne <ddevie...@gmail.com> wrote:
> On Wed, Jun 23, 2010 at 5:34 AM, Stefan Bodewig <bode...@apache.org>
> wrote:
> > I've taken your patch and modified it locally so the attribute is now
> > named onMissingExtensionPoint (and the value "error" has been renamed to
> > "fail"). I've also added constants for the three possible attribute
> > values to ProjectHelper.
> >
> > All of this is still open for debate.
>
> I'm not sure I understand the problem at hand, and thus the need for
> the proposed solution.
>
> When a build file declares extensionOf="foo" on a target, it is in
> control and can easily make sure it imports the build file that does
> declare the "foo" extension. I don't see why a build wouldn't in fact,
> since it makes no sense IMHO to write extensionOf="foo" if you don't.
> What am I missing? I can't see the situation that would warrant such a
> new feature, that a little refactoring of the builds couldn't solve by
> splitting into separate common+build+deploy specific parts. Thanks,
> --DD
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>
