You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Danny Yates <da...@codeaholics.org> on 2010/06/19 23:46:37 UTC
missing extension-point behaviour
Hi guys,
I'm loving the new 1.8 extension point functionality.
I'm working on a project which has multiple deployable components
("services") and has separate build and deploy scripts. I'd like to use
extension points to be able to write a single "descriptor" for any given
service in order to centralise the definitions of services which are
currently sprinkled liberally throughout the build and deploy scripts.
The problem I have is that some of the targets in the descriptor are
extensions of extension points in the build script (and are only used during
build) and some are extensions of extension points in the deploy script (and
are only used during deployment). Of course, this doesn't work because
ProjectHelper2 tries to verify the existence of an extension point during
project file parsing and which extension points are present is a function of
whether the importing script is the build script or the deploy script.
I've made some changes to add an "extension-point-missing" attribute which
takes values:
- "error" - the current behaviour (and default if the attribute is
missing)
- "warn" - log a warning and ignore (see next)
- "ignore" - don't stop or warn, and don't add the extension target as a
dependency of the (non-existent) extension point
I'd like to submit this patch for consideration for Ant 1.8.2. How do I go
about doing that?
Thanks,
Danny.
Re: missing extension-point behaviour
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-06-23, Danny Yates wrote:
> I take it this will be in 1.8.2 then?
Yes.
> Is there a schedule for release?
Not even a tentative one so far.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: missing extension-point behaviour
Posted by Danny Yates <da...@codeaholics.org>.
That's awesome. Thanks Stefan.
I take it this will be in 1.8.2 then? Is there a schedule for release?
On 23 June 2010 11:34, Stefan Bodewig <bo...@apache.org> wrote:
> On 2010-06-22, Danny Yates wrote:
>
> > OK, so no feedback. Consider this to be me nagging :-)
>
> Consider me nagged.
>
> 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.
>
> It should pop up inside Ant's svn trunk once the current infrastructure
> hickups have been resolved (the European svn server seems to be in
> trouble right now).
>
> Many thanks for the very complete patch which even addressed the
> antstructure task.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: missing extension-point behaviour
Posted by Dominique Devienne <dd...@gmail.com>.
On Wed, Jun 23, 2010 at 4:27 PM, Danny Yates <da...@codeaholics.org> wrote:
> Thanks for the pointer ref <fileset>
>
> I'm not sure that merging the two builds is possible for various reasons.
> Technically, yes; but for "security reasons", no.
>
> Also, I'd really like it so that I don't have to <subant> (or <ant> or
> <antcall> or whetever) into the service-specific scripts, because there are
> (will be) a large number of touch points, and I don't want to have to go and
> find each of them whenever a new service is added. As I have it now, adding
> a new service is as simple as dropping in a new service descriptor.
You already have these descriptor builds, so importing them all in 2
builds, or have them import 2 builds is not much different, and that's
the same number of touch points if you add a new service.
But I'll stop arguing, I don't know the specifics and you obviously
made these conscious choices for a reason. I'm still a bit on the
fence, but that doesn't matter, you already got buy in from Stefan, so
my guess is that you're mostly home free having this feature enabled
given that no other commiters chimed in ;) Cheers, --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: missing extension-point behaviour
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-06-23, Danny Yates wrote:
> Also, I'd really like it so that I don't have to <subant> (or <ant> or
> <antcall> or whetever) into the service-specific scripts, because there are
> (will be) a large number of touch points, and I don't want to have to go and
> find each of them whenever a new service is added.
This is how I understood it. You are using wildcard imports and
extension-ppoints as an alternative to subant where you have to know all
callable targets upfront. Given that subant is way more heavyweight
than import and plain dependencies I can understand you want to avoid
subant.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: missing extension-point behaviour
Posted by Danny Yates <da...@codeaholics.org>.
Thanks for the pointer ref <fileset>
I'm not sure that merging the two builds is possible for various reasons.
Technically, yes; but for "security reasons", no.
Also, I'd really like it so that I don't have to <subant> (or <ant> or
<antcall> or whetever) into the service-specific scripts, because there are
(will be) a large number of touch points, and I don't want to have to go and
find each of them whenever a new service is added. As I have it now, adding
a new service is as simple as dropping in a new service descriptor.
Cheers,
Danny.
On 23 June 2010 20:46, Dominique Devienne <dd...@gmail.com> wrote:
> On Wed, Jun 23, 2010 at 2:17 PM, Danny Yates <da...@codeaholics.org>
> wrote:
> > [...]
> > 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?
>
> That is clearer indeed, and the reason why I didn't get it, because
> what you are trying to achieve is "upside-down" compared to my
> thinking and I suspect the way extension-point where designed to be
> used. I kinda understand your rational for doing it that way though,
> even though I think I would have gone for a different design,
> possibly:
>
> 1) merge build.xml and deploy.xml and be done with it. Somehow I
> suspect the target sets are mostly orthogonal and the merge is
> possible.
> 2) do exactly what you say you didn't want to do :) i.e. do it
> "right-side-up" by having each "service" script import (now helper as
> opposed to master) build(er).xml and deploy(er).xml. To build all
> services, you'd <subant> into each "service"-specific script.
>
> So I guess now I'm more +/-0 on this new feature, rather than plain -0.5.
> --DD
>
> PS: You want <fileset dir="service-descriptors"
> includes="*-descriptor.xml" /> to ensure you don't scan the whole of
> ${basedir}. Antoine's optimization probably recognize that case, but
> it's always better to be as specific with the fileset's dir attribute
> as you can.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: missing extension-point behaviour
Posted by Dominique Devienne <dd...@gmail.com>.
On Wed, Jun 23, 2010 at 2:17 PM, Danny Yates <da...@codeaholics.org> wrote:
> [...]
> 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?
That is clearer indeed, and the reason why I didn't get it, because
what you are trying to achieve is "upside-down" compared to my
thinking and I suspect the way extension-point where designed to be
used. I kinda understand your rational for doing it that way though,
even though I think I would have gone for a different design,
possibly:
1) merge build.xml and deploy.xml and be done with it. Somehow I
suspect the target sets are mostly orthogonal and the merge is
possible.
2) do exactly what you say you didn't want to do :) i.e. do it
"right-side-up" by having each "service" script import (now helper as
opposed to master) build(er).xml and deploy(er).xml. To build all
services, you'd <subant> into each "service"-specific script.
So I guess now I'm more +/-0 on this new feature, rather than plain -0.5. --DD
PS: You want <fileset dir="service-descriptors"
includes="*-descriptor.xml" /> to ensure you don't scan the whole of
${basedir}. Antoine's optimization probably recognize that case, but
it's always better to be as specific with the fileset's dir attribute
as you can.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: missing extension-point behaviour
Posted by Danny Yates <da...@codeaholics.org>.
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 <dd...@gmail.com> wrote:
> On Wed, Jun 23, 2010 at 5:34 AM, Stefan Bodewig <bo...@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-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: missing extension-point behaviour
Posted by Dominique Devienne <dd...@gmail.com>.
On Wed, Jun 23, 2010 at 5:34 AM, Stefan Bodewig <bo...@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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: missing extension-point behaviour
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-06-22, Danny Yates wrote:
> OK, so no feedback. Consider this to be me nagging :-)
Consider me nagged.
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.
It should pop up inside Ant's svn trunk once the current infrastructure
hickups have been resolved (the European svn server seems to be in
trouble right now).
Many thanks for the very complete patch which even addressed the
antstructure task.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: missing extension-point behaviour
Posted by Danny Yates <da...@codeaholics.org>.
OK, so no feedback. Consider this to be me nagging :-)
On 21 June 2010 13:37, Stefan Bodewig <bo...@apache.org> wrote:
> On 2010-06-21, Danny Yates wrote:
>
> > Anything I can do to assist?
>
> Wait and answer questions/concerns as they arrise (if they arrise).
>
> Nag and become annoying if you feel it takes too long ;-)
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: missing extension-point behaviour
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-06-21, Danny Yates wrote:
> Anything I can do to assist?
Wait and answer questions/concerns as they arrise (if they arrise).
Nag and become annoying if you feel it takes too long ;-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: missing extension-point behaviour
Posted by Danny Yates <da...@codeaholics.org>.
Thanks Stefan.
Anything I can do to assist?
Cheers,
Danny.
On 21 June 2010 07:59, Stefan Bodewig <bo...@apache.org> wrote:
> On 2010-06-19, Danny Yates wrote:
>
> > I've made some changes to add an "extension-point-missing" attribute
> which
> > takes values:
>
> > - "error" - the current behaviour (and default if the attribute is
> > missing)
> > - "warn" - log a warning and ignore (see next)
> > - "ignore" - don't stop or warn, and don't add the extension target as
> a
> > dependency of the (non-existent) extension point
>
> Sounds reasonable - one could argue about the name and see whether there
> is anything that better matches existing names in Ant, but that's a
> different issue.
>
> > I'd like to submit this patch for consideration for Ant 1.8.2. How do I
> go
> > about doing that?
>
> You've done everything exactly the way it should be: Prepare a patch
> against svn trunk, ideally containing test cases and documentation, open
> a bugzilla issue and attach it there. Discuss your proposal on this
> list.
>
> Now let's wait to see whether any of the other developers has an opinion
> on it as well.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: missing extension-point behaviour
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-06-19, Danny Yates wrote:
> I've made some changes to add an "extension-point-missing" attribute which
> takes values:
> - "error" - the current behaviour (and default if the attribute is
> missing)
> - "warn" - log a warning and ignore (see next)
> - "ignore" - don't stop or warn, and don't add the extension target as a
> dependency of the (non-existent) extension point
Sounds reasonable - one could argue about the name and see whether there
is anything that better matches existing names in Ant, but that's a
different issue.
> I'd like to submit this patch for consideration for Ant 1.8.2. How do I go
> about doing that?
You've done everything exactly the way it should be: Prepare a patch
against svn trunk, ideally containing test cases and documentation, open
a bugzilla issue and attach it there. Discuss your proposal on this
list.
Now let's wait to see whether any of the other developers has an opinion
on it as well.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org