You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2001/11/21 08:39:18 UTC
xdocs for cornerstone/apps/*
Peter,
I'm trying to do some xdocs for the cornerstone apps (starting with
hsql). I'm having some problems with ${tools.dir} and it seemingly
inheriting from the master build.xml for cornerstone (despite
inheritall="false"). Could you take a look please :-) The target is
"build hsql docs" if you could not guess.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: xdocs for cornerstone/apps/*
Posted by Peter Donald <pe...@apache.org>.
On Sat, 24 Nov 2001 23:01, Paul Hammant wrote:
> Peter,
>
> >>1) In jakarta-avalon-cornerstone/ doing "ant hsql xdocs_alt" leaves
> >>${apps-target}unset. The build.bat/sh file was setting this.
> >>
> >> I guess this is indicating that all permutations must be expanded
> >>into targets in the top level :-(
> >
> >or don't use the top level file to build projects that are largely
> >independent ? I don't ;)
>
> Rule #2 - http://www.joelonsoftware.com/articles/fog0000000043.html
kool site. Can't see what relevence rule 2 has to this situation. In both
cases we do have one step. ie Whats the difference between
cd $CORNERSTONE_HOME && ant
and
cd $CORNERSTONE_HOME/apps/hsql && ant
--
Cheers,
Pete
*------------------------------------------------------*
| "Computers are useless. They can only give you |
| answers." - Pablo Picasso |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: xdocs for cornerstone/apps/*
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>It is because the script overides tools.dir on the commandline. It is
>precisely these complications why I want to kill tools/ dir once and for good.
>
>If you insist on causing yourself pain by building projects from outside
>their tree you will have to do something like
>
>ant hsql -Dapps-target=xdocs_alt
>
OK, that still did not work.
Perhaps we should just remove those ten targets from Cornerstone that
cause controversy and force people to build using installed Ant from one
of the seven apps/xxx directories.
I can't help worrying about the central nightly build then...
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: xdocs for cornerstone/apps/*
Posted by Peter Donald <pe...@apache.org>.
On Sat, 24 Nov 2001 23:54, Paul Hammant wrote:
> Peter,
>
> >Yep - don't use "value" to define the location of tools dir but instead do
> >something like
> >
> ><property name="tools.dir" location="blah"/>
>
> Yup tried that in the top level build.xml (and committed it) but "build
> hsql xdocs_alt" still does not work.
>
> Could you take a look please Peter.... :-)
It is because the script overides tools.dir on the commandline. It is
precisely these complications why I want to kill tools/ dir once and for good.
If you insist on causing yourself pain by building projects from outside
their tree you will have to do something like
ant hsql -Dapps-target=xdocs_alt
--
Cheers,
Pete
---------------------------------------------
We shall not cease from exploration, and the
end of all our exploring will be to arrive
where we started and know the place for the
first time -- T.S. Eliot
---------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: xdocs for cornerstone/apps/*
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>
>Yep - don't use "value" to define the location of tools dir but instead do
>something like
>
><property name="tools.dir" location="blah"/>
>
Yup tried that in the top level build.xml (and committed it) but "build
hsql xdocs_alt" still does not work.
Could you take a look please Peter.... :-)
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: xdocs for cornerstone/apps/*
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>1) In jakarta-avalon-cornerstone/ doing "ant hsql xdocs_alt" leaves
>>${apps-target}unset. The build.bat/sh file was setting this.
>>
>> I guess this is indicating that all permutations must be expanded
>>into targets in the top level :-(
>>
>
>or don't use the top level file to build projects that are largely
>independent ? I don't ;)
>
Rule #2 - http://www.joelonsoftware.com/articles/fog0000000043.html
>I don't think you should be running the hsql build from the base directory
>but from in the hsql directory.
>
I'd agree. If it were my own source tree I would not have it at
sub-project level. I'd have it at top level, but this is Apache, and
they can't support every diseased half finished idea I have at top-level
;-)
>I was thinking about splitting the cornerstone build.xml into files. One just
>built cornerstone while the other would be a controller for all the projects
>build files. So if you wanted to rebuild all the projects (ftpserver, db,
>hsql, cornerstone, jesktop, etc) then you would do something like
>
>ant -f all.xml clean main
>
Kool...
>or similar. Thoughts?
>
>>2) In jakarta-avalon-cornerstone/ doing "build hsql xdocs_alt" leaves
>>${tools.dir}still relative, but wrong. I've tried passing the property
>>up like so...
>>
>> <target name="hsql" depends="compile" description="Delegates to
>>build.xml in apps/hsql">
>> <ant antfile="build.xml" dir="apps/hsql" target="${apps-target}"
>>inheritall="false">
>> <property name="tools.dir" value="../../${tools.dir}"/>
>> </ant>
>> </target>
>>
>>... but it is not changing anything, the property is still relatively
>>wrong.
>>
>>Any ideas?
>>
>
>Yep - don't use "value" to define the location of tools dir but instead do
>something like
>
><property name="tools.dir" location="blah"/>
>
ahhhh.
>This will resolve the tools directory completely. On my box the tools.dir
>property would evaluate to
>
>/opt/avalon/jakarta-avalon/tools
>
>rather than just
>
>../jakarta-avalon/tools
>
I'll have another go.
>
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: xdocs for cornerstone/apps/*
Posted by Peter Donald <pe...@apache.org>.
On Sat, 24 Nov 2001 22:08, Paul Hammant wrote:
> Peter,
>
> I trying again to get xdocs building for sub-projects in apps. I'm not
> having much luck.
>
> I've installed Ant and added the two missing jars. ( I prefer the
> built-in route to be honest )
So do I in some ways but it
> *Achievments*
>
> 1) In jakarta-avalon-cornerstone/apps/hsql/ "ant xdocs_alt" works as
> promised.
kool.
> 1) In jakarta-avalon-cornerstone/ doing "ant hsql xdocs_alt" leaves
> ${apps-target}unset. The build.bat/sh file was setting this.
>
> I guess this is indicating that all permutations must be expanded
> into targets in the top level :-(
or don't use the top level file to build projects that are largely
independent ? I don't ;)
I don't think you should be running the hsql build from the base directory
but from in the hsql directory.
I was thinking about splitting the cornerstone build.xml into files. One just
built cornerstone while the other would be a controller for all the projects
build files. So if you wanted to rebuild all the projects (ftpserver, db,
hsql, cornerstone, jesktop, etc) then you would do something like
ant -f all.xml clean main
or similar. Thoughts?
> 2) In jakarta-avalon-cornerstone/ doing "build hsql xdocs_alt" leaves
> ${tools.dir}still relative, but wrong. I've tried passing the property
> up like so...
>
> <target name="hsql" depends="compile" description="Delegates to
> build.xml in apps/hsql">
> <ant antfile="build.xml" dir="apps/hsql" target="${apps-target}"
> inheritall="false">
> <property name="tools.dir" value="../../${tools.dir}"/>
> </ant>
> </target>
>
> ... but it is not changing anything, the property is still relatively
> wrong.
>
> Any ideas?
Yep - don't use "value" to define the location of tools dir but instead do
something like
<property name="tools.dir" location="blah"/>
This will resolve the tools directory completely. On my box the tools.dir
property would evaluate to
/opt/avalon/jakarta-avalon/tools
rather than just
../jakarta-avalon/tools
--
Cheers,
Pete
---------------------------------------
Be nice to your friends. If it weren't
for them, you'd be a complete stranger.
---------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: xdocs for cornerstone/apps/*
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
OK, I stand corrected amd will take you on good faith that Ant 1.4.1
cures previous ills. Does it pass in tools.dir as a -D param?
If it is all the things we need, I vote we remove tools/ and go with an
installed Ant 1.4.1
Regards,
- Paul H
>On Wed, 21 Nov 2001 21:27, Paul Hammant wrote:
>
>>>So as soon as you use build.[sh|bat] then the tools.dir is overidden.
>>>Hmmmm. Have you considered making it work more like the demo/build.xml
>>>
>>Demo does not have xdocs working either!
>>
>
>but it would if you did what I suggested ;)
>
>>>The way I build demos is by cd'ing into apps/demo and then just "ant".
>>>
>>That's great Peter, but you are an Ant committer too. Some months ago
>>we were juggling versions of Ant that were not committed yet. Should we
>>use the Ant from ../jakarta-avalon/tools or not.
>>
>
>either should work. The reason we had to wait for 1.4.1 was because of a bug.
>We should be able to use 1.4.1 for everything now ... you can correct any
>build.xmls that don't work under 1.4.1 ;)
>
>>I used to have Jesktop apps working like that (30 build scripts). But
>>came to the conclusion that you could not get ant working from two
>>places in the same directory tree adequately.
>>
>
>You couldn't before 1.4.1 - now you can ;)
>
>>My feeling is that no amopunt of effort with the current Ant will allow
>>Ant invocation at dirA/ and dirA/dirB where build.xml in the former
>>delegates to another in the latter.
>>
>
>not sure what you mean but either of the following works in current
>cornerstone CVS with released version of ant.
>
>build.xml --> apps/demo/build.xml --> build.xml
>apps/demo/build.xml --> build.xml
>
>the first occurs if you go
>./build.sh demo
>
>while the second occurs if you go
>cd apps/demo
>ant
>
>>True..... But we've completely abandoned our Avalon (and possibly Ant)
>>newbies if we do that. It's already amazingly complicated with support
>>for Ant in a number of different installed or uninstalled places, and
>>Avalon get via two routes (CVS, nighlty download, release download)
>>
>
>Right - we could possibly remove ant from CVS now. We just need to document
>the install process (basically adding xalan and junit into ant/lib) and then
>we could almost remove the whole tools directory.
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: xdocs for cornerstone/apps/*
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
I trying again to get xdocs building for sub-projects in apps. I'm not
having much luck.
I've installed Ant and added the two missing jars. ( I prefer the
built-in route to be honest )
*Achievments*
1) In jakarta-avalon-cornerstone/apps/hsql/ "ant xdocs_alt" works as
promised.
*Problems*
1) In jakarta-avalon-cornerstone/ doing "ant hsql xdocs_alt" leaves
${apps-target}unset. The build.bat/sh file was setting this.
I guess this is indicating that all permutations must be expanded
into targets in the top level :-(
2) In jakarta-avalon-cornerstone/ doing "build hsql xdocs_alt" leaves
${tools.dir}still relative, but wrong. I've tried passing the property
up like so...
<target name="hsql" depends="compile" description="Delegates to
build.xml in apps/hsql">
<ant antfile="build.xml" dir="apps/hsql" target="${apps-target}"
inheritall="false">
<property name="tools.dir" value="../../${tools.dir}"/>
</ant>
</target>
... but it is not changing anything, the property is still relatively
wrong.
Any ideas?
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: xdocs for cornerstone/apps/*
Posted by Peter Donald <pe...@apache.org>.
On Wed, 21 Nov 2001 21:27, Paul Hammant wrote:
> >So as soon as you use build.[sh|bat] then the tools.dir is overidden.
> > Hmmmm. Have you considered making it work more like the demo/build.xml
>
> Demo does not have xdocs working either!
but it would if you did what I suggested ;)
> >The way I build demos is by cd'ing into apps/demo and then just "ant".
>
> That's great Peter, but you are an Ant committer too. Some months ago
> we were juggling versions of Ant that were not committed yet. Should we
> use the Ant from ../jakarta-avalon/tools or not.
either should work. The reason we had to wait for 1.4.1 was because of a bug.
We should be able to use 1.4.1 for everything now ... you can correct any
build.xmls that don't work under 1.4.1 ;)
> I used to have Jesktop apps working like that (30 build scripts). But
> came to the conclusion that you could not get ant working from two
> places in the same directory tree adequately.
You couldn't before 1.4.1 - now you can ;)
> My feeling is that no amopunt of effort with the current Ant will allow
> Ant invocation at dirA/ and dirA/dirB where build.xml in the former
> delegates to another in the latter.
not sure what you mean but either of the following works in current
cornerstone CVS with released version of ant.
build.xml --> apps/demo/build.xml --> build.xml
apps/demo/build.xml --> build.xml
the first occurs if you go
./build.sh demo
while the second occurs if you go
cd apps/demo
ant
> True..... But we've completely abandoned our Avalon (and possibly Ant)
> newbies if we do that. It's already amazingly complicated with support
> for Ant in a number of different installed or uninstalled places, and
> Avalon get via two routes (CVS, nighlty download, release download)
Right - we could possibly remove ant from CVS now. We just need to document
the install process (basically adding xalan and junit into ant/lib) and then
we could almost remove the whole tools directory.
--
Cheers,
Pete
The big mistake that men make is that when they turn thirteen or fourteen and
all of a sudden they've reached puberty, they believe that they like women.
Actually, you're just horny. It doesn't mean you like women any more at
twenty-one than you did at ten. --Jules Feiffer (cartoonist)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: xdocs for cornerstone/apps/*
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>I'm trying to do some xdocs for the cornerstone apps (starting with
>>hsql). I'm having some problems with ${tools.dir} and it seemingly
>>inheriting from the master build.xml for cornerstone (despite
>>inheritall="false"). Could you take a look please :-) The target is
>>"build hsql docs" if you could not guess.
>>
>
>Okays - it is actually build.sh that sets the tools.dir directtory like
>-Dtools.dir=$AVALON_TOOLS
>
Cool, I can pass that up with <param>
>So as soon as you use build.[sh|bat] then the tools.dir is overidden. Hmmmm.
>Have you considered making it work more like the demo/build.xml
>
Demo does not have xdocs working either!
>The way I build demos is by cd'ing into apps/demo and then just "ant".
>
That's great Peter, but you are an Ant committer too. Some months ago
we were juggling versions of Ant that were not committed yet. Should we
use the Ant from ../jakarta-avalon/tools or not.
I used to have Jesktop apps working like that (30 build scripts). But
came to the conclusion that you could not get ant working from two
places in the same directory tree adequately.
My feeling is that no amopunt of effort with the current Ant will allow
Ant invocation at dirA/ and dirA/dirB where build.xml in the former
delegates to another in the latter.
>If you
>have a look at the build file you will notice it has a cleverly positioned
>antcall back to the base build.xml (ie ../../build.xml) to make sure
>cornerstone.jar is built. You could do the same the other apps and then you
>would not need to use build.[sh|bat] you could just use ant.
>
>yer/no ?
>
True..... But we've completely abandoned our Avalon (and possibly Ant)
newbies if we do that. It's already amazingly complicated with support
for Ant in a number of different installed or uninstalled places, and
Avalon get via two routes (CVS, nighlty download, release download)
If we go this route should we book in build.bat/sh files to those
locations. My reservations (dirA/dirB) still exist. I think we have to
make one choice as to where Ant is invoked.
Whilst I'm ranting (I apologise as all of this is a zillion hours of
your work). Newbies are *really* put of by the number of vars used in a
build.xml file. I've simplied to the inferior hard coded type for the
Phoenix Dev Kit script example.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: xdocs for cornerstone/apps/*
Posted by Peter Donald <pe...@apache.org>.
On Wed, 21 Nov 2001 18:39, Paul Hammant wrote:
> Peter,
>
> I'm trying to do some xdocs for the cornerstone apps (starting with
> hsql). I'm having some problems with ${tools.dir} and it seemingly
> inheriting from the master build.xml for cornerstone (despite
> inheritall="false"). Could you take a look please :-) The target is
> "build hsql docs" if you could not guess.
Okays - it is actually build.sh that sets the tools.dir directtory like
-Dtools.dir=$AVALON_TOOLS
So as soon as you use build.[sh|bat] then the tools.dir is overidden. Hmmmm.
Have you considered making it work more like the demo/build.xml
The way I build demos is by cd'ing into apps/demo and then just "ant". If you
have a look at the build file you will notice it has a cleverly positioned
antcall back to the base build.xml (ie ../../build.xml) to make sure
cornerstone.jar is built. You could do the same the other apps and then you
would not need to use build.[sh|bat] you coul djust use ant.
yer/no ?
--
Cheers,
Pete
----------------------------------------------------
"The only way to discover the limits of the possible
is to go beyond them into the impossible."
-Arthur C. Clarke
----------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>