You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Stanislas Pinte <st...@wanadoo.be> on 2000/11/22 10:15:02 UTC
enhydra make and xmlc tasks
hello,
has anyone got a task to be used to create a new enhydra project, or to use
the XMLC compiler?
STan
-------------------------------------------------------
Stanislas Pinte
Software engineer - Trademine-europe
Tel: 00 32 486 67 78 86
-------------------------------------------------------
Re: enhydra make and xmlc tasks
Posted by Stanislas Pinte <st...@wanadoo.be>.
Let's go now!
Stan
Would some ones want to collaborate with me on that?
Stan
At 08:32 PM 11/22/00 +1100, you wrote:
>At 10:15 22/11/00 +0100, you wrote:
> >hello,
> >
> >has anyone got a task to be used to create a new enhydra project, or to use
> >the XMLC compiler?
>
>Not that I know of but it would be a very kewl addition (*hint* *hint*) ;)
>
>Cheers,
>
>Pete
>
>*------------------------------------------------------*
>| Despite your efforts to be a romantic hero, you will |
>| gradually evolve into a postmodern plot device. |
>*------------------------------------------------------*
-------------------------------------------------------
Stanislas Pinte
Software engineer - Trademine-europe
Tel: 00 32 486 67 78 86
-------------------------------------------------------
RE: enhydra make and xmlc tasks
Posted by Stanislas Pinte <st...@wanadoo.be>.
What I had in mind was to build an Ant task for xmlc, being totally
non-intrusive to enhydra, and enabling the user
to use the standard xmlc, specifying all enhydra-needed properties.
So I guess no license issues in that case, right?
At 09:37 PM 11/22/00 +1100, you wrote:
>Pete,
>
>A fair while ago, William G Thompson submitted a task for xmlc. He had
>made some changes to xmlc for it to work with ant and he included this
>updated xmlc.jar file. This file includes gnu.regexp.* classes.
>
>At the time, I had heard that there were some issues with APL/GPL/LGPL,
>so I asked him if this was an issue. He stated that the gnu.regexp
>classes were LGPL so he thought there was no problem. I wasn't so sure
>and asked the list (and Duncan) for clarification. I didn't get much
>feedback.
>
>I don't whether Enhydra is using these classes or just William and what
>that all means for an ant xmlc task. I'm not even sure about the
>interaction between the APL and the Enhydra licence. At the time, I
>quoted Duncan thus
>
> > To quote James Duncan Davidson
> >
> > > The ASF board would have to make a ruling on that I think since we
>don't
> > > have a known way that the SPL (basically MPL) and ASF license
>interact.
> > It's
> > > totally clear that they can use our code. But going the other way is
> > > something I'm not sure of. I'll be asking and replying.
> > >
> > > .duncan
>
>I looked at the time and the Enhydra licence seemed to relate to the
>MPL.
>
>I don't know the resolution of these issues. You seem to be more across
>the licensing issues. Any ideas?
>
>Check out William's submission here
>
>http://marc.theaimsgroup.com/?l=ant-dev&m=86951893308217&w=2
>
>
>Conor
>
>
> > -----Original Message-----
> > From: Peter Donald [mailto:donaldp@apache.org]
> > Sent: Wednesday, 22 November 2000 20:32
> > To: ant-user@jakarta.apache.org
> > Subject: Re: enhydra make and xmlc tasks
> >
> >
> > At 10:15 22/11/00 +0100, you wrote:
> > >hello,
> > >
> > >has anyone got a task to be used to create a new enhydra
> > project, or to use
> > >the XMLC compiler?
> >
> > Not that I know of but it would be a very kewl addition
> > (*hint* *hint*) ;)
> >
> > Cheers,
> >
> > Pete
> >
> > *------------------------------------------------------*
> > | Despite your efforts to be a romantic hero, you will |
> > | gradually evolve into a postmodern plot device. |
> > *------------------------------------------------------*
> >
-------------------------------------------------------
Stanislas Pinte
Software engineer - Trademine-europe
Tel: 00 32 486 67 78 86
-------------------------------------------------------
RE: enhydra make and xmlc tasks
Posted by Peter Donald <do...@apache.org>.
At 09:37 22/11/00 +1100, you wrote:
>Pete,
>
>A fair while ago, William G Thompson submitted a task for xmlc. He had
>made some changes to xmlc for it to work with ant and he included this
>updated xmlc.jar file. This file includes gnu.regexp.* classes.
actually now I remember ... took ages for that mail to download ;)
>At the time, I had heard that there were some issues with APL/GPL/LGPL,
>so I asked him if this was an issue. He stated that the gnu.regexp
>classes were LGPL so he thought there was no problem. I wasn't so sure
>and asked the list (and Duncan) for clarification. I didn't get much
>feedback.
I think the LGPL is fine if it is in binary form only. Turbine/James/Cocoon
etc rely on LGPLed libraries.
>I don't whether Enhydra is using these classes or just William and what
>that all means for an ant xmlc task. I'm not even sure about the
>interaction between the APL and the Enhydra licence.
I *think* that it is fine if to "use" xmlc if we do not modify it. If there
needs to be modifications made the xmlc then they need to be done outside
of apache CVS (preferrably at enhydra thou if not at somewhere else). Thou
IANAL ;) So if the task can be written just using a prebuilt xmlc binary it
would be considered a "Larger Work" and only the xmlc is covered by
OPL/Enhydra license.
Thats my guess but it would be good to seek clarification.
Cheers,
Pete
*------------------------------------------------------*
| Despite your efforts to be a romantic hero, you will |
| gradually evolve into a postmodern plot device. |
*------------------------------------------------------*
RE: How to pass arguments to a custom doclet
Posted by "J. Matthew Pryor" <jm...@verveinc.com>.
RTFWWW, I answered my own question :
http://java.sun.com/j2se/1.3/docs/tooldocs/javadoc/overview.html#options
jmp
> -----Original Message-----
> From: J. Matthew Pryor [mailto:jmp@verveinc.com]
> Sent: Wednesday, November 22, 2000 4:46 PM
> To: ant-user@jakarta.apache.org
> Subject: How to pass arguments to a custom doclet
>
>
> I am using the javadoc task to run a cusom doclet
>
> It works just fine using this rule:
> <!-- generate the toplink proxies -->
> <target name="generateTopLinkProxies">
> <javadoc private="true" sourcepath="${source}" destdir="${gen}"
> packagenames="a.b.c.*" docletpathref="run.classpath" >
> <doclet
> name="a.b.framework.tools.codegen.toplink.CloneProxyDoclet">
> </doclet>
> </javadoc>
> </target>
>
> Now I wish to have the destdir parameter passed to my doculet, but is
> doesn't
>
> There was a previous posting on ths list pointing out that the
> destdir (-d)
> option was for the standard doclet only. If that is the case, how do I
> specify additional otpions that will get passed into my doclet ?
>
> using a param for the doclet
>
> <doclet
> name="a.b.framework.tools.codegen.toplink.CloneProxyDoclet">
> <param name="-foo" value="foovalue"/>
> </doclet>
>
> results in
>
> [javadoc] Generating Javadoc
> [javadoc] Javadoc args: javadoc -private -classpath
> D:\dev\jdk1.3\lib\tools.jar;.\3rdparty\jakarta-ant_1.2\lib\ant.jar
> ;.\3rdpart
> y\jakarta-ant_1.2\lib\xml.jar;.\3rdparty\jakarta-ant_1.2\lib\jaxp.
> jar;.\3rdp
> arty\jakarta-ant_1.2\lib\parser.jar -sourcepath C:\src -doclet
> a.b.framework.tools.codegen.toplink.CloneProxyDoclet -docletpath
> C:\build\classes;D:\dev\Oracle\ora81\jdbc\lib\classes111.zip;D:\de
> v\TopLink3
> .0pr1\TLJ\Classes\JDK1.3\toplink.jar;D:\dev\TopLink3.0pr1\TLJ\Clas
> ses\JDK1.3
> \tools.jar;D:\dev\TopLink3.0pr1\TLJ\Classes\JDK1.3\toplinksdk.jar;
> D:\dev\Top
> Link3.0pr1\TLJ\Classes\JDK1.3\toplinksdkxerces.jar;D:\dev\TopLink3
> .0pr1\TLJ\
> Classes\JDK1.3\toplinkx.jar;D:\dev\TopLink3.0pr1\TLJ\Classes\JDK1.
> 3\xerces.j
> ar;C:\3rdparty\log4j-v0.8.5b\log4j.jar -foo foovalue a.b.c
> [javadoc] Javadoc execution
> [javadoc] usage: javadoc [options] [packagenames] [sourcefiles]
> [classnames] [@files]
> [javadoc] javadoc: invalid flag: -foo
> [javadoc] -overview <file> Read overview documentation
> from HTML
> file
> [javadoc] -public Show only public classes and members
> [javadoc] -protected Show protected/public classes and
> members (default)
> [javadoc] -package Show
> package/protected/public classes
> and members
> [javadoc] -private Show all classes and members
> [javadoc] -help Display command line options
> [javadoc] -doclet <class> Generate output via alternate doclet
> [javadoc] -docletpath <path> Specify where to find doclet class
> files
> [javadoc] -1.1 Generate output using JDK 1.1
> emulating doclet
> [javadoc] -sourcepath <pathlist> Specify where to find source files
> [javadoc] -classpath <pathlist> Specify where to find user
> class files
> [javadoc] -bootclasspath <pathlist> Override location of class files
> loaded
> [javadoc] by the bootstrap class loader
> [javadoc] -extdirs <dirlist> Override location of installed
> extensions
> [javadoc] -verbose Output messages about what
> Javadoc is
> doing
> [javadoc] -locale <name> Locale to be used, e.g. en_US or
> en_US_WIN
> [javadoc] -encoding <name> Source file encoding name
> [javadoc] -J<flag> Pass <flag> directly to the runtime
> system
> [javadoc]
> [javadoc] 1 error
>
> Using : additionalparam in the javadoc target
>
> <javadoc private="true" sourcepath="${source}"
> packagenames="a.b.c.*" docletpathref="run.classpath" additionalparam="-foo
> foovalue" >
> <doclet
> name="a.b.framework.tools.codegen.toplink.CloneProxyDoclet">
> </doclet>
> </javadoc>
>
> results in :
>
> [javadoc] Javadoc args: javadoc -private "-foo foovalue" -classpath
> D:\dev\jdk1.3\lib\tools.jar;.\3rdparty\jakarta-ant_1.2\lib\ant.jar
> ;.\3rdpart
> y\jakarta-ant_1.2\lib\xml.jar;.\3rdparty\jakarta-ant_1.2\lib\jaxp.
> jar;.\3rdp
> arty\jakarta-ant_1.2\lib\parser.jar -sourcepath C:\src -doclet
> a.b.framework.tools.codegen.toplink.CloneProxyDoclet -docletpath
> C:\build\classes;D:\dev\Oracle\ora81\jdbc\lib\classes111.zip;D:\de
> v\TopLink3
> .0pr1\TLJ\Classes\JDK1.3\toplink.jar;D:\dev\TopLink3.0pr1\TLJ\Clas
> ses\JDK1.3
> \tools.jar;D:\dev\TopLink3.0pr1\TLJ\Classes\JDK1.3\toplinksdk.jar;
> D:\dev\Top
> Link3.0pr1\TLJ\Classes\JDK1.3\toplinksdkxerces.jar;D:\dev\TopLink3
> .0pr1\TLJ\
> Classes\JDK1.3\toplinkx.jar;D:\dev\TopLink3.0pr1\TLJ\Classes\JDK1.
> 3\xerces.j
> ar;C:\3rdparty\log4j-v0.8.5b\log4j.jar a.b.c
> [javadoc] Javadoc execution
> [javadoc] javadoc: invalid flag: -foo foovalue
> [javadoc] usage: javadoc [options] [packagenames] [sourcefiles]
> [classnames] [@files]
> [javadoc] -overview <file> Read overview documentation
> from HTML
> file
> [javadoc] -public Show only public classes and members
> [javadoc] -protected Show protected/public classes and
> members (default)
> [javadoc] -package Show
> package/protected/public classes
> and members
> [javadoc] -private Show all classes and members
> [javadoc] -help Display command line options
> [javadoc] -doclet <class> Generate output via alternate doclet
> [javadoc] -docletpath <path> Specify where to find doclet class
> files
> [javadoc] -1.1 Generate output using JDK 1.1
> emulating doclet
> [javadoc] -sourcepath <pathlist> Specify where to find source files
> [javadoc] -classpath <pathlist> Specify where to find user
> class files
> [javadoc] -bootclasspath <pathlist> Override location of class files
> loaded
> [javadoc] by the bootstrap class loader
> [javadoc] -extdirs <dirlist> Override location of installed
> extensions
> [javadoc] -verbose Output messages about what
> Javadoc is
> doing
> [javadoc] -locale <name> Locale to be used, e.g. en_US or
> en_US_WIN
> [javadoc] -encoding <name> Source file encoding name
> [javadoc] -J<flag> Pass <flag> directly to the runtime
> system
> [javadoc]
> [javadoc] 1 error
>
> So I cannot work out how to get custom options to my doclet
>
> I guess this may be a doclet thing rather than an Ant thing ..
>
> Any help appreciated
>
> Matthew
>
>
>
How to pass arguments to a custom doclet
Posted by "J. Matthew Pryor" <jm...@verveinc.com>.
I am using the javadoc task to run a cusom doclet
It works just fine using this rule:
<!-- generate the toplink proxies -->
<target name="generateTopLinkProxies">
<javadoc private="true" sourcepath="${source}" destdir="${gen}"
packagenames="a.b.c.*" docletpathref="run.classpath" >
<doclet
name="a.b.framework.tools.codegen.toplink.CloneProxyDoclet">
</doclet>
</javadoc>
</target>
Now I wish to have the destdir parameter passed to my doculet, but is
doesn't
There was a previous posting on ths list pointing out that the destdir (-d)
option was for the standard doclet only. If that is the case, how do I
specify additional otpions that will get passed into my doclet ?
using a param for the doclet
<doclet
name="a.b.framework.tools.codegen.toplink.CloneProxyDoclet">
<param name="-foo" value="foovalue"/>
</doclet>
results in
[javadoc] Generating Javadoc
[javadoc] Javadoc args: javadoc -private -classpath
D:\dev\jdk1.3\lib\tools.jar;.\3rdparty\jakarta-ant_1.2\lib\ant.jar;.\3rdpart
y\jakarta-ant_1.2\lib\xml.jar;.\3rdparty\jakarta-ant_1.2\lib\jaxp.jar;.\3rdp
arty\jakarta-ant_1.2\lib\parser.jar -sourcepath C:\src -doclet
a.b.framework.tools.codegen.toplink.CloneProxyDoclet -docletpath
C:\build\classes;D:\dev\Oracle\ora81\jdbc\lib\classes111.zip;D:\dev\TopLink3
.0pr1\TLJ\Classes\JDK1.3\toplink.jar;D:\dev\TopLink3.0pr1\TLJ\Classes\JDK1.3
\tools.jar;D:\dev\TopLink3.0pr1\TLJ\Classes\JDK1.3\toplinksdk.jar;D:\dev\Top
Link3.0pr1\TLJ\Classes\JDK1.3\toplinksdkxerces.jar;D:\dev\TopLink3.0pr1\TLJ\
Classes\JDK1.3\toplinkx.jar;D:\dev\TopLink3.0pr1\TLJ\Classes\JDK1.3\xerces.j
ar;C:\3rdparty\log4j-v0.8.5b\log4j.jar -foo foovalue a.b.c
[javadoc] Javadoc execution
[javadoc] usage: javadoc [options] [packagenames] [sourcefiles]
[classnames] [@files]
[javadoc] javadoc: invalid flag: -foo
[javadoc] -overview <file> Read overview documentation from HTML
file
[javadoc] -public Show only public classes and members
[javadoc] -protected Show protected/public classes and
members (default)
[javadoc] -package Show package/protected/public classes
and members
[javadoc] -private Show all classes and members
[javadoc] -help Display command line options
[javadoc] -doclet <class> Generate output via alternate doclet
[javadoc] -docletpath <path> Specify where to find doclet class
files
[javadoc] -1.1 Generate output using JDK 1.1
emulating doclet
[javadoc] -sourcepath <pathlist> Specify where to find source files
[javadoc] -classpath <pathlist> Specify where to find user class files
[javadoc] -bootclasspath <pathlist> Override location of class files
loaded
[javadoc] by the bootstrap class loader
[javadoc] -extdirs <dirlist> Override location of installed
extensions
[javadoc] -verbose Output messages about what Javadoc is
doing
[javadoc] -locale <name> Locale to be used, e.g. en_US or
en_US_WIN
[javadoc] -encoding <name> Source file encoding name
[javadoc] -J<flag> Pass <flag> directly to the runtime
system
[javadoc]
[javadoc] 1 error
Using : additionalparam in the javadoc target
<javadoc private="true" sourcepath="${source}"
packagenames="a.b.c.*" docletpathref="run.classpath" additionalparam="-foo
foovalue" >
<doclet
name="a.b.framework.tools.codegen.toplink.CloneProxyDoclet">
</doclet>
</javadoc>
results in :
[javadoc] Javadoc args: javadoc -private "-foo foovalue" -classpath
D:\dev\jdk1.3\lib\tools.jar;.\3rdparty\jakarta-ant_1.2\lib\ant.jar;.\3rdpart
y\jakarta-ant_1.2\lib\xml.jar;.\3rdparty\jakarta-ant_1.2\lib\jaxp.jar;.\3rdp
arty\jakarta-ant_1.2\lib\parser.jar -sourcepath C:\src -doclet
a.b.framework.tools.codegen.toplink.CloneProxyDoclet -docletpath
C:\build\classes;D:\dev\Oracle\ora81\jdbc\lib\classes111.zip;D:\dev\TopLink3
.0pr1\TLJ\Classes\JDK1.3\toplink.jar;D:\dev\TopLink3.0pr1\TLJ\Classes\JDK1.3
\tools.jar;D:\dev\TopLink3.0pr1\TLJ\Classes\JDK1.3\toplinksdk.jar;D:\dev\Top
Link3.0pr1\TLJ\Classes\JDK1.3\toplinksdkxerces.jar;D:\dev\TopLink3.0pr1\TLJ\
Classes\JDK1.3\toplinkx.jar;D:\dev\TopLink3.0pr1\TLJ\Classes\JDK1.3\xerces.j
ar;C:\3rdparty\log4j-v0.8.5b\log4j.jar a.b.c
[javadoc] Javadoc execution
[javadoc] javadoc: invalid flag: -foo foovalue
[javadoc] usage: javadoc [options] [packagenames] [sourcefiles]
[classnames] [@files]
[javadoc] -overview <file> Read overview documentation from HTML
file
[javadoc] -public Show only public classes and members
[javadoc] -protected Show protected/public classes and
members (default)
[javadoc] -package Show package/protected/public classes
and members
[javadoc] -private Show all classes and members
[javadoc] -help Display command line options
[javadoc] -doclet <class> Generate output via alternate doclet
[javadoc] -docletpath <path> Specify where to find doclet class
files
[javadoc] -1.1 Generate output using JDK 1.1
emulating doclet
[javadoc] -sourcepath <pathlist> Specify where to find source files
[javadoc] -classpath <pathlist> Specify where to find user class files
[javadoc] -bootclasspath <pathlist> Override location of class files
loaded
[javadoc] by the bootstrap class loader
[javadoc] -extdirs <dirlist> Override location of installed
extensions
[javadoc] -verbose Output messages about what Javadoc is
doing
[javadoc] -locale <name> Locale to be used, e.g. en_US or
en_US_WIN
[javadoc] -encoding <name> Source file encoding name
[javadoc] -J<flag> Pass <flag> directly to the runtime
system
[javadoc]
[javadoc] 1 error
So I cannot work out how to get custom options to my doclet
I guess this may be a doclet thing rather than an Ant thing ..
Any help appreciated
Matthew
RE: enhydra make and xmlc tasks
Posted by Chris Todd <ch...@christophertodd.com>.
If it is the gnu.regexp.* classes that are the only licensing issue, why not
simply replace them with jakarta-ORO?
Sincerest regards,
Chris Todd
Software Engineer
Alabanza Corporation
ctodd@alabanza.com
>-----Original Message-----
>From: Conor MacNeill [mailto:conor@m64.com]
>Sent: Wednesday, November 22, 2000 5:37 AM
>To: ant-user@jakarta.apache.org
>Subject: RE: enhydra make and xmlc tasks
>
>
>Pete,
>
>A fair while ago, William G Thompson submitted a task for xmlc. He had
>made some changes to xmlc for it to work with ant and he included this
>updated xmlc.jar file. This file includes gnu.regexp.* classes.
>
>At the time, I had heard that there were some issues with APL/GPL/LGPL,
>so I asked him if this was an issue. He stated that the gnu.regexp
>classes were LGPL so he thought there was no problem. I wasn't so sure
>and asked the list (and Duncan) for clarification. I didn't get much
>feedback.
>
>I don't whether Enhydra is using these classes or just William and what
>that all means for an ant xmlc task. I'm not even sure about the
>interaction between the APL and the Enhydra licence. At the time, I
>quoted Duncan thus
>
>> To quote James Duncan Davidson
>>
>> > The ASF board would have to make a ruling on that I think since we
>don't
>> > have a known way that the SPL (basically MPL) and ASF license
>interact.
>> It's
>> > totally clear that they can use our code. But going the other way is
>> > something I'm not sure of. I'll be asking and replying.
>> >
>> > .duncan
>
>I looked at the time and the Enhydra licence seemed to relate to the
>MPL.
>
>I don't know the resolution of these issues. You seem to be more across
>the licensing issues. Any ideas?
>
>Check out William's submission here
>
>http://marc.theaimsgroup.com/?l=ant-dev&m=86951893308217&w=2
>
>
>Conor
>
>
>> -----Original Message-----
>> From: Peter Donald [mailto:donaldp@apache.org]
>> Sent: Wednesday, 22 November 2000 20:32
>> To: ant-user@jakarta.apache.org
>> Subject: Re: enhydra make and xmlc tasks
>>
>>
>> At 10:15 22/11/00 +0100, you wrote:
>> >hello,
>> >
>> >has anyone got a task to be used to create a new enhydra
>> project, or to use
>> >the XMLC compiler?
>>
>> Not that I know of but it would be a very kewl addition
>> (*hint* *hint*) ;)
>>
>> Cheers,
>>
>> Pete
>>
>> *------------------------------------------------------*
>> | Despite your efforts to be a romantic hero, you will |
>> | gradually evolve into a postmodern plot device. |
>> *------------------------------------------------------*
>>
>
>
>
RE: enhydra make and xmlc tasks
Posted by Conor MacNeill <co...@m64.com>.
Pete,
A fair while ago, William G Thompson submitted a task for xmlc. He had
made some changes to xmlc for it to work with ant and he included this
updated xmlc.jar file. This file includes gnu.regexp.* classes.
At the time, I had heard that there were some issues with APL/GPL/LGPL,
so I asked him if this was an issue. He stated that the gnu.regexp
classes were LGPL so he thought there was no problem. I wasn't so sure
and asked the list (and Duncan) for clarification. I didn't get much
feedback.
I don't whether Enhydra is using these classes or just William and what
that all means for an ant xmlc task. I'm not even sure about the
interaction between the APL and the Enhydra licence. At the time, I
quoted Duncan thus
> To quote James Duncan Davidson
>
> > The ASF board would have to make a ruling on that I think since we
don't
> > have a known way that the SPL (basically MPL) and ASF license
interact.
> It's
> > totally clear that they can use our code. But going the other way is
> > something I'm not sure of. I'll be asking and replying.
> >
> > .duncan
I looked at the time and the Enhydra licence seemed to relate to the
MPL.
I don't know the resolution of these issues. You seem to be more across
the licensing issues. Any ideas?
Check out William's submission here
http://marc.theaimsgroup.com/?l=ant-dev&m=86951893308217&w=2
Conor
> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
> Sent: Wednesday, 22 November 2000 20:32
> To: ant-user@jakarta.apache.org
> Subject: Re: enhydra make and xmlc tasks
>
>
> At 10:15 22/11/00 +0100, you wrote:
> >hello,
> >
> >has anyone got a task to be used to create a new enhydra
> project, or to use
> >the XMLC compiler?
>
> Not that I know of but it would be a very kewl addition
> (*hint* *hint*) ;)
>
> Cheers,
>
> Pete
>
> *------------------------------------------------------*
> | Despite your efforts to be a romantic hero, you will |
> | gradually evolve into a postmodern plot device. |
> *------------------------------------------------------*
>
Re: enhydra make and xmlc tasks
Posted by Peter Donald <do...@apache.org>.
At 10:15 22/11/00 +0100, you wrote:
>hello,
>
>has anyone got a task to be used to create a new enhydra project, or to use
>the XMLC compiler?
Not that I know of but it would be a very kewl addition (*hint* *hint*) ;)
Cheers,
Pete
*------------------------------------------------------*
| Despite your efforts to be a romantic hero, you will |
| gradually evolve into a postmodern plot device. |
*------------------------------------------------------*