You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Jeff Turner <je...@socialchange.net.au> on 2001/12/10 13:16:10 UTC
Avalon src distro won't build (Re: [Code Freeze] Avalon should be in code freeze)
On Sat, Dec 08, 2001 at 11:12:41AM -0500, Berin Loritsch wrote:
> Peter Donald wrote:
>
> >On Sat, 8 Dec 2001 01:17, Berin Loritsch wrote:
> >
> >>I realized my last post should have had a new title so as not to be lost.
> >>Please come up with issues for Avalon Framework--and we will decide if it
> >>is a showstopper, a minor but allowable change (spelling/correction of
> >>documentation), or something that will be placed on hold.
> >>
> >>The CVS should have 100% back compatible code. If this is not the case,
> >>please alert me ASAP.
> >>
> >
> >Oh - we still have a show stopper. The tools code is still included in
> >source distributions. We need to fix this prior to release.
>
>
> I have the fix in CVS now (hopefully).
Not including tools/ is going to cause lots of problems for users of the
source distribution:
1) Half the targets in the src distro won't work. Targets like 'dist'
and 'docs' *require* jars from tools/lib
2) We can't have this fancy Ant 1.5-specific stuff in build.xml, because
we can't reasonably expect end users to have Ant 1.5.
3) Our build.xml must work with AND without the tools directory. This
leads to a hack-filled build.xml. An example: tools/ext/logkit.jar is
copied to lib/ in the src distro. But it still doesn't build, because
elsewhere, lib/logkit*.jar is explicitly excluded..
4) We now need two BUILDING files, containing two different sets of
instructions. The CVS version says "type ./build.sh"; the src distro
one says "download Ant 1.4 and type 'ant'".
I think overall, this counts as a showstopper; we *at least* need a
resolution to 3), because otherwise the src distro is plain broken.
I have a Cunning Plan (tm) for how to solve most of these problems in a
clean way... :)
Fact: if we don't include tools/, we need to lose some of the
functionality from build.xml. No way around it.
Simple solution: maintain two build.xml files, one a cut-down version
for the source distribution.
But that's horrible, because we have to maintain near-identical two
build files.
So...
How about we keep our one build.xml, and in it's 'src-dist' target,
apply a stylesheet to build.xml *itself*, and remove all targets that
would break without tools/. Ie, we have:
<property name="build2srcbuild" value="${tools.dir}/stripbuild.xsl"/>
..
<style style="${build2srcbuild}" in="build.xml" out="${src.dist.dir}/build.xml"/>
Then in 'stripbuild.xsl', we strip targets like 'dist' and 'docs'. We can
also convert from Ant 1.5 syntax to Ant 1.4.
That's the basic idea. Now for a nice refinement...
Instead of just removing those targets that rely on tools/, we can print
a message saying "Please download the Avalon Tools distribution from
..., and extract to the 'tools' directory". We then have
Avalon-tools-1.4.tar.gz somewhere for users to download.
That way, if users want the extra targets, they can have them if they
download the extra package.
For example, our 'stripbuild.xsl' file would replace the 'docs' target
with the following:
<target name="tools_check">
<condition property="tools.present">
<available file="${tools.dir}" type="dir"/>
</condition>
</target>
<target name="notools_msg" unless="tools.present">
<echo message="--------------------------------------------------------------"/>
<echo message="This target requires extra jars in order to run. These may be "/>
<echo message=" downloaded from ${tools.url}. Please extract these jars to "/>
<echo message=" the ${tools.dir} directory, and re-run this target. "/>
<echo message="--------------------------------------------------------------"/>
</target>
<target name="docs" depends="tools_check, notools_msg" if="tools.present">
... (same contents as before)
</target>
So I think it's a pretty neat compromise :)
- We only need to maintain one build.xml
- The source distribution is small by default, and contains only the
tasks that a casual user needs to build.
- If the casual user wants to run a fancier target, they have a clear
upgrade path. We could even automate it with a HTTP get task.
What do people think? In particular, what do we do now? Three options:
1. Go with this proposed solution (needs writing an xsl, lots of testing)
2. Re-add the tools/ directory for this release
3. Work around the problem for now; fix the critical bugs, document that
half the targets won't work, etc.
I obviously prefer 1, and would help write it. If we choose 3, I can
help with that too.
--Jeff
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon src distro won't build (Re: [Code Freeze] Avalon should be in code freeze)
Posted by Jeff Turner <je...@socialchange.net.au>.
On Mon, Dec 10, 2001 at 12:48:23PM -0500, Berin Loritsch wrote:
> Jeff Turner wrote:
[..]
> >>>Oh - we still have a show stopper. The tools code is still included in
> >>>source distributions. We need to fix this prior to release.
> >>>
> >>
> >>I have the fix in CVS now (hopefully).
> >>
>
>
> The more serious issues in build.xml (like no docs for the binary distribution)
> have been handled.
>
> I also updated the BUILDING file so that it handles both cases.
>
> As to the other issues, are they addressed by the new BUILDING file?
> If not, please do the piece that works reliably and is quick to implement.
Okay, I'll defer the XSLT thing till after 4.1, where it can be done as
part of the larger cleanup Pete mentioned.
So..
>> 1) Half the targets in the src distro won't work. Targets like 'dist'
>> and 'docs' *require* jars from tools/lib
To be solved later; documented for now in BUILDING
>> 2) We can't have this fancy Ant 1.5-specific stuff in build.xml,
>> because we can't reasonably expect end users to have Ant 1.5.
Fixed.
>> 3) Our build.xml must work with AND without the tools directory. This
>> leads to a hack-filled build.xml. An example: tools/ext/logkit.jar
>> is copied to lib/ in the src distro. But it still doesn't build,
>> because elsewhere, lib/logkit*.jar is explicitly excluded..
Removed the explicit exclude; fixed.
>> 4) We now need two BUILDING files, containing two different sets of
>> instructions. The CVS version says "type ./build.sh"; the src
>> distro one says "download Ant 1.4 and type 'ant'".
Fixed by Berin.
I'm +1 on a release.
--Jeff
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Unresolved Issues? (was Re: Avalon src distro won't build)
Posted by Jeff Turner <je...@socialchange.net.au>.
On Tue, Dec 11, 2001 at 02:31:26PM +1100, Peter Donald wrote:
> On Tue, 11 Dec 2001 06:05, Berin Loritsch wrote:
> > The BUILDING text file was updated to address some concerns with the ANT
> > file. Also, build.xml was updated to fix some issues with building the
> > distributions.
> >
> > Are there any other issues that are left?
>
> Can BUILDING be renamed to BUILDING.txt (to make it easier for win32 users)
> and also could it actually be included in distribution ;)
Done. I also changed README.txt, LICENSE.txt and the others (except
KEYS, which is read by tools like gpg, not humans).
While doing so, I found cornerstone's build to be very broken. Half the
apps/*/build.xml's only build from their directory, not when called from
the root build.xml. There's broken refs to tools/lib/xerces.jar all over
the place. Ick. Major build rejig required, best done if/when tools gets
turfed out I suppose..
--Jeff
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Unresolved Issues? (was Re: Avalon src distro won't build)
Posted by Peter Donald <pe...@apache.org>.
On Tue, 11 Dec 2001 06:05, Berin Loritsch wrote:
> The BUILDING text file was updated to address some concerns with the ANT
> file. Also, build.xml was updated to fix some issues with building the
> distributions.
>
> Are there any other issues that are left?
Can BUILDING be renamed to BUILDING.txt (to make it easier for win32 users)
and also could it actually be included in distribution ;)
I would prefer if big warning messages were printed if you tried to use some
feature (ie doc generation) that used libs that were not present. Though this
is not something to hold up a release for .
--
Cheers,
Pete
---------------------------------------------------
"If you don't know where you want to go, we'll make
sure you get taken."
Microsoft ad slogan, translated into Japanese.
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Unresolved Issues? (was Re: Avalon src distro won't build)
Posted by Berin Loritsch <bl...@apache.org>.
The BUILDING text file was updated to address some concerns with the ANT file.
Also, build.xml was updated to fix some issues with building the distributions.
Are there any other issues that are left?
Have we adequately addressed our concerns?
If possible I would like to get this out tomorrow (it is too late in the day
to get meaningful feedback in time to do a whole lot about it).
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon src distro won't build (Re: [Code Freeze] Avalon should be in code freeze)
Posted by Berin Loritsch <bl...@apache.org>.
Jeff Turner wrote:
> On Sat, Dec 08, 2001 at 11:12:41AM -0500, Berin Loritsch wrote:
>
>>Peter Donald wrote:
>>
>>
>>>On Sat, 8 Dec 2001 01:17, Berin Loritsch wrote:
>>>
>>>
>>>>I realized my last post should have had a new title so as not to be lost.
>>>>Please come up with issues for Avalon Framework--and we will decide if it
>>>>is a showstopper, a minor but allowable change (spelling/correction of
>>>>documentation), or something that will be placed on hold.
>>>>
>>>>The CVS should have 100% back compatible code. If this is not the case,
>>>>please alert me ASAP.
>>>>
>>>>
>>>Oh - we still have a show stopper. The tools code is still included in
>>>source distributions. We need to fix this prior to release.
>>>
>>
>>I have the fix in CVS now (hopefully).
>>
The more serious issues in build.xml (like no docs for the binary distribution)
have been handled.
I also updated the BUILDING file so that it handles both cases.
As to the other issues, are they addressed by the new BUILDING file?
If not, please do the piece that works reliably and is quick to implement.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon src distro won't build (Re: [Code Freeze] Avalon should be in code freeze)
Posted by Peter Donald <pe...@apache.org>.
On Mon, 10 Dec 2001 23:16, Jeff Turner wrote:
> On Sat, Dec 08, 2001 at 11:12:41AM -0500, Berin Loritsch wrote:
> > Peter Donald wrote:
> > >On Sat, 8 Dec 2001 01:17, Berin Loritsch wrote:
> > >>I realized my last post should have had a new title so as not to be
> > >> lost. Please come up with issues for Avalon Framework--and we will
> > >> decide if it is a showstopper, a minor but allowable change
> > >> (spelling/correction of documentation), or something that will be
> > >> placed on hold.
> > >>
> > >>The CVS should have 100% back compatible code. If this is not the
> > >> case, please alert me ASAP.
> > >
> > >Oh - we still have a show stopper. The tools code is still included in
> > >source distributions. We need to fix this prior to release.
> >
> > I have the fix in CVS now (hopefully).
>
> Not including tools/ is going to cause lots of problems for users of the
> source distribution:
>
> 1) Half the targets in the src distro won't work. Targets like 'dist'
> and 'docs' *require* jars from tools/lib
In other avalon projects they won't even build without the lib directory ;(
> 2) We can't have this fancy Ant 1.5-specific stuff in build.xml, because
> we can't reasonably expect end users to have Ant 1.5.
do we have any left? It should be all 1.4.1, if not I haven't used IDEA with
that project yet ;)
> 3) Our build.xml must work with AND without the tools directory. This
> leads to a hack-filled build.xml. An example: tools/ext/logkit.jar is
> copied to lib/ in the src distro. But it still doesn't build, because
> elsewhere, lib/logkit*.jar is explicitly excluded..
yup - yuck.
> 4) We now need two BUILDING files, containing two different sets of
> instructions. The CVS version says "type ./build.sh"; the src distro
> one says "download Ant 1.4 and type 'ant'".
yucko.
> I think overall, this counts as a showstopper; we *at least* need a
> resolution to 3), because otherwise the src distro is plain broken.
yep.
> I have a Cunning Plan (tm) for how to solve most of these problems in a
> clean way... :)
...snip...
> What do people think? In particular, what do we do now? Three options:
>
> 1. Go with this proposed solution (needs writing an xsl, lots of testing)
> 2. Re-add the tools/ directory for this release
> 3. Work around the problem for now; fix the critical bugs, document that
> half the targets won't work, etc.
>
> I obviously prefer 1, and would help write it. If we choose 3, I can
> help with that too.
Personally I would actually prefer we just not include tools in CVS or in the
distributions. If it wasn't for the cocoon stuff I would have done that by
now but as I am sure I would break stuff I haven't.
I would prefer instructions like
If you want to build documentation then
- Download Cocoon 2.0.. from X
- Extract it to a directory like Y
- specify properties a, b and c in build.properties/ant.properties
- type ant docs
For all our external jars that we are dependent on (JMX, Xerces, JDom,
servlet API, jaxen etc) you could download them separately to build relevent
parts (if parts were optional) or flat out require them (like an XML parser)
and specify them in properties files.
For interdependencies between our own projects then I would say that it is
acceptable to include jars or at least redirect users to released version of
other toolkit. ie instead of distributing framework we could redirect to a
released version of said framework. However if we were depending on CVS
versions of another product then we would include it in distribution.
I used to not prefer this but now that ant and some of the other libs
(logkit/framework) are stablizing then I think this woul dbe acceptable.
Thoughts ?
--
Cheers,
Pete
------------------------------------------
I just hate 'yes' men, don't you Smithers?
------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>