Sam Ruby escribió:
> Kevin A. Burton wrote:
>
> > They are called dependencies. There is NO way we can have a
> > global build system without using CVS tags for supported
> > versions. If Jetspeed it forced to work out of the Turbine
> > HEAD all the time then this is not going to work. Things
> > will be failing left and right.
>
> Things are not as black as you might think. If it hasn't been mentioned to
> you, take a look at the following URL:
>
> http://oss.software.ibm.com/developerworks/opensource/jakarta/proto/index.html
>
> The conclusion I come to is that *most* of the projects actually will build
> with the latest tip version of all of their dependencies. The ones that
> don't primarily are the ones that I haven't contacted the owners of
> (including JetSpeed). The smoketest problem is suspected to be a setup
> problem on my end. The other failures appear to be legit.
>
I can already pinpoint a very importan issue with the data you are giving: while
cocoon2 succeeds, cocoon fails.
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.
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.
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?
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.
>
> What appears to be the largest problem with JetSpeed at this moment is that
> it is considerably backlevel with its version of Castor that it supports -
> to the point where it won't work with the latest released version of that
> dependency. The reason for this is because the schema definitions conform
> to a backlevel version of that specification. Alexandria had a similar
> issue, and I created the patch to address the issue. I'm willing to help
> out here.
>
> An implication of being bound to a specific and backlevel version of a
> dependency is that if somebody wanted to compose a system with multiple
> components, there is a distinct possibility that such a system would never
> run.
>
+1 on that. I think this effort needs to be done, but I think it is too radical to
test against latest version of each package.
Examples coming to mind:
svg-batik (spec changing and the product tracking it)
fop (ditto)
xalan/xalan2 I'm not sure if they can co-exist so what if you integrate a xalan
project and a xalan2 one?
If I incorporate a PDF display facility in jetspeed, for instance, I will have to
race each time somebody touches the fop cvs. I think it is better if we can track
version 0.16 until our next release. Also, see the point about functional tests in
previous mail.
>
> In my opinion, a global build system such as the one I pointed to above is
> primarily there to benefit projects such as JetSpeed which depend on a
> large number of other products. On one hand, it should put pressure on
> projects which expose a public interface to maintain a level of backwards
> compatibility. And at the same time, it will provide an early warning of
> impending API changes that may affect you.
>
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?
>
> In the short time that this build system has been in existence, I can
> already point to several success stories.
I agree that our concerns are possibly extreme, and that in practice things will be
simpler :-)
>
>
> Of course, this can only work if there is a reasonable effort applied to
> staying current.
>
> I realize that this is a volunteer effort, but I am willing to contribute.
> Interested?
>
I am interested in staying current wrt xalan and turbine. Castor is something that
we have a proposal to drop. I (personally) don't care about castor being there or
not but I don't know it neither have plans to use it. In fact, I think that for
some processes castor is not the right thing, for instance marshalling a feed xml
(several megabytes ).
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.
>
> - Sam Ruby
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/[email protected]/>
> List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
