[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fwd: Update on Ozone's library...]



On Mon, 26 Mar 2001, David Li wrote:
> > On Mon, 26 Mar 2001, David Li wrote:
> > > >%_It seems that the dev list is like of quiet.
> > 
> > I did reply on your original post in the dev list. Here it is again:
> > 
> 
> Hmm... I really have to check what's wrong with my dev list
> subscription. I don't seem to get that email. Sorry to spam the users
> list.

cross posting over ozone-users and ozone-dev does not work.

> 
> > Thanks for your help, David. I will take a look at your changes as soon as
> > possible.
> > 
> 
> Let me know if there is anything I can help.
> 
> > Anyway, JUnit, Castor and Ant are just needed to build the ozone server. You
> > should never get in touch with them if you just program ozone clients. The only
> > problem could be the ojvm command to start ozone applications. This builds
> > the CLASSPATH so that the ozone libraries are inserted before the rest of the
> > CLASSPATH but it should be no problem to change this. Or did I miss something?
> > 
> 
> I really need to build Ozone for our purpose. We are looking at Ozone
> for two possible extensions. 
> 
> 1. RDF databaes. Ozone seems to be ideal storage for RDF and fit quite
> well with W3C's interfaces proposal. The current status is that we are
> trying to get the alpha out as soon as possible.
We are looking forward ;)

> 2. A deductive database based on either RDF or Ozone itself. We want to
> get something like W3C Metalog or N3 to work with our RDF
> implementation. Look like we will have to implement something like Rete
> algorithm for Ozone. We are debeting whether to go generic with Ozone or
> specific with our RDF implementation.

Wow! What's a deductive database? or a Rete algorithm?

> 
> > > Also, I'd like to suggest putting the version number of the included
> > > jars. It makes it easier to integrate.
> > 
> > Hmmm... I'm not sure. If we do so then we would have to add/delete each new
> > version of a library instead of just commit/update it. CVS would be unable to
> > build diffs then.
> > 
> 
> Well... It should be fine for the jar files. Jars are binary files and
> there is a little to get the diff in those files except saving something
> in updating. However, the diff and patch used by CVS doesn't perform
> well in binary merge.

I like the idea of Michael to put version numbers somewhere in the CHANGES file
and/or in the revision log of the CVS file. What do you think?

> On the other hand, having the version numbers in the jar files makes
> integrating Ozone into other projects easier. We use junit and castor in
> our project as well. Have two conflict version (especially Castor) is a
> big pain in the butt. 

I still beliefe that the jars in ozone/bin should not affect your ozone client
development. The only problem I see is that if you start your client via the
ojvm command then both versions of the jars are in the CLASSPATH. But it should
be no problem to fix this by just adjusting the order of entries in the
ozone/bin/ozoneEnv script near line 67. Did you try this?


Falko
-- 
______________________________________________________________________
Falko Braeutigam                              mailto:falko@smb-tec.com
SMB GmbH                                        http://www.smb-tec.com