Sam Ruby wrote:
>
> 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.
>
> 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.
>
The Turbine dependency issue is solved now since I updated it to the latest
TDK over the week-end. Only the Castor dependency remains an issue.
I'll try to regenerate the Cator API code this evening with castor 8.11 and
check if it solves the issue.
I'm not sure it's worth investing more time in solving this issue since
there are very good chances that we drop the Castor geneated API in the
near future thus removing this dependency.
I think our indecision about Castor generated API support is the main reason
why the dependency is not updated.
> 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.
>
> 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.
>
> In the short time that this build system has been in existence, I can
> already point to several success stories.
>
I think it's a very valuable tool because it increases the visibility in the
the other projects which we depend upon. It's already in my bookmarks :)
> 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?
>
> - Sam Ruby
>
Of course, especially if you can help us answer of persistence problem:
dhould we stick to Castor generated API, should we use Castor mapping file or
should we drop Castor altogether and use another persistence mechanism ?
--
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]
