[embed] few changes in xml processing

[Costin Manolache <cm...@yahoo.com>]

I finally got everything to work with gump - and it seems
to be as good as the official run, so I'll start checking
in the changes.

There are few things:
1. ProjectComponentFactory / ProjectComponentHelper. Nothing fancy,
I intend to propose them for the main branch after more review. The
default is to call Project for unknown types - so everything that works
now will work the same, however any 'antlib' variant could be hooked
in ( including in ant1.5 )

2. An experimental TaskDiscovery that uses this hook and commons-discovery.
That's just for testing the concepts, will likely be changed/removed.

3. ProjectHelper: all project components will be lazy-loaded, via 
UnknownElement(2). Until now, some components were created imediately,
some were lazy ( those without <taskdef> ). The problem is that this
adds complexity to the parsing code - and has logic that shouldn't 
be there. A more uniform processing will simplify the programatic use
of ant - which is one of the goals of embed. 
I'll continue testing and hopefully remove the last special cases
( as long as it doesn't brake anything - and it shouldn't, since
the 'lazy' case was there already, only that it happened less often). 

4. I added ${} processing to text body. I hate <echo>${prop}</echo>
behaving differently from <echo message="${prop}"/>. I don't know
if this will ever get into the main branch, but I intend to keep it
in the proposal for a while, maybe I can convince people.

5. Split the compilation of 'core' components and those depending
on jxpat/velocity/etc.

6. implemented JxPath set task - just for fun.

I'm also trying to get JNDI dynamic properties and support a form
of ant:env context - that will provide a jndi interface into ant
properties and references ( and tasks and targets - later ), allowing
more power to tasks that do not extend Task but use TaskAdapter.


-- 
Costin



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [embed] few changes in xml processing

[Stephane Bailliez <sb...@apache.org>]

----- Original Message -----
From: "Steve Loughran" <st...@iseran.com>
> > 4. I added ${} processing to text body. I hate <echo>${prop}</echo>
> > behaving differently from <echo message="${prop}"/>. I don't know
> > if this will ever get into the main branch, but I intend to keep it
> > in the proposal for a while, maybe I can convince people.
>
> I woorry about tasks that explicitly expect the conversion not to catch,
> things like SQL, maybe. It could be all those tasks that dont expand
> properties do so by accident of course.

I think there is a bug/patch hanging around in bugzilla to enable property
processing in SQLExec
I really need to sit down and do my homework in Ant to fix bugs but I have
many things to do and this should not improve in the next weeks. (At least I
hope so for some reasons)

Stephane




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [embed] few changes in xml processing

[Costin Manolache <cm...@yahoo.com>]

Stefan Bodewig wrote:

> On Mon, 14 Oct 2002, Costin Manolache <cm...@yahoo.com> wrote:
> 
>> I think I found the real problem - Echo is calling
>> Project.replaceProperties() in addText(), but since properties
>> are evaluated later this will fail.
> 
> Hmm?

Sorry, I was talking about embed, the main branch is fine on this.

It was import that gave me problems - and it still does. It
'imports' the file at the end of the init target, and any 
property setting will happens there. If I add an echo after 
import it won't see the changes.

I'm trying to find a fix, it is clear that I was looking in 
the very wrong place.

Costin



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [embed] few changes in xml processing

[Stefan Bodewig <bo...@apache.org>]

On Mon, 14 Oct 2002, Costin Manolache <cm...@yahoo.com> wrote:

> I think I found the real problem - Echo is calling 
> Project.replaceProperties() in addText(), but since properties
> are evaluated later this will fail.

Hmm?

[bodewig@bodewig jakarta-ant]$ cat > /tmp/echo.xml
<project default="foo">
  <target name="foo">
    <property name="bar" value="baz"/>
    <echo>${bar}</echo>
  </target>
</project>
[bodewig@bodewig jakarta-ant]$ ant -f /tmp/echo.xml 
Buildfile: /tmp/echo.xml

foo:
     [echo] baz

BUILD SUCCESSFUL
Total time: 1 second

what is the problem?  This works with Ant 1.5.1 and CVS HEAD.

The problem is the load of tasks that do not expand properties
themselves - or taken the other way around, that IntrospectionHelper
hasn't done so to begin with.

Stefan

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [embed] few changes in xml processing

[Costin Manolache <cm...@yahoo.com>]

Steve Loughran wrote:

>> 4. I added ${} processing to text body. I hate <echo>${prop}</echo>
>> behaving differently from <echo message="${prop}"/>. I don't know
>> if this will ever get into the main branch, but I intend to keep it
>> in the proposal for a while, maybe I can convince people.
> 
> I woorry about tasks that explicitly expect the conversion not to catch,
> things like SQL, maybe. It could be all those tasks that dont expand
> properties do so by accident of course.

> 
> But if we do fix the behaviour, then any third party task that calls
> expandProperties() on the element text, after it has already been
> expanded, may break...if you double escape $${something} then the first
> pass will convert it to ${something}, the second expansion to the contents
> of "something"
> 
> Perhaps the trick is to have a new setter, setExpandedText(String text) to
> do the right thing.

You're probably right. 

I think I found the real problem - Echo is calling 
Project.replaceProperties() in addText(), but since properties
are evaluated later this will fail.

So the change will no longer be necesary, since the other change
( all-lazy ) will solve this problem.

Thanks.

-- 
Costin



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [embed] few changes in xml processing

[Steve Loughran <st...@iseran.com>]

----- Original Message -----
From: "Costin Manolache" <cm...@yahoo.com>
To: <an...@jakarta.apache.org>
Sent: Thursday, October 10, 2002 2:28 PM
Subject: [embed] few changes in xml processing


> I finally got everything to work with gump - and it seems
> to be as good as the official run, so I'll start checking
> in the changes.

if I ever get the chance, I need to sit down and look at all this

> 4. I added ${} processing to text body. I hate <echo>${prop}</echo>
> behaving differently from <echo message="${prop}"/>. I don't know
> if this will ever get into the main branch, but I intend to keep it
> in the proposal for a while, maybe I can convince people.

I woorry about tasks that explicitly expect the conversion not to catch,
things like SQL, maybe. It could be all those tasks that dont expand
properties do so by accident of course.

But if we do fix the behaviour, then any third party task that calls
expandProperties() on the element text, after it has already been expanded,
may break...if you double escape $${something} then the first pass will
convert it to ${something}, the second expansion to the contents of
"something"

Perhaps the trick is to have a new setter, setExpandedText(String text) to
do the right thing.



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>