You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Geoff Howard <ge...@leverageweb.com> on 2003/03/30 15:24:07 UTC
src/targets xml fragments
Is there any strategy for making the xml fragments in
src/targets well-formed so editors don't barf on them?
Geoff
Re: src/targets xml fragments
Posted by Joerg Heinicke <jo...@gmx.de>.
Bertrand Delacretaz wrote:
> Le Vendredi, 27 juin 2003, à 15:52 Europe/Zurich, Geoff Howard a écrit :
>
>> Joerg, David and I are discussing alternatives to the current
>> build file entities for the sub-targets. One that's on the
>> table now is to use ANTModule from http://www.ct42.de/en/ch02.html.
>> See below for the discussion that's happened so far.
>>
>> As this would refactor the build (to a degree), I figure this
>> should be discussed. What do "we" think?...
>
>
> Assuming this is really needed, wouldn'it be easier to store well-formed
> ant include files and pre-process them (with XSLT for example) during
> the build, instead of introducing yet another build tool?
>
> -Bertrand
Ok, this is the simple option, ANTModule might be oversized. It's very
useful if you want to reuse parts of your build system (the modules) in
different projects. We for example have a module for JBoss specific stuff
(server start, shutdown and so on) and this module is reused in different
projects.
But here we have only have *one* project (Cocoon) and we have *one* build
system for this *one* project.
The last remaining question IMHO is: *Why* does every Apache project have
its own build system? So many tasks are done again and again and in every
project, e.g. the really overall needed "compile". Imagine there are
different Cocoon subprojects and every one has its own build system code to
start Cocoon including the subprojects' extensions, setting up the almost
same classpath and so on.
Joerg
--
System Development
VIRBUS AG
Fon +49(0)341-979-7419
Fax +49(0)341-979-7409
joerg.heinicke@virbus.de
www.virbus.de
Re: src/targets xml fragments
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Vendredi, 27 juin 2003, à 15:52 Europe/Zurich, Geoff Howard a écrit :
> Joerg, David and I are discussing alternatives to the current
> build file entities for the sub-targets. One that's on the
> table now is to use ANTModule from http://www.ct42.de/en/ch02.html.
> See below for the discussion that's happened so far.
>
> As this would refactor the build (to a degree), I figure this
> should be discussed. What do "we" think?...
Assuming this is really needed, wouldn'it be easier to store
well-formed ant include files and pre-process them (with XSLT for
example) during the build, instead of introducing yet another build
tool?
-Bertrand
Re: src/targets xml fragments
Posted by Geoff Howard <co...@leverageweb.com>.
Joerg, David and I are discussing alternatives to the current
build file entities for the sub-targets. One that's on the
table now is to use ANTModule from http://www.ct42.de/en/ch02.html.
See below for the discussion that's happened so far.
As this would refactor the build (to a degree), I figure this
should be discussed. What do "we" think?
Geoff
At 12:41 PM 6/27/2003, Joerg wrote:
>Geoff Howard wrote:
>>To David's question:
>>I don't have an ant reference, but I don't think there's
>>a way to do that and still do the entity include. That's
>>why the resource Joerg pointed to exists I'd guess. You
>>can't have entities point to the children of the root node
>>by some magic I'm not aware of, can you??
>
>AFAIK not.
>
>>At 04:18 AM 6/27/2003, Joerg wrote:
>>
>>>May I point to http://www.ct42.de/en/ch02.html?
>>>
>>>Joerg
>>
>>Why, yes you may!
>>- Just curious - why is this not in ant itself? Is that what
>>the "integration in ant" page is about? If that's a goal,
>>perhaps we could help move it in that direction?
>
>There were discussions in the ant community about an importing mechanism
>and there will be possibly on in Ant 1.6. AFAIK without any target name
>prefixing, i.e. with the disadvantage of having unique names over all
>imported files. It's based on or similar to the ProjectHelper
>http://cvs.apache.org/viewcvs.cgi/ant/src/main/org/apache/tools/ant/helper/ProjectHelper2.java.
>
>>- Does someone (Joerg?) have experience using this?
>
>We have been using it in our company since half a year for a really
>complex build system.
>
>And I know the guy who wrote that very well, he works here too ;-)
>
>>- This seems like it would be pretty "invasive" in the sense that
>>every target would need to get touched if only to prefix the module
>>name to the beginning of the depends targets.
>
>You only need to touch these <antcall target=""/> or <target depends=""/>
>that refer to another file. The imported files (at the moment by entities)
>must surrounded by an <module name="modulename"/> element.
>
>I can imagine an automatic migration by two stylesheets:
>1. Make all included files well-formed.
>2. Create a list of all <target name=""/> with their file/module name.
>3. Replace all antcalls/dependencies target names with their prefixed version.
>
>>Is that overly
>>invasive given that beta is right around the corner?
>
>I guess less than 5 hours?? I would volunteer for it if you want to use
>that tool. If the beta is to near maybe after releasing the first beta?
>
>Additionally the ant task <antstructure/>
>(http://ant.apache.org/manual/CoreTasks/antstructure.html) is extended by
>the added elements <import/> and <module/>.
>
>What do you think?
I think it's worth proposing!
Geoff
Re: src/targets xml fragments
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Joerg Heinicke wrote, On 27/06/2003 18.41:
> Geoff Howard wrote:
>
>> To David's question:
>> I don't have an ant reference, but I don't think there's
>> a way to do that and still do the entity include. That's
>> why the resource Joerg pointed to exists I'd guess. You
>> can't have entities point to the children of the root node
>> by some magic I'm not aware of, can you??
>
> AFAIK not.
>
>> At 04:18 AM 6/27/2003, Joerg wrote:
>>
>>> May I point to http://www.ct42.de/en/ch02.html?
>>>
>>> Joerg
>>
>> Why, yes you may!
>> - Just curious - why is this not in ant itself?
Because Ant is doing it's own mechanism, that started before you posted
a reference to your project on the Ant list.
>> Is that what
>> the "integration in ant" page is about? If that's a goal,
>> perhaps we could help move it in that direction?
>
> There were discussions in the ant community about an importing mechanism
> and there will be possibly on in Ant 1.6. AFAIK without any target name
> prefixing, i.e. with the disadvantage of having unique names over all
> imported files. It's based on or similar to the ProjectHelper
> http://cvs.apache.org/viewcvs.cgi/ant/src/main/org/apache/tools/ant/helper/ProjectHelper2.java.
This is a tad imprecise.
The <import> task is in Ant codebase since months now, and used by
Centipede for much much more.
As for the ProjectHelper, it's a different thing, as import is a task
that hooks into the Ant ProjectHelper.
What does your task bring more than Ant1.6's one, task name prefixing?
That's trivial to add to Ant, but then we need to do it also with
properties, references, etc etc.
...
> What do you think?
I think that waiting for Ant1.6 is much better. Centipede also makes
antlibs contain these plugin buildfiles, and adds other feature like
automatic jar downloads, initialization of common variables,
multi-project builds (that Cocoon needs because of blocks).
If you *really* want to help us (Ant and Centipede) in this import
facility, get on the Ant list and send patches that enhance the current
import task in what you need.
How do you reference base and plugin-relative files?
How do you, if ever, alias local plugin project properties?
And most of all: what prevents you with sending patches to Ant instead
of continuing to focus on your proprietary import method?
It's a lot since Ant and your project knew of each other, what happened
since then?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: src/targets xml fragments
Posted by Joerg Heinicke <jo...@gmx.de>.
Geoff Howard wrote:
> To David's question:
> I don't have an ant reference, but I don't think there's
> a way to do that and still do the entity include. That's
> why the resource Joerg pointed to exists I'd guess. You
> can't have entities point to the children of the root node
> by some magic I'm not aware of, can you??
AFAIK not.
> At 04:18 AM 6/27/2003, Joerg wrote:
>
>> May I point to http://www.ct42.de/en/ch02.html?
>>
>> Joerg
>
>
> Why, yes you may!
> - Just curious - why is this not in ant itself? Is that what
> the "integration in ant" page is about? If that's a goal,
> perhaps we could help move it in that direction?
There were discussions in the ant community about an importing mechanism and
there will be possibly on in Ant 1.6. AFAIK without any target name
prefixing, i.e. with the disadvantage of having unique names over all
imported files. It's based on or similar to the ProjectHelper
http://cvs.apache.org/viewcvs.cgi/ant/src/main/org/apache/tools/ant/helper/ProjectHelper2.java.
> - Does someone (Joerg?) have experience using this?
We have been using it in our company since half a year for a really complex
build system.
And I know the guy who wrote that very well, he works here too ;-)
> - This seems like it would be pretty "invasive" in the sense that
> every target would need to get touched if only to prefix the module
> name to the beginning of the depends targets.
You only need to touch these <antcall target=""/> or <target depends=""/>
that refer to another file. The imported files (at the moment by entities)
must surrounded by an <module name="modulename"/> element.
I can imagine an automatic migration by two stylesheets:
1. Make all included files well-formed.
2. Create a list of all <target name=""/> with their file/module name.
3. Replace all antcalls/dependencies target names with their prefixed version.
> Is that overly
> invasive given that beta is right around the corner?
I guess less than 5 hours?? I would volunteer for it if you want to use that
tool. If the beta is to near maybe after releasing the first beta?
Additionally the ant task <antstructure/>
(http://ant.apache.org/manual/CoreTasks/antstructure.html) is extended by
the added elements <import/> and <module/>.
What do you think?
Joerg
--
System Development
VIRBUS AG
Fon +49(0)341-979-7419
Fax +49(0)341-979-7409
joerg.heinicke@virbus.de
www.virbus.de
Re: src/targets xml fragments
Posted by Geoff Howard <co...@leverageweb.com>.
To David's question:
I don't have an ant reference, but I don't think there's
a way to do that and still do the entity include. That's
why the resource Joerg pointed to exists I'd guess. You
can't have entities point to the children of the root node
by some magic I'm not aware of, can you??
At 04:18 AM 6/27/2003, Joerg wrote:
>May I point to http://www.ct42.de/en/ch02.html?
>
>Joerg
Why, yes you may!
- Just curious - why is this not in ant itself? Is that what
the "integration in ant" page is about? If that's a goal,
perhaps we could help move it in that direction?
- Does someone (Joerg?) have experience using this?
- This seems like it would be pretty "invasive" in the sense that
every target would need to get touched if only to prefix the module
name to the beginning of the depends targets. Is that overly
invasive given that beta is right around the corner?
Seems to me though that this is what we "need" - anyone else
have other ideas?
Geoff
>David Crossley wrote:
>>On 2003-03-30, Geoff Howard wrote:
>>
>>>Is there any strategy for making the xml fragments in src/targets
>>>well-formed so editors don't barf on them?
>>
>>That sounds like a good idea and makes me itch.
>>What do you think needs to be done?
>>Is it just that the multiple <target> elements need
>>to be wrapped in a container element?
>>--David
Re: src/targets xml fragments
Posted by Joerg Heinicke <jo...@gmx.de>.
May I point to http://www.ct42.de/en/ch02.html?
Joerg
David Crossley wrote:
> On 2003-03-30, Geoff Howard wrote:
>
>>Is there any strategy for making the xml fragments in
>>src/targets well-formed so editors don't barf on them?
>
>
> That sounds like a good idea and makes me itch.
> What do you think needs to be done?
>
> Is it just that the multiple <target> elements need
> to be wrapped in a container element?
>
> --David
Re: src/targets xml fragments
Posted by David Crossley <cr...@indexgeo.com.au>.
On 2003-03-30, Geoff Howard wrote:
> Is there any strategy for making the xml fragments in
> src/targets well-formed so editors don't barf on them?
That sounds like a good idea and makes me itch.
What do you think needs to be done?
Is it just that the multiple <target> elements need
to be wrapped in a container element?
--David