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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
