Re: [Fwd: Re: [architecture] Re: JPackages and ObjectWeb]

[Eric Bruneton <Eric.Bruneton@xxxxxxxxxxxxxxxxxxxx>]

David Walluck wrote:
> Keep in mind that the following comments or `criticisms' (marked
> with a `*') are not meant to be rude. Virtually *every* Java
> project suffers from these same symptoms I'm about to mention, and
> the JPackage Project exists as a volunteer effort only to help
> these issues go away.

> >Anyway, I've copied the subset of Jonathan required by Fractal in
> > the
>
> * For JPackage purposes, this isn't a good idea at all. We want to
> use the official latest version of jonathan. Our policy dictates
> that we must remove any internal sources like these and instead use
> the official external jar.

as Gerard said the Jonathan case is very special.

> A couple questions about julia.
>
> 1. Is it a separate project or is the only place to find it in
> fractal? I mean, is julia a part of fractal or it's own package?

Julia is an implementation of Fractal (the Fractal module/jar only 
contains Java interfaces). It is a sub-project of the Fractal 
project. Modules that depend on Julia depend in fact on the presence 
of a Fractal implementation, not necessarily Julia itself.

> 2. I didn't realize julia needed cldc. Yet, somehow I was able to
> build it. I'll have to look at this.

the cldc jar is only used to verify that the Julia source code doesn't 
use APIs that are not in the CLDC API.

> Anyway, the dependencies you listed for each jar is a great help to
> me. It will translate directly to the rpm spec file that I am
> creating. Thanks.

be careful: these are dependencies between CVS modules (some modules 
provide several jars. However, if a module A requires a module B, it 
often - but not always - requires all the jars provided by B). The 
real jar file dependencies can be found by looking in the 'externals' 
and 'config' directories (for R and BR, respectively), and in the 
'lib' directories (specific R dependencies to run the tests and/or 
the examples).

> * This is yet another thing that causes problems. How is anyone
> ever to know what the latest version even is? Things like this may
> lead to fragmentation of projects which depend on jonathan. For
> example, jonas uses 3.1. This is a good idea to use the latest
> available release. The problem is, what happens when 3.1 is
> incompatible with 3.0a10? We in JPackage would have to patch every
> project, or as a last resort include both versions.
> ...
> Modularity is always good. We tend not to ship our own packages
> with say, the seven or so listed, but I could do this if you prefer
> that each module get its own package. Generally, we make a
> directory and put each jar into there. So anyone who installs the
> fractal RPM would get all seven jars. Javadocs and examples are
> packages separately, however. Anyway, whichever way you prefer is
> fine.
> ...
> * One last thing, is that *all* objectweb projects seem to not
> honor the CLASSPATH in build.xml. This means we must go into
> `externals' or `lib' or whatever directory you use, and change the
> jars. Using the CLASSPATH would be much preferred.

if you have precise instructions (or tutorials, or example projects) 
on how to organize Java projects, how to manage their dependencies, 
and how to build them, so that they can easily be packaged in rpm or 
debian packages, we can try to take them into account in the Fractal 
project (if you want, we can also include your rpm spec files in the 
CVS, and integrate the rpm building tasks in the build.xml files)

Eric