Giacomo Pati wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 22 Feb 2006, Upayavira wrote:
Date: Wed, 22 Feb 2006 06:49:39 -0800
From: Upayavira <[EMAIL PROTECTED]>
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: [VOTE] Release 2.1.9
Ralph Goers wrote:
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
> > > > I believe the alternatives that were mentioned were to
either get > > > the OK from legal or not deliver the jcr block as
part of the > > > release. If the answer above means you don't
feel we have > > > permission than the release should go out
without JCR.
> > > > > The API can be redistributed with an implementation, and
we do > > redistribute the implementation. Does this give use the
permission to > > redistribute the API with the implementation?
IANAL and I don't > > know...
> > > > > Ok, so how do we solve this issue? I understand the
comment from Roy
> that we are not allowed to ship the jar right now. I personally
would go
> the easiest way: remove the jcr api from the repo, disable the
block by
> default, add a readme that people have to download the jar and
put it
> into local libs to build the block.
My understanding from Roy is that, if we ship Jackrabbit, we don't
need the JCR jar, as Jackrabbit provides its own impl. Does it still
work if you just remove the JCR jar? Or did I misunderstand something?
No, this is not correct. The jackrabbit-jar is only an implementation
of the JCR APIs. Rereading Roys mail:
"The JCR API, in contrast, will either already be present in the J2SE
engine (with or without an implementation) or must be downloaded and
installed by the user."
IMO for Cocoon this means that our users needs to get/have the jcr.jar
by themself, either donwloading it by hand from the SUN/Day site and
install it as an Java extension or other mechanism (i.e. global lib
dir of a target container) or use a scritp (read Maven) to get it.
Now, the only way I see ATM is to extend the Ant-script for the
repository block to download that jcr.jar from the Day site and put it
to the correct location for deployment/build (this is meant for the
branch).
Or add some mock classes in our base code. Se far, we have been doing it
for mail.jar and other jars that we don't distribute due legal reasons.
Best Regards,
Antonio Gallardo.
- -- Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)
iD8DBQFD/OdrLNdJvZjjVZARAn5CAJsH4ZCDaP5JfuXlM8Bj/ad7XP6VsQCgpQzc
HgGFORsS8vlrf9/PTxzRBfg=
=cCJL
-----END PGP SIGNATURE-----
