Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <16128.195.226.6.75.1096890382.squirrel@195.226.6.75>
In-Reply-To: <200410041136.i94BabE7019737@ags01.agsoftware.dnsalias.com>
References: <15797.195.226.6.75.1096889223.squirrel@195.226.6.75>
    <200410041136.i94BabE7019737@ags01.agsoftware.dnsalias.com>
Date: Mon, 4 Oct 2004 05:46:22 -0600 (CST)
Subject: RE: Compile errors with 2.1.x
From: "Antonio Gallardo" <agallardo@agssa.net>
To: dev@cocoon.apache.org
User-Agent: SquirrelMail/1.4.3a-1
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal

Carsten Ziegeler dijo:
> Antonio Gallardo wrote:
>>
>> Carsten Ziegeler dijo:
>> > It seems that the current SVN of 2.1.x does not build. The
>> deprecated
>> > block requires the now missing Jisp classes.
>>
>> I think the problem is only in the old store stuff. Maybe we
>> can delete that too?
>>
>> The sources in question are:
>>
>> src/deprecated/java/org/apache/cocoon/components/store/impl/De
>> faultPersistentStore.java
>> src/deprecated/java/org/apache/cocoon/components/store/JispStr
>> ingKey.java
>>
>> WDYT?
>>
> Hmm, our policy says that we remove deprecated code in the next
> minor version change (if we remove it), so from that pov we
> should leave the classes in 2.1.x.
> Now, we could either readd the jisp jar or add a mock class for
> the deprecated block.
> Or we could say that this is a special case, where we don't have
> to follow our deprecation/removal policy.
> Don't know which is best.

I think in this "special" case we can remove the jisp support. Remember
there were problems using jisp. So, I think even users using deprecated
stuff should avoid using jisp, if they expect stability. And at least, we
cannot also update the jar because of the new GPL. Then we have only 2
options:

1-Stay with the buggy code, even when we know about that or...
2-Remove the buggy code. Currently, we have 2 new cache solutions.

I will prefer (2).

Do you think we need a vote for that? Or to request users feedback (in
users mailist)?

I know this must be solved fast if we want to release 2.1.6 after GT2004.

Best Regards,

Antonio Gallardo.