You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/03/21 14:55:32 UTC
Cocoon Gump Status
It seems that we are converging toward a stable gump setup. This is very
nice and very useful to help us solidify our contracts and make it
visible for other projects underneath our food chain to watch us.
Currently, 6 blocks fail. I'm listing the problems
- databases -> doesn't pickup mock classes
- jsp -> doesn't pickup mock classes
these are going to be fixed as soon as I figure out what's wrong, but
this appears a trivial fix. It could well be that latest gump run did a
cvs update right before my fixes landed in CVS. So I'm going to wait for
next gump run.
- php -> requires PHPServlet to be setup. This needs to be added in
Gump. Hopefully Sam will help us on this since he's the author of that
package.
- web3 -> doesn't pickup mock classes + depends on Doug Lea
concurrently library. I just found it on the gump repository so I'm
adding this dependency right away.
the really broken ones are:
- fop
- slide
where we depend on classes now missing.
Does anybody know what's wrong with these packages and how hard it would
be to solve the issues?
TIA
Stefano.
Re: Cocoon Gump Status
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Stefano Mazzocchi wrote:
> So, what do we do?
Good question.
a) Fix GUMP so that it can take stuff from a branch.
b) Include a Cocoon owned stub.
c) Do nothing.
In either case, check
http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization
before it goes stale.
Send nag mails to Jeremias who promised to do something but buried
himself into the licensing stuff instead (which is, admittedly, much
more necessary for the next FOP release).
J.Pietschmann
Re: Cocoon Gump Status
Posted by Stefano Mazzocchi <st...@apache.org>.
J.Pietschmann wrote:
> Santiago Gala wrote:
>
>> Nagging FOP developers to deprecate those classes but keep an
>> implementation in term of the new ones at least during one full
>> development/release cycle?
>
>
> Wont help in this case. The old API was really botched.
So, what do we do?
Stefano.
Re: Cocoon Gump Status
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Santiago Gala wrote:
> Nagging FOP developers to deprecate those classes but keep an
> implementation in term of the new ones at least during one full
> development/release cycle?
Wont help in this case. The old API was really botched.
J.Pietschmann
Re: Cocoon Gump Status
Posted by Stefano Mazzocchi <st...@apache.org>.
Vadim Gritsenko wrote:
> <sidenote>Is it good idea to start software (have first release) with
> deprecations? :)</sidenote>
Is it a good idea to release software with a 0.x version? ;-)
When I released Cocoon 1.0, I felt that 0.01alpha was a much better
indication of its functionality.
But if I did so, probably all of you wouldn't be here by now :)
Food for thought.
Stefano.
Re: Cocoon Gump Status
Posted by Vadim Gritsenko <va...@verizon.net>.
Santiago Gala wrote:
> Vadim Gritsenko wrote:
...
>>
>> They have those classes. In the branch. Same situation as we had
>> recently before repository split-up.
>>
>
> But, If they have documented
> (http://xml.apache.org/fop/embedding.html) the use of the Options
> class, they should be aware that users are not like computers, i.e.
> they need time to understand changes, plan for migration and migrate.
Yes. deprecation warning should be there (like: please be warned that in
2 years this class will be gone (see below)).
> They could keep them in HEAD, and have them in the first 1.0 release,
> deprecated.
<sidenote>Is it good idea to start software (have first release) with
deprecations? :)</sidenote>
> Or, alternatively, a "fop-020-compatibility.jar" could be kept in HEAD
> with impls of those missing classes, to ease migration. This would
> bring the extra added value of having users able to test the new stuff
> without having to change code, while keeping them conscious that they
> are relying on deprecated, dangerous stuff.
Nah, I don't agree with this. If I plan to maintain fop-020-branch for
2-3 years and want to continue working on some fop-070 during this time,
I don't want these classes be in fop-070 for two years.
2 years considered by everybody here as a long enough time to migrate to
next version. If you haven't, may be you don't need this fop-070 at all...
OTOH, if release cycle is much shorter, then I agree with you,
compatibility jar is a must. But only if software has been released. All
of this is non-applicable to alpha software.
Vadim
Re: Cocoon Gump Status
Posted by Santiago Gala <sg...@hisitech.com>.
Vadim Gritsenko wrote:
> Santiago Gala wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> Stefano Mazzocchi wrote:
>>>
>>>> It seems that we are converging toward a stable gump setup. This is
>>>> very nice and very useful to help us solidify our contracts and make
>>>> it visible for other projects underneath our food chain to watch us.
>>>>
>>>> Currently, 6 blocks fail. I'm listing the problems
>>>
>>>
>>>
>>> <snip/>
>>>
>>>> the really broken ones are:
>>>>
>>>> - fop
>>>
>>>
>>>
>>>
>>> Latest FOP release is fop-0.20.5rc2 coming from the maintainance
>>> branch. This release still has org.apache.fop.apps.Options class. But
>>> in CVS head it was removed (in favor of something better, I presume.
>>> AFAIK fop is moving towards Avalon).
>>>
>>> As we recenlty agreed, Cocoon should base on the released stuff.
>>> Thus, I don't see how GUMP could be fixed.
>>>
>>
>> Nagging FOP developers to deprecate those classes but keep an
>> implementation in term of the new ones at least during one full
>> development/release cycle?
>
>
>
> They have those classes. In the branch. Same situation as we had
> recently before repository split-up.
>
But, If they have documented (http://xml.apache.org/fop/embedding.html)
the use of the Options class, they should be aware that users are not
like computers, i.e. they need time to understand changes, plan for
migration and migrate.
They could keep them in HEAD, and have them in the first 1.0 release,
deprecated. Or, alternatively, a "fop-020-compatibility.jar" could be
kept in HEAD with impls of those missing classes, to ease migration.
This would bring the extra added value of having users able to test the
new stuff without having to change code, while keeping them conscious
that they are relying on deprecated, dangerous stuff.
I think (I'm not sure) this is the approach Avalon is taking.
The good thing about gump is that it makes us aware of such stuff much
in advance.
> Vadim
>
--
Santiago Gala
High Sierra Technology, S.L. (http://hisitech.com)
http://memojo.com?page=SantiagoGalaBlog
Re: Cocoon Gump Status
Posted by Vadim Gritsenko <va...@verizon.net>.
Santiago Gala wrote:
> Vadim Gritsenko wrote:
>
>> Stefano Mazzocchi wrote:
>>
>>> It seems that we are converging toward a stable gump setup. This is
>>> very nice and very useful to help us solidify our contracts and make
>>> it visible for other projects underneath our food chain to watch us.
>>>
>>> Currently, 6 blocks fail. I'm listing the problems
>>
>>
>> <snip/>
>>
>>> the really broken ones are:
>>>
>>> - fop
>>
>>
>>
>> Latest FOP release is fop-0.20.5rc2 coming from the maintainance
>> branch. This release still has org.apache.fop.apps.Options class. But
>> in CVS head it was removed (in favor of something better, I presume.
>> AFAIK fop is moving towards Avalon).
>>
>> As we recenlty agreed, Cocoon should base on the released stuff.
>> Thus, I don't see how GUMP could be fixed.
>>
>
> Nagging FOP developers to deprecate those classes but keep an
> implementation in term of the new ones at least during one full
> development/release cycle?
They have those classes. In the branch. Same situation as we had
recently before repository split-up.
Vadim
Re: Cocoon Gump Status
Posted by Santiago Gala <sg...@hisitech.com>.
Vadim Gritsenko wrote:
> Stefano Mazzocchi wrote:
>
>> It seems that we are converging toward a stable gump setup. This is
>> very nice and very useful to help us solidify our contracts and make
>> it visible for other projects underneath our food chain to watch us.
>>
>> Currently, 6 blocks fail. I'm listing the problems
>
>
> <snip/>
>
>> the really broken ones are:
>>
>> - fop
>
>
>
> Latest FOP release is fop-0.20.5rc2 coming from the maintainance branch.
> This release still has org.apache.fop.apps.Options class. But in CVS
> head it was removed (in favor of something better, I presume. AFAIK fop
> is moving towards Avalon).
>
> As we recenlty agreed, Cocoon should base on the released stuff. Thus, I
> don't see how GUMP could be fixed.
>
Nagging FOP developers to deprecate those classes but keep an
implementation in term of the new ones at least during one full
development/release cycle?
I think this is one of the best things gump brings. I'm not sure if it
will be possible here, though.
> Vadim
>
--
Santiago Gala
High Sierra Technology, S.L. (http://hisitech.com)
http://memojo.com?page=SantiagoGalaBlog
Re: Cocoon Gump Status
Posted by Vadim Gritsenko <va...@verizon.net>.
Stefano Mazzocchi wrote:
> It seems that we are converging toward a stable gump setup. This is
> very nice and very useful to help us solidify our contracts and make
> it visible for other projects underneath our food chain to watch us.
>
> Currently, 6 blocks fail. I'm listing the problems
<snip/>
> the really broken ones are:
>
> - fop
Latest FOP release is fop-0.20.5rc2 coming from the maintainance branch.
This release still has org.apache.fop.apps.Options class. But in CVS
head it was removed (in favor of something better, I presume. AFAIK fop
is moving towards Avalon).
As we recenlty agreed, Cocoon should base on the released stuff. Thus, I
don't see how GUMP could be fixed.
Vadim