Sam Ruby wrote:
>
> Santiago Gala wrote:
> >
> > 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. ;-)
>
I hope you're not in this forum looking for these kind of individuals... ;)
> > 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.
>
+1.
Just be aware that the building process will only expose changes in
the java source files and not in the auxillary files such as configuration
files which may have major impact on the software.
>
> 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.
>
Agreed, especially since Jon sends to the mailing list the output of the
build scripts, we don't even have to go to the website... ;)
> > 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...
>
I'm trying it right now, I've already updated the build file fixing the
regeneration tasks and updated the JCM xsd.
My main concern with the update is that I believe that Kevin manually
modified some auto-generated java files... :(
--
Raphaël Luta - [EMAIL PROTECTED]
Vivendi Universal Networks - Services Manager / Paris
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
