cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gallardo <agalla...@agssa.net>
Subject Re: [VOTE] Release 2.1.9
Date Wed, 22 Feb 2006 23:01:18 GMT
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 <uv@odoko.co.uk>
>> 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-----



Mime
View raw message