cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Piroumian <kpiroum...@apache.org>
Subject Re: [WARN] Strange things
Date Thu, 23 May 2002 10:00:26 GMT
Ovidui (default), Diana, Vadim,

From: "Ovidiu Predescu" <ovidiu@cup.hp.com>
> On Wed, 22 May 2002 16:46:48 +0400, "Konstantin Piroumian"
<kpiroumian@apache.org> 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 <ovidiu@cup.hp.com>
>
> >>> 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message