Ovidui (default), Diana, Vadim, From: "Ovidiu Predescu" <[EMAIL PROTECTED]> > On Wed, 22 May 2002 16:46:48 +0400, "Konstantin Piroumian" <[EMAIL PROTECTED]> wrote: > > > Hi, Cocooners! > > > > I've just made a clean checkout of Cocoon and noticed several strange > > things. > > > > 1) Running the build: > > > > >build.bat -Dinclude.webapp.libs=yes webapp > > > > results in a 17 min. building process, which includes everything is > > possible: documentation generation, apidocs, and even the scratchpad.jar > > building. Can anybody of build.xml gurus take a look at it. I don't think > > that it is the intended behavior. And I'm sure that scratchpad jar should be > > built only for 'installscratchpadwar' (is there a 'scratchpadwebapp' > > target?) target, cause it can easily break the build. > > > > 2) The set of jars in lib: > > > > commons-httpclient-20020423.jar - where is it used? > > It's used by the SOAP logicsheet and perhaps others to make HTTP requests.
Ok. > > > commons-jpath-1.0b1.jar, commons-jxpath.jar - do we need both? > > The commons-jxpath.jar was probably added by Ivelin without noticing > there's another one in there. I've fixed this. Thanks > > > xt-19991105.jar - as I remember no one objected on removing XT support > > > > There are many other JARs that have some unknown (to me) purpose. There is a > > jars.xml document that should list all the used jars, but it's out of date > > now. (Btw, Diana, can we force everybody who is adding a new jar to update > > the documentation accordingly?) <from person="Diana"> How could I, or anyone, *force* "everybody" (or anyone) to do anything here? Why would I want to? </from> Yes, you right. "Force" is a wrong word in an Open Source community. But see below what Ovidiu suggests ;) > > We can have a build.xml target which checks if jars.xml is up-to-date > with respect to the jars available in lib/. THe target will be run as > part of the build process, and it should stop the build if the file is > not up-to-date. I'll give it a shot and let you know how it works. I'd change it to a warning. It's possible to add a new JAR and don't run the build for a while - but the other users won't be happy with it ;) > > > 3) emacs directory in the root > > > > I suspect that this one comes from Ovidui. Shouldn't we place this kind of > > stuff in some common place? Say: > > dev-tools/ > > /emacs > > /xmlspy > > /jbuilder > > > > etc? > > Yes, I've added it. We should probably do what you suggest. If > dev-tools/ is a good name, I'll go ahead and add it. Any opinions? <from person="Vadim"> Can't we reuse tools/ directory for this? </from> I've discussed it with Nicola, but he wants to keep the 'tools' directory as clear as possible. He suggested to use something like 'src/resources' as those files are resources for developers. IMO, 'resources' is a very often used name and something like 'dev' or 'dev-tool' in the root would be better. > > > I am also looking for a good place for i18n supporting stylesheets. Having > > them in the samples is not a very good idea as they have nothing to do with > > the samples and can lead to confusion. > > Are these logicsheets? If so, how about putting them in the same > directory as the other logicsheets? No, they are helper stylesheets for dictionary generation, convertion, merge, etc. Maybe someday I'll create a bat file for them (or add a special target to the build) or even create a GUI application, who knows... > > > P.S. We could simply rename scratchpad to 'contrib' or 'optional' and > > provide it separately ;) > > I don't think this is a good idea. optional/ should be used for > optional things, which are stable, as opposed to things still in > development, which is the case with those in scratchpad/. Partially it was a joke. But it would be fine to separate the 'core' (or better 'most used parts') from specific or rarely used ones (SOAP, DELI, etc.). We could have a 'standart' Cocoon and an C2EE (Cocoon 2 Enterprise Edition) with all the advanced things, like Schecoon, Charts, LDAP, Portal/Authentication, etc. I've also created a 'myapp' having in mind a requirement to have a Minimal Cocoon (or a Quick Start Cocoon) and it would be fine if somebody more experienced in Ant would create a build target for it. (Or maybe give me a hint on where to start. Do we have a modular build already?). And we can have C2ME, C2SE, C2EE ;). Konstantin > > Regards, > -- > Ovidiu Predescu <[EMAIL PROTECTED]> > > >>> I'm in the job market again, check out my resume and qualifications at: > http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs ...) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
