Re: missing extension-point behaviour
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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: missing extension-point behaviour
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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: missing extension-point behaviour
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 bode...@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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: missing extension-point behaviour
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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: missing extension-point behaviour
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
Re: missing extension-point behaviour
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
Re: missing extension-point behaviour
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-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: missing extension-point behaviour
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 ddevie...@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-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: missing extension-point behaviour
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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: missing extension-point behaviour
OK, so no feedback. Consider this to be me nagging :-) On 21 June 2010 13:37, Stefan Bodewig bode...@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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: missing extension-point behaviour
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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: missing extension-point behaviour
Thanks Stefan. Anything I can do to assist? Cheers, Danny. On 21 June 2010 07:59, Stefan Bodewig bode...@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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: missing extension-point behaviour
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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
