You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by co...@covalent.net on 2002/03/01 02:05:14 UTC
Re: ClassLoaders ( was: Re: We need to stop the lies)
On Fri, 1 Mar 2002, Peter Donald wrote:
> > Well, given your ( completely unjustified IMHO, but unfortunately
> > seconded by another commiter, so validated ) -1 on the TaskAdapter
> > improvements I'm not very inclined to get anything in - what can be
> > implemented as a task can be kept outside without any problem
> > and interference. I strongly believe we already have too many
> > tasks in ant, and grouping them in libraries is better.
> >
> > I'm focusing on adding the hooks I need and making the core
> > changes only.
>
> You don't need any changes to ants core tasks to implement the functionality.
> You could quite easily go to commons and implement it over there against
> ant1.4.1
The hooks are not only for that particular change - they solve few
big problems in ant - it allows Tasks to be created by a factory that
can control the loader, allow an alternative Project helper to
be plugged in ( i.e. XML2 support, other extensions ), allow more
flexibility in creating adapters.
> Given how unlikely it is that your changes will be accepted into the main
> tree I would recomend that as the best path forward.
Well, I think the changes are solving a real problem in Ant1,
and I see no reason to not have them accpted.
If you have a valid reason to -1 any of the changes and a second
commiter will agree with you - I'll try to work around and find
a better solutions.
Jose Alberto is the only reason for giving up on extending TaskAdapter,
since I don't believe your argument is valid. But the rule
is there, if a second commiter believes the same, it's valid.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ClassLoaders ( was: Re: We need to stop the lies)
Posted by co...@covalent.net.
On Fri, 1 Mar 2002, Peter Donald wrote:
> The ClassLoader is however a completely different beastie and until it is
> thouroughly tested shouldn't be anywhere near ants core - especially as it
> doesn't need to be. If it turns out to be a good idea we can always
> incorporate it later.
I'm not touching ClassLoaders in any way with the hooks - the task
( actually, ProjectComponent ) creation will be 'hooked'.
If someone writes a Task that 'plugs' a different factory that
can use a different loader policy - that's great, but it doesn't
have to be included in ant unless everyone agrees.
The current mechansim:
- addTaskDefinition( String name, Class c)
- createTask(): c.newInstance()
It will remain the default, however it will be possible to register
a ProjectComponentHelper, with a simple:
createProjectComponent( Project p, String role, String ns, String name);
The createTask will first call any factory - and the factory has full
freedom in doing anything it wants to create the loader.
> > > Given how unlikely it is that your changes will be accepted into the main
> > > tree I would recomend that as the best path forward.
> >
> > Well, I think the changes are solving a real problem in Ant1,
> > and I see no reason to not have them accpted.
>
> But you are unlikely to stick around to maintain ant.
Well, as likely (or unlikely ) as anyone else around here.
Now that tomcat3.3 is completed I have some free time - and
some ideas.
> > If you have a valid reason to -1 any of the changes and a second
> > commiter will agree with you - I'll try to work around and find
> > a better solutions.
>
> Thats going to be the only real solution for you I suspect.
I'll do what I have to do.
( assuming you'll have a second -1 and good arguments to block
improvements in task registration/creation )
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ClassLoaders ( was: Re: We need to stop the lies)
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
Jose Alberto Fernandez wrote:
>
> This is fine. But still, the main drive of my question stands:
>
> For people that are proposing alternative syntax for ANT, how
> would they tell a basic task like <ant> to use a different parser?
Well, I think the contract of the <ant> task is to process an XML based
build file. If someone wants to proces a different syntax, they need to
either provide their own version of <ant> or augment <ant> to support
different buildfile types.
>
> Would they have to provide their own <ant> implementation and
> replace the default <ant>?
Yes, they could do that.
>
> If an IDE constructs a model on the fly (no XML file) how can <antcall>
> work (have you change the implementation?) since it only calls <ant>.
Of course I changed the implementation since I did not want to reparse a
model that has already been parsed. This is the mutant implementation of
<antcall>
public void callTarget(Map properties, List targets)
throws ExecutionException {
runBuild(frame.getProject(), properties, targets);
}
Since the project model just represents the buildfile in mutant, this is
easy to do - there is no execution context info stored in the project model.
>
> This is where I kind of get puzzled on how worth is allowing IDEs to
> pass their own pre-build model. It seems to me you will need the written
> XML for any real build, and if that is the case then we should really define
> the interface to be the XML and not the Project instance.
I disagree.
Conor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ClassLoaders ( was: Re: We need to stop the lies)
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
From: "Conor MacNeill" <co...@cortexebusiness.com.au>
> Jose Alberto Fernandez wrote:
>
> > How does Mutant implement <ant>?
> >
> > Is it consider part of the core or not? I guess this is the point where
> > I always have dificulty with proposals on having different syntax
> > for project files. How does the <ant> task knows what syntax to parse?
> >
> > Jose Alberto
> >
>
>
> Jose Alberto,
>
> Good question. Mutant provides two core services for running sub-builds
>
> void runBuild(File antFile, Map properties, List targets)
> throws ExecutionException;
>
>
> void runBuild(Project model, Map properties, List targets)
> throws ExecutionException;
>
>
> The first is for processing XML build files. The mutant core does
> provide support for the parsing of XML build files. In the second, the
> task requesting the subbuild can provide its own Project model
> constructed in some other way. The first version is implemented by
> converting the XML version to a Project model and then calling the
> second version.
>
> XMLProjectParser parser = new XMLProjectParser();
> Project project
> = parser.parseBuildFile(InitUtils.getFileURL(antFile));
> runBuild(project, properties, targets);
>
> So the implementation of <ant> uses the first.
>
> While the core provides the XML parsing service, it is decoupled from
> the rest of the core.
This is fine. But still, the main drive of my question stands:
For people that are proposing alternative syntax for ANT, how
would they tell a basic task like <ant> to use a different parser?
Would they have to provide their own <ant> implementation and
replace the default <ant>?
If an IDE constructs a model on the fly (no XML file) how can <antcall>
work (have you change the implementation?) since it only calls <ant>.
This is where I kind of get puzzled on how worth is allowing IDEs to
pass their own pre-build model. It seems to me you will need the written
XML for any real build, and if that is the case then we should really define
the interface to be the XML and not the Project instance.
Jose Alberto
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ClassLoaders ( was: Re: We need to stop the lies)
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
Jose Alberto Fernandez wrote:
> How does Mutant implement <ant>?
>
> Is it consider part of the core or not? I guess this is the point where
> I always have dificulty with proposals on having different syntax
> for project files. How does the <ant> task knows what syntax to parse?
>
> Jose Alberto
>
Jose Alberto,
Good question. Mutant provides two core services for running sub-builds
void runBuild(File antFile, Map properties, List targets)
throws ExecutionException;
void runBuild(Project model, Map properties, List targets)
throws ExecutionException;
The first is for processing XML build files. The mutant core does
provide support for the parsing of XML build files. In the second, the
task requesting the subbuild can provide its own Project model
constructed in some other way. The first version is implemented by
converting the XML version to a Project model and then calling the
second version.
XMLProjectParser parser = new XMLProjectParser();
Project project
= parser.parseBuildFile(InitUtils.getFileURL(antFile));
runBuild(project, properties, targets);
So the implementation of <ant> uses the first.
While the core provides the XML parsing service, it is decoupled from
the rest of the core.
Conor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ClassLoaders ( was: Re: We need to stop the lies)
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
How does Mutant implement <ant>?
Is it consider part of the core or not? I guess this is the point where
I always have dificulty with proposals on having different syntax
for project files. How does the <ant> task knows what syntax to parse?
Jose Alberto
----- Original Message -----
From: "Conor MacNeill" <co...@cortexebusiness.com.au>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Friday, March 01, 2002 4:51 AM
Subject: RE: ClassLoaders ( was: Re: We need to stop the lies)
> From: Peter Donald [mailto:peter@apache.org]
>
> Costin has proposed changes to ProjectHelper that are mostly
> equivelent to
> the ProjectBuilder abstraction I proposed. Basically a mechanism
> to to have
> alternative strategys to build project objects. At one stage you
> objected to
> ProjectBuilder abstraction back ages ago. Though from your
> comments recently
> I don't think your objections still hold ?
>
OK, I see what you are getting at. In mutant the core doesn't really care how project models are constructed. What interests the core is the model itself. The core expects to be given the model from the front-end code. How the front end built the model is not really relevant to how the core processes the model. Since the core never requests "building" of the project model, there is currently no need for the abstraction in mutant.
How do you use the abstraction in myrmidon?
Conor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ClassLoaders ( was: Re: We need to stop the lies)
Posted by Peter Donald <pe...@apache.org>.
On Fri, 1 Mar 2002 15:51, Conor MacNeill wrote:
> > From: Peter Donald [mailto:peter@apache.org]
> >
> > Costin has proposed changes to ProjectHelper that are mostly
> > equivelent to
> > the ProjectBuilder abstraction I proposed. Basically a mechanism
> > to to have
> > alternative strategys to build project objects. At one stage you
> > objected to
> > ProjectBuilder abstraction back ages ago. Though from your
> > comments recently
> > I don't think your objections still hold ?
>
> OK, I see what you are getting at. In mutant the core doesn't really care
> how project models are constructed. What interests the core is the model
> itself. The core expects to be given the model from the front-end code. How
> the front end built the model is not really relevant to how the core
> processes the model. Since the core never requests "building" of the
> project model, there is currently no need for the abstraction in mutant.
>
> How do you use the abstraction in myrmidon?
Similar but with an extra layer essentially. The actual runtime doesn't care
how Project is constructed and that has little effect on how it is processed.
Myrmidon however has an extra layer between frontend and the engine - namely
the Embeddor.
The Embeddor was designed to make it easy to embed ant into other productsa
with minimal of fuss. Basically it is a simple facade that makes embedding
easier. One of the methods it supports looks something like
Project buildProject( String location,
String builderType,
Parameters buildParams );
This will then use BuilderType and buildParams to go look up a ProjectBuilder
(by default it uses standard File/URL based builder) and then build project
from specified location. You can still build it manually if needed but in
most cases you want to build it from a resource.
--
Cheers,
Pete
*-------------------------------------*
| Does the name `Pavlov' ring a bell? |
*-------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ClassLoaders ( was: Re: We need to stop the lies)
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
> From: Peter Donald [mailto:peter@apache.org]
>
> Costin has proposed changes to ProjectHelper that are mostly
> equivelent to
> the ProjectBuilder abstraction I proposed. Basically a mechanism
> to to have
> alternative strategys to build project objects. At one stage you
> objected to
> ProjectBuilder abstraction back ages ago. Though from your
> comments recently
> I don't think your objections still hold ?
>
OK, I see what you are getting at. In mutant the core doesn't really care how project models are constructed. What interests the core is the model itself. The core expects to be given the model from the front-end code. How the front end built the model is not really relevant to how the core processes the model. Since the core never requests "building" of the project model, there is currently no need for the abstraction in mutant.
How do you use the abstraction in myrmidon?
Conor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ClassLoaders ( was: Re: We need to stop the lies)
Posted by Peter Donald <pe...@apache.org>.
On Fri, 1 Mar 2002 13:54, Conor MacNeill wrote:
> > From: Peter Donald [mailto:peter@apache.org]
> >
> > I don't think the ProjectHelper changes will cause any problems.
> > The only one
> > who has ever expressed doubts over that style is Conor and I
> > believe he has
> > changed his mind.
>
> Not sure to what you are referring. Can you explain?
Costin has proposed changes to ProjectHelper that are mostly equivelent to
the ProjectBuilder abstraction I proposed. Basically a mechanism to to have
alternative strategys to build project objects. At one stage you objected to
ProjectBuilder abstraction back ages ago. Though from your comments recently
I don't think your objections still hold ?
--
Cheers,
Pete
*------------------------------------------------*
| You can't wake a person who is pretending |
| to be asleep. -Navajo Proverb. |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ClassLoaders ( was: Re: We need to stop the lies)
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
> From: Peter Donald [mailto:peter@apache.org]
>
> I don't think the ProjectHelper changes will cause any problems.
> The only one
> who has ever expressed doubts over that style is Conor and I
> believe he has
> changed his mind.
>
Not sure to what you are referring. Can you explain?
Conor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ClassLoaders ( was: Re: We need to stop the lies)
Posted by Peter Donald <pe...@apache.org>.
On Fri, 1 Mar 2002 12:05, costinm@covalent.net wrote:
> > You don't need any changes to ants core tasks to implement the
> > functionality. You could quite easily go to commons and implement it over
> > there against ant1.4.1
>
> The hooks are not only for that particular change - they solve few
> big problems in ant - it allows Tasks to be created by a factory that
> can control the loader, allow an alternative Project helper to
> be plugged in ( i.e. XML2 support, other extensions ), allow more
> flexibility in creating adapters.
I don't think the ProjectHelper changes will cause any problems. The only one
who has ever expressed doubts over that style is Conor and I believe he has
changed his mind.
The ClassLoader is however a completely different beastie and until it is
thouroughly tested shouldn't be anywhere near ants core - especially as it
doesn't need to be. If it turns out to be a good idea we can always
incorporate it later.
> > Given how unlikely it is that your changes will be accepted into the main
> > tree I would recomend that as the best path forward.
>
> Well, I think the changes are solving a real problem in Ant1,
> and I see no reason to not have them accpted.
But you are unlikely to stick around to maintain ant.
> If you have a valid reason to -1 any of the changes and a second
> commiter will agree with you - I'll try to work around and find
> a better solutions.
Thats going to be the only real solution for you I suspect.
> Jose Alberto is the only reason for giving up on extending TaskAdapter,
> since I don't believe your argument is valid. But the rule
> is there, if a second commiter believes the same, it's valid.
Jose is not a committer as such. Feel free to wail.
--
Cheers,
Pete
"The perfect way is only difficult for those who pick and choose. Do not
like, do not dislike; all will then be clear. Make a hairbreadth
difference and heaven and earth are set apart; if you want the truth to
stand clear before you, never be for or against." - Bruce Lee
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>