cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@cup.hp.com>
Subject Re: [C2]: Beta 1 - It's there....
Date Wed, 06 Jun 2001 20:54:34 GMT
On Wed, 6 Jun 2001 22:23:06 +0200 (CEST), giacomo <giacomo@apache.org> wrote:

> > > Now the CVS stuff:
> > > - I tagged the beta with cocoon_20_b1
> > > - I checked in the build.xml with the new version 2.1-dev
> > > - I made a branch of cocoon_20_b1 with the name cocoon_20
> > > - I checked in the build.xml with the new version 2.0b1-dev under
> > >   the branch cocoon_20_branch.
> > > So the HEAD is the 2.1 version and the 2.0 is a branch.
> >
> > Yes, that good. I assume all the new development will happen only on
> > the HEAD and bug fixes will be applied to both HEAD and 2.0b1-dev
> > branch. Is this the common understanding?
> 
> It depends :) Adding components can certainly be done on the
> cocoon_20_branch (after voting for) but general API chnges surely not.

Ah, you're right, I forgot this is still a beta, not the final release!

However is it correct to assume the main CVS branch will have all the
changes the cocoon_20_branch has, plus some more?

The reason I'm asking is because we want to offer Cocoon as part of
our App Server offering, and there are some logistics in terms of
which source code tree we build on. Internally I maintain a CVS
repository, which is a copy of Cocoon's CVS, plus the changes we do
internally. These changes will eventually be submitted to Cocoon, but
for our team to be able to develop cooperatively is very important to
have a common repository. And since we don't have CVS write access
(yet ;-), this is the only option.

> > > Now, some problems I had with building the distribution:
> > > 1. I had no public pgp key suitable for signing the dist....
> > >    So I had to create a new one.
> > > 2. Operations on daedalus are slow
> > >    I used my own machine instead and had to transfer the
> > >    files (Beforehand I had to install the jdk 1.2.2)
> > > 3. The build docs is not working on daedalus. The build
> > >    ends with an exception telling that a lib (I think it
> > >    was libXm.so) is missing.
> > >    Perhaps someone could check this?
> >
> > Perhaps somebody needs to install LessTif on daedalus so the image
> > generation processing could work fine. I don't have access to the
> > machine so I can't help.
> 
> Not sure if this will help? Do you have any experience with LessTif and
> C2? I've use Xvfb on X-less server to fix it.

I don't have experience with Xvfb, but I assume it only gives you the
XWindows-like server. What LessTif gives you is the set of libraries
some applications depend on. But don't ask me which, because I thought
the JVM only needs the X11 libraries to do all the graphics
manipulation. If Carsten is right and the missing library is libXm.so,
then some component in the build process needs the Motif libXm.so
library. LessTif will provide that library.


Regards,
-- 
Ovidiu Predescu <ovidiu@cup.hp.com>
http://orion.nsr.hp.com/ (inside HP's firewall only)
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

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


Mime
View raw message