You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Wolfgang Häfelinger <wh...@epo.org> on 2006/05/23 12:26:25 UTC
ComponentHelper replacement
Hi,
I'm heavily using <presetdef> to override/customize tasks. It annoys me
and users
of my framework to see messages like
Trying to override old definition of task junit
and so I had the idea to write my "own" ComponentHelper and to hook it in
via
reference "ant.ComponentHelper".
The idea is - theoretically - simple, just inherit from ComponentHelper
and override
method
updateDataTypeDefinition()
and get rid of this project.log() statement (which should be a verbose
message
after all).
In practice however I run into serious problems and I have no real clue
how to do
it:
- updateDataType() is private, so I need to change addTaskDefinition() as
well (
I really wonder why updateDataTypeDefinition() is private and not
protected).
- updateDataType() uses lot's of private variables and methods like
rebuildTaskClassDefinitions
antTypeTable
sameDefinition
project
invalidateCreatedTasks
and it appears that most of this private staff does not even have a
"read"
method.
Therfore customization by inheritance appears not to work.
In a second approach I copied ComponentHelper.java in my own package
structure,
added a couple of import statements, and finally got stuck because of
Task t = (Task) ref.get();
//being a weak ref, it may be null by this point
if (t != null) {
t.markInvalid(); // <= package access only
}
Ok, so do I need to put ComponentHelper.java in org.apache.tools.ant to
make javac
happy? This was then my third approach. I saved a copy of
ComponentHelper.java as
MyComponentHelper.java in "your" namespace and now I'm stuck because of
for (Iterator i = helper.checkedNamespaces.iterator(); i.hasNext();)
{
// ..
}
Here checkedNamespaces is private (again) and there's no way to access it.
Now for my final question (thanks for reading so far):
How do I ever have a chance to replace ComponentHelper with my own version
if
basically everything is "private" ?
And here's my proposal for Ant 1.6.6:
1. $ perl -pi -e 's,\sprivate\s, protected ,g' `find -name
\*.java`
2. provide at least a "getter" for each "non-public" attribute
Cheers,
Wolfgang.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ComponentHelper replacement
Posted by Steve Loughran <st...@apache.org>.
Wolfgang Ha"felinger wrote:
> Hey,
>
>>> Ant's purpose is as a build tools, not a Java library.
>
> Perhaps time to change. After all, there must be a reason why
> Maven's community is growing :-)
Ahh, we arent going to go there.
>>> <presetdef> is just syntactic sugar, and is better not used
>>> IMHO.
>
> I disagree. It's very cool. Almost as cool as "macrodef" which
> I really love.
They are good, but work best if you put stuff into new namespaces as
otherwise you are redefining default things. Just like in C++, this can
get you into trouble. Just like in C++, they do give you near unlimited
power.
Regarding private vs public, private stuff is primarily there to let the
team changing things without fear of breaking stuff. There is a general
assumption that public method calls should stay around, purely for
people using Ant programmatically.
If you can make a good case for something becoming public, it will get
changed, or the underlying cause of your problems may get fixed in some
other way.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ComponentHelper replacement
Posted by Wolfgang Häfelinger <wh...@epo.org>.
>> <scriptdef> lets you do this inline, though python's space rules make
>> the resulting XML files look a bit messy.
<scriptdef> is a feature I'm not particular happy with. It makes me depend
on specific languages
and features. My framework consists basically of macros build on top of
other macros or "native"
tasks (either standard Ant task or custom tasks implement by me).
So looking at my framework's XML code, I can hardly see any Java
dependencies with the
exception of <taskdef> (I can probably also get rid of it using a property
file).
Steve Loughran <st...@apache.org>
26-05-2006 15:29
Please respond to
"Ant Developers List" <de...@ant.apache.org>
To
Ant Developers List <de...@ant.apache.org>
cc
Subject
Re: ComponentHelper replacement
Wolfgang Häfelinger wrote:
>>>My preference is to improve Ant's API.
>
>
> I would like to see Ant evolving in such a way allowing
> me to implement a framework like Maven on top of it.
>
>
>>>So, the question is "can Ant evolve into a good Java API?"
>
>
> I have no doubt that it can be done, we just need to focus on
> it.
>
> However, why does it need to be a Java API? Let's just talk
> about a good API and treat Java as an implementation detail.
>
> I think it would be pretty cool to implement tasks (i.e. macros
> with a "native" implementation) in other languages as well (I
> would love to see Python supported).
<scriptdef> lets you do this inline, though python's space rules make
the resulting XML files look a bit messy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: ComponentHelper replacement
Posted by "Stephen McConnell (DPML)" <mc...@apache.org>.
> -----Original Message-----
> From: Steve Loughran [mailto:stevel@apache.org]
<snip/>
Apologies for the delay in responding (have been
swamped with moving house and the cup).
> > I think that part of the problem here is that Ant is
> > bootstrapping itself from nothing and as a
> > consequence we have an overly complex build file that does not
> > generate the information needed for rapid problem
> > identification/resolution by the non-committer community.
>
> that sounds like one of my comments. Programmatic use of ant
> is always secondary. Do we want to change that?
>
> If so, how?
>
> -split out libraries for execution, java exec, other misc
> things -complete programmatic use of ant without problems
I'm thinking along the lines of moving the ant codebase structure to
something that reflects a project codebase per jar file where each
project (a.k.a. ant-sub-project) would have its own build file,
clearly identified dependencies, testcases, and resulting artifacts.
Could this be a feasible post-1.7 objective?
Cheers, Steve.
--------------------------
Stephen McConnell
mailto:mcconnell@dpml.net
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ComponentHelper replacement
Posted by Steve Loughran <st...@apache.org>.
Stephen McConnell (DPML) wrote:
>
>
>
>>-----Original Message-----
>>From: Steve Loughran [mailto:stevel@apache.org]
>>Sent: Friday, 26 May 2006 10:59 PM
>>To: Ant Developers List
>>Subject: Re: ComponentHelper replacement
>>
>>Wolfgang Häfelinger wrote:
>>
>>>>>My preference is to improve Ant's API.
>>>
>>>
>>>I would like to see Ant evolving in such a way allowing me to
>>>implement a framework like Maven on top of it.
>
>
> I agree.
>
> IMO there are two views that could be addressed here:
>
> (a) build.xml integrity
> (b) the Ant implementation quality
>
> The first item (a) concerning build integrity is related to the integrity of
> the XML file parsed by Ant. I would like to see the build file evolve
> towards an XML schema compliant source which would suggest that there is a
> generic Ant schema with support for extended data types and task definition
> schemas. Validation of custom data and tasks at the XML Schema level would
> be a major improvement over the current status-quo through simple
> elimination of XML structural issues combined with pre-execution validation
> for custom tasks. Introduction of XML schema has build and runtime
> implications that would require evaluation of JDK version and XML API
> support. A worst-case scenario would be schema-enabled versus
> schema-unsupported distributions.
I'm sorry, I have to work with XSD as my day job. It's evil and wrong.
It's one of the primary causes of grief in the whole O/X mapping area,
and it is very hard to work with.
Only people with a formal CS background and experience in those
mathematical language models can begin to understand all of it, and even
then it doesnt make sense to most of them.
>
> A more immediate concern is validation of the Ant implementation - in
> particular, tests cases against the Ant distribution. An earlier thread
> raised by Subir Bhaumik on the subject of "Using Ant Programmatically" and
> the appearance of an NPE is an example of the type of problem that should
> not occur or at least should be easily replication within a junit or
> integration test. Looking into the subject of that thread its relatively
> easy to see that the scope of existing tests related to Taskdef are limited:
>
> public TaskdefsTest(String name) {
> super(name);
> }
>
> My immediate thoughts here are related to the process of Ant improvement.
> Subir's post as a minimum should be treated as a challenge - i.e.
> replication of the NPE in a testcase. Instead Subir was told to look at the
> source and figure this out for himself (which IMO is not equal to
> satisfactory process closure). I think that part of the problem here is that
> Ant is bootstrapping itself from nothing and as a consequence we have an
> overly complex build file that does not generate the information needed for
> rapid problem identification/resolution by the non-committer community.
that sounds like one of my comments. Programmatic use of ant is always
secondary. Do we want to change that? If so, how?
-split out libraries for execution, java exec, other misc things
-complete programmatic use of ant without problems
> In particular:
>
> (a) default bootstrapping scenario presumes user intervention
you mean the double step of bootstrap/build?
> (b) default build file exemplifies a bad-practices (mixing core with
> external dependent builds) resulting in a complex 67kB XML file
yes, its got a bit big.
> (c) no build metric (test case reports, etc.) for published
> distributions
>
> All of the above could be improved with some refactoring of:
>
> (a) the project structure
> (b) the build strategy
> (c) published metrics
>
> The build structure could be improved with the separation of core from
> extension projects (with the assumption that each extension project
> addresses the specific extension concern). In effect, each project could
> represent the build solution for each of the package Ant jar file included
> in the formal Ant distribution. With rationalization of build structure the
> build strategy could be significantly improved by using a released (bundled
> binary?) version of Ant as the build system - enabling a much more rigorous
> evaluation of the result (junit reports, coverage, etc.) with respect to the
> Ant core and specific extensions (without the user intervention
> prerequisite).
>
> Given the above - it could be reasonable to assume:
>
> (a) a complete Ant build without user intervention
we could write (and maintain) another .bat/.sh for this.
> (b) build metrics created as a part of the build process
reasonable.
> (c) publication content (apis, junit reports, checkstyle reports, etc.)
> generated as a part of formal distribution content
>
possible. Would be nice up on the web site as a proof of 'compliance'.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: ComponentHelper replacement
Posted by "Stephen McConnell (DPML)" <mc...@apache.org>.
> -----Original Message-----
> From: Steve Loughran [mailto:stevel@apache.org]
> Sent: Friday, 26 May 2006 10:59 PM
> To: Ant Developers List
> Subject: Re: ComponentHelper replacement
>
> Wolfgang Häfelinger wrote:
> >>>My preference is to improve Ant's API.
> >
> >
> > I would like to see Ant evolving in such a way allowing me to
> > implement a framework like Maven on top of it.
I agree.
IMO there are two views that could be addressed here:
(a) build.xml integrity
(b) the Ant implementation quality
The first item (a) concerning build integrity is related to the integrity of
the XML file parsed by Ant. I would like to see the build file evolve
towards an XML schema compliant source which would suggest that there is a
generic Ant schema with support for extended data types and task definition
schemas. Validation of custom data and tasks at the XML Schema level would
be a major improvement over the current status-quo through simple
elimination of XML structural issues combined with pre-execution validation
for custom tasks. Introduction of XML schema has build and runtime
implications that would require evaluation of JDK version and XML API
support. A worst-case scenario would be schema-enabled versus
schema-unsupported distributions.
A more immediate concern is validation of the Ant implementation - in
particular, tests cases against the Ant distribution. An earlier thread
raised by Subir Bhaumik on the subject of "Using Ant Programmatically" and
the appearance of an NPE is an example of the type of problem that should
not occur or at least should be easily replication within a junit or
integration test. Looking into the subject of that thread its relatively
easy to see that the scope of existing tests related to Taskdef are limited:
public TaskdefsTest(String name) {
super(name);
}
My immediate thoughts here are related to the process of Ant improvement.
Subir's post as a minimum should be treated as a challenge - i.e.
replication of the NPE in a testcase. Instead Subir was told to look at the
source and figure this out for himself (which IMO is not equal to
satisfactory process closure). I think that part of the problem here is that
Ant is bootstrapping itself from nothing and as a consequence we have an
overly complex build file that does not generate the information needed for
rapid problem identification/resolution by the non-committer community.
In particular:
(a) default bootstrapping scenario presumes user intervention
(b) default build file exemplifies a bad-practices (mixing core with
external dependent builds) resulting in a complex 67kB XML file
(c) no build metric (test case reports, etc.) for published
distributions
All of the above could be improved with some refactoring of:
(a) the project structure
(b) the build strategy
(c) published metrics
The build structure could be improved with the separation of core from
extension projects (with the assumption that each extension project
addresses the specific extension concern). In effect, each project could
represent the build solution for each of the package Ant jar file included
in the formal Ant distribution. With rationalization of build structure the
build strategy could be significantly improved by using a released (bundled
binary?) version of Ant as the build system - enabling a much more rigorous
evaluation of the result (junit reports, coverage, etc.) with respect to the
Ant core and specific extensions (without the user intervention
prerequisite).
Given the above - it could be reasonable to assume:
(a) a complete Ant build without user intervention
(b) build metrics created as a part of the build process
(c) publication content (apis, junit reports, checkstyle reports, etc.)
generated as a part of formal distribution content
Cheers, Steve.
--------------------------
Stephen McConnell
mailto:mcconnell@dpml.net
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ComponentHelper replacement
Posted by Steve Loughran <st...@apache.org>.
Wolfgang Häfelinger wrote:
>>>My preference is to improve Ant's API.
>
>
> I would like to see Ant evolving in such a way allowing
> me to implement a framework like Maven on top of it.
>
>
>>>So, the question is "can Ant evolve into a good Java API?"
>
>
> I have no doubt that it can be done, we just need to focus on
> it.
>
> However, why does it need to be a Java API? Let's just talk
> about a good API and treat Java as an implementation detail.
>
> I think it would be pretty cool to implement tasks (i.e. macros
> with a "native" implementation) in other languages as well (I
> would love to see Python supported).
<scriptdef> lets you do this inline, though python's space rules make
the resulting XML files look a bit messy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: ComponentHelper replacement
Posted by Jeffrey E Care <ca...@us.ibm.com>.
Wolfgang Häfelinger <wh...@epo.org> wrote on 05/26/2006 04:49:05
AM:
> >> My preference is to improve Ant's API.
>
> I would like to see Ant evolving in such a way allowing
> me to implement a framework like Maven on top of it.
Like Maven in what way?
At IBM we've built a vast set of Ant extensions that provide many of the
same concepts that Maven provides, and managed to do it using the Ant APIs
as they are. What is lacking that you need?
> I think it would be pretty cool to implement tasks (i.e. macros
> with a "native" implementation) in other languages as well (I
> would love to see Python supported).
IIRC <scriptdef> will let you implement tasks in any language BSF allows.
____________________________________________________________________________________________
Jeffrey E. (Jeff) Care
carej@us.ibm.com
IBM WebSphere Application Server Development
WAS Pyxis Lead Release Engineer
RE: ComponentHelper replacement
Posted by Wolfgang Häfelinger <wh...@epo.org>.
>> My preference is to improve Ant's API.
I would like to see Ant evolving in such a way allowing
me to implement a framework like Maven on top of it.
>> So, the question is "can Ant evolve into a good Java API?"
I have no doubt that it can be done, we just need to focus on
it.
However, why does it need to be a Java API? Let's just talk
about a good API and treat Java as an implementation detail.
I think it would be pretty cool to implement tasks (i.e. macros
with a "native" implementation) in other languages as well (I
would love to see Python supported).
Cheers,
Wolfgang.
"Stephen McConnell (DPML)" <mc...@apache.org>
23-05-2006 21:10
Please respond to
"Ant Developers List" <de...@ant.apache.org>
To
"'Ant Developers List'" <de...@ant.apache.org>
cc
Subject
RE: ComponentHelper replacement
> -----Original Message-----
> From: Dominique Devienne [mailto:ddevienne@gmail.com]
> Sent: Wednesday, 24 May 2006 4:16 AM
> To: Ant Developers List
> Subject: Re: ComponentHelper replacement
>
> > However, it is possible to isolate Ant idiosyncrasies as an
> > implementation concern providing one can establish a viable project
> > model.
>
> I've long thought Ant needed a more rigorous model exposed to
> Java clients and extension builders. However, I don't think
> what I had in mind was quite as ambitious as what you
> describe. It's not easy to evolve Ant in such a way, and
> attempts at starting from scratch failed
> (Ant: myrmidon and mutant), not from lack of quality, but
> from lack of community support.
>
> Maven (1 or 2) may indeed be closer to your thinking.
Close? Maybe.
The solution? No.
IMO Maven is too focussed on build time concerns (as opposed to the
overall
runtime management subject). In effect Maven's underlying framework does
not
fold easily into deployment and runtime solutions (which is at the end of
the day the product of a build). In addition there are simple pragmatic
issues that Maven does not fulfil. My point is that Ant as an API needs
to
evolve and its evolution should be driven by API users. It's not a
question
of Maven - Maven does not deliver what I need - I can build systems on Ant
that deliver better solutions than Maven but in doing so, there are issues
in the Ant API.
My preference is to improve Ant's API.
>
> > I.e. perhaps Dominique's suggestion on the money?
>
> You meant Wolfgang, no? ;-) --DD
LOL - Yes.
However - it raises an interesting question:
>Dominique wrote:
> Ant's purpose is as a build tools, not a Java library.
So, the question is "can Ant evolve into a good Java API?"
If the answer is YES - in your opinion .. how?
If the answer is NO - in your opinion .. why not?
Cheers, Steve.
--------------------------
Stephen McConnell
mailto:mcconnell@dpml.net
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: ComponentHelper replacement
Posted by "Stephen McConnell (DPML)" <mc...@apache.org>.
> -----Original Message-----
> From: Dominique Devienne [mailto:ddevienne@gmail.com]
> Sent: Wednesday, 24 May 2006 4:16 AM
> To: Ant Developers List
> Subject: Re: ComponentHelper replacement
>
> > However, it is possible to isolate Ant idiosyncrasies as an
> > implementation concern providing one can establish a viable project
> > model.
>
> I've long thought Ant needed a more rigorous model exposed to
> Java clients and extension builders. However, I don't think
> what I had in mind was quite as ambitious as what you
> describe. It's not easy to evolve Ant in such a way, and
> attempts at starting from scratch failed
> (Ant: myrmidon and mutant), not from lack of quality, but
> from lack of community support.
>
> Maven (1 or 2) may indeed be closer to your thinking.
Close? Maybe.
The solution? No.
IMO Maven is too focussed on build time concerns (as opposed to the overall
runtime management subject). In effect Maven's underlying framework does not
fold easily into deployment and runtime solutions (which is at the end of
the day the product of a build). In addition there are simple pragmatic
issues that Maven does not fulfil. My point is that Ant as an API needs to
evolve and its evolution should be driven by API users. It's not a question
of Maven - Maven does not deliver what I need - I can build systems on Ant
that deliver better solutions than Maven but in doing so, there are issues
in the Ant API.
My preference is to improve Ant's API.
>
> > I.e. perhaps Dominique's suggestion on the money?
>
> You meant Wolfgang, no? ;-) --DD
LOL - Yes.
However - it raises an interesting question:
>Dominique wrote:
> Ant's purpose is as a build tools, not a Java library.
So, the question is "can Ant evolve into a good Java API?"
If the answer is YES - in your opinion .. how?
If the answer is NO - in your opinion .. why not?
Cheers, Steve.
--------------------------
Stephen McConnell
mailto:mcconnell@dpml.net
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ComponentHelper replacement
Posted by Dominique Devienne <dd...@gmail.com>.
> However, it is possible to isolate Ant
> idiosyncrasies as an implementation concern providing one can establish a
> viable project model.
I've long thought Ant needed a more rigorous model exposed to Java
clients and extension builders. However, I don't think what I had in
mind was quite as ambitious as what you describe. It's not easy to
evolve Ant in such a way, and attempts at starting from scratch failed
(Ant: myrmidon and mutant), not from lack of quality, but from lack of
community support.
Maven (1 or 2) may indeed be closer to your thinking.
> I.e. perhaps Dominique's suggestion on the money?
You meant Wolfgang, no? ;-) --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: ComponentHelper replacement
Posted by Steve <mc...@apache.org>.
Wolfgang Häfelinger wrote:
> Dominique Devienne wrote:
> > Ant's purpose is as a build tools, not a Java library.
>
> Perhaps time to change.
It seems to me that a primary objective of the Ant community has been to
focus on the build file XML integrity over and above API integrity. If you
take the next step and attempt an abstract above the Ant API - e.g. a model
for a buildable project using ant as the build implementation - then Ant (as
a library dependency) is brittle. However, it is possible to isolate Ant
idiosyncrasies as an implementation concern providing one can establish a
viable project model.
A viable project model introduces the following concerns:
(a) resource management
(b) dependency management
(c) project layout
(d) build execution
None of the above are trivial concerns. A resource management framework is
needed to address general resource of dependencies (jars, preference data,
deployment info, etc.) in a secure manner (where 'secure' can be asserted as
a system configuration concern -- i.e. it's not a case of saying that
something is signed or not - it's about enabling a controlled environment).
A dependency management model is needed to ensure integrity with respect to
the resources used and consumed by hundreds of projects with respect to
build, runtime and test phase dependecies. The ability to construct and
manage project layouts is needed in order to support general simplification
of build procedures by adding an abstraction between physical file system
locations (dirs and files) from the tasks that deliver the ultimate value in
build process. A build execution model is needed in order to create the
framework for generic processors that can extend/enhance common build
procedures without resorting to references to task names or local path
definitions.
IMO - the above subjects are priority drivers for the evolution of the Ant
API. In particular, these priorities focus attention on the following Ant
extension points:
(a) ProjectHelper
(b) ComponentHelper
(c) PropertyHelper
As a general comment I've found these classes difficult to deal with and the
supporting documentation limited. My impression is that the codebase has
evolved with the intention of supporting third-party extension however in
practice my earlier comment concerning "brittle" comes to mind. Given the
solutions out there I prefer Ant probably because of the working 'primary
objective' mentioned above -- however, I do believe that the community
dealing with Ant as a library needs to step up a take an assertive role in
the future direction of this project.
I.e. perhaps Dominique's suggestion on the money?
Cheers, Steve.
--------------------------
Stephen McConnell
mailto:mcconnell@dpml.net
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ComponentHelper replacement
Posted by Wolfgang Häfelinger <wh...@epo.org>.
Hey,
>> Ant's purpose is as a build tools, not a Java library.
Perhaps time to change. After all, there must be a reason why
Maven's community is growing :-)
>> <presetdef> is just syntactic sugar, and is better not used
>> IMHO.
I disagree. It's very cool. Almost as cool as "macrodef" which
I really love.
Cheers,
Wolfgang.
"Dominique Devienne" <dd...@gmail.com>
23-05-2006 14:53
Please respond to
"Ant Developers List" <de...@ant.apache.org>
To
"Ant Developers List" <de...@ant.apache.org>
cc
Subject
Re: ComponentHelper replacement
> Still the overall problem I have with customizing Ant is the over-usage
of
> "private". It also bites at other places, ComponentHelper is just an
example.
On the contrary, it's a Good Thing (TM)
Ant's purpose is as a build tools, not a Java library. Keeping its
internals private allows future refactoring which do not break BC, or
minimize BC issues. It's a lot easier to open up an API here and
there, when there's a good case for it, rather than leaving everything
"protected" or public.
<presetdef> is just syntactic sugar, and is better not used IMHO. But
if you persist on wanting to overuse it, concentrate your energy on
simply adding an attribute to presetdef to ignore overrides (with all
that entails), and provide a patch.
Or better yet, use a my- prefix for your presets, so as not to confuse
people with tasks that look like plain Ant tasks, but don't behave the
same because their defaults have been changed. This is most likely a
maintenance issue, and a violation of the "principle of least
surprise".
Good luck. I'll get down from my soap box now ;-) --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ComponentHelper replacement
Posted by Dominique Devienne <dd...@gmail.com>.
> Still the overall problem I have with customizing Ant is the over-usage of
> "private". It also bites at other places, ComponentHelper is just an example.
On the contrary, it's a Good Thing (TM)
Ant's purpose is as a build tools, not a Java library. Keeping its
internals private allows future refactoring which do not break BC, or
minimize BC issues. It's a lot easier to open up an API here and
there, when there's a good case for it, rather than leaving everything
"protected" or public.
<presetdef> is just syntactic sugar, and is better not used IMHO. But
if you persist on wanting to overuse it, concentrate your energy on
simply adding an attribute to presetdef to ignore overrides (with all
that entails), and provide a patch.
Or better yet, use a my- prefix for your presets, so as not to confuse
people with tasks that look like plain Ant tasks, but don't behave the
same because their defaults have been changed. This is most likely a
maintenance issue, and a violation of the "principle of least
surprise".
Good luck. I'll get down from my soap box now ;-) --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ComponentHelper replacement
Posted by Wolfgang Häfelinger <wh...@epo.org>.
Hi Kev,
> If this is the problem that you and your users are facing, perhaps it
> would be a better solution to provide a way to suppress these
> messages instead of rewriting ComponentHelper et al.
Is there are nice way to customize output suppressing?
Still the overall problem I have with customizing Ant is the over-usage of
"private". It also bites
at other places, ComponentHelper is just an example.
Cheers,
Wolfgang.
Kev Jackson <fo...@gmail.com>
23-05-2006 13:23
Please respond to
"Ant Developers List" <de...@ant.apache.org>
To
"Ant Developers List" <de...@ant.apache.org>
cc
Subject
Re: ComponentHelper replacement
On 23 May 2006, at 17:26, Wolfgang Häfelinger wrote:
> Hi,
>
> I'm heavily using <presetdef> to override/customize tasks. It
> annoys me
> and users
> of my framework to see messages like
>
> Trying to override old definition of task junit
>
ignoring the rest of your message for now - your main problem seems
to be that you're getting too much info dumped to System.out. Is
that the main problem?
If this is the problem that you and your users are facing, perhaps it
would be a better solution to provide a way to suppress these
messages instead of rewriting ComponentHelper et al.
Thanks
Kev
--
"Society in every state is a blessing, but government even in its
best state is but a necessary evil; in it's worst state an
intolerable one" - Thomas Paine
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ComponentHelper replacement
Posted by Kev Jackson <fo...@gmail.com>.
On 23 May 2006, at 17:26, Wolfgang Häfelinger wrote:
> Hi,
>
> I'm heavily using <presetdef> to override/customize tasks. It
> annoys me
> and users
> of my framework to see messages like
>
> Trying to override old definition of task junit
>
ignoring the rest of your message for now - your main problem seems
to be that you're getting too much info dumped to System.out. Is
that the main problem?
If this is the problem that you and your users are facing, perhaps it
would be a better solution to provide a way to suppress these
messages instead of rewriting ComponentHelper et al.
Thanks
Kev
--
"Society in every state is a blessing, but government even in its
best state is but a necessary evil; in it's worst state an
intolerable one" - Thomas Paine
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org