Santiago Gala wrote:
>
> I can already pinpoint a very importan issue with the data
> you are giving: while cocoon2 succeeds, cocoon fails.
All you are pointing out is that I haven't gotten around to solving that
problem yet
> This is due to the fact that cocoon is a production project
> (legacy, I would say), that has been frozen WRT features and
> it is only bugfixed (I don't say that it can't be updated to
> work with the next version of fop, but the main developers
> are probably concentrating these efforts WRT cocoon2). Also,
> they use turbine services that have changed lately.
Not exactly. You see, I'm a committer to cocoon so I felt that I could
solve this one myself, so I've focused first on projects where I may need
to spend some time convincing some recalcitrant individuals. ;-)
> It is legitimate, as they don't want to break stability of
> a product that is being used in production. While bug fixing
> will continue, I don't expect major updates.
Cocoon 2 is not out yet, and even if it were released *today* there would
need to be a period of time of transition. Locking Cocoon 1 users into
specific versions of prereqs will make their migration harder as it will
have to be an all or nothing event.
> Another point: cocoon2 works against xalan2. How do you decide
> about major versions of other components? i.e. how do you decide
> to test against xalan2 or xalan1?
Major releases should be handled differently in that I feel that in making
such a major release the authors are more entitled to break compatibility.
Once I get past this "bootstrapping" phase where I can successfully build
products against the major version that they are intended for, I plan to
try to start "upgrading" products systematically. Once I get a clean
build, I can easily do trial runs with different configurations to see what
the consequences are.
> I think, as you can see from previous mails, that there should
> be a way to freeze "major" releases of depended modules, while
> having the system test for problems in minor cvs updates.
Why not do both in parallel?
You build daily using a stable version. I build daily using the latest and
greatest. In this way you get both stability and early warning of
impending changes.
> Yes, but see above. Sometimes the api changes come through
> revision of specs, and I don't want my agenda depending on the
> fop-w3c agenda. If we want to encourage experimentation, we
> should know that some projects will have incompatible changes
> before apis get frozen. Should this stop efforts like adding
> PDF support to jetspeed portlets?
Cocoon2 obviously has this problem too. It looks like for the moment,
their gameplan is to not let the incompatibilities compound too far.
Nobody will get too upset if the tinderbox breaks from time to time. In
fact, it is expected. And it is recognized that there will be times that
it is not practical to fix the problem immediately. All I am providing is
an opportunity for you to be aware of the problems, and in return I would
like to ask that the jetspeed team remain aware of any issues that may be
raised from time to time.
> xalan/xalan2 I'm not sure if they can co-exist so what if
> you integrate a xalan project and a xalan2 one?
I originally took the <style> task to Ant based on XT and added support for
Xalan. Since then, I've added support for Xalan2. It will adapt
dynamically. A better approach would be to encourage projects to upgrade
to JAXP 1.1, and backport the TraX interfaces to Xalan 1. These are the
types of issues I intend to champion.
> I agree that our concerns are possibly extreme, and that in
> practice things will be simpler :-)
Agreed! ;-)
> I think that we are already current WRT turbine and ecs (I saw
> that Raphael did it already), but the castor stuff will sure
> take more time.
Not knowing castor, xml-schema, or alexandria, I got Alexandria updated in
about a half a day. I've got a plane ride coming up this evening, meaning
that I have some idle time on my hands...so I could do the same for
jetspeed...
- Sam Ruby
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
