RE: [Tm4j-developers] Re: TM4J

[Kal A. <ka...@te...>]

>
> > I've been wanting to do something like this for some time now...
> >
> > > - directory structure:
> > >
> > >    tm4j
> > >         bin      - some scripts, like ant
> > >         build    - this is where the compiled stuff goes to
> > >         etc      - configuration stuff if necessary
> > >         lib       - all necessary jars, including ant
> > >         src      - the sources
> > >         docs    - documentation
> > >
> > >    this follows more or less the apache project structure and
> is useful,
> > >    I guess.
> >
> > That looks good. I would also like to use CVS to control our web-site
> > content. So I would suggest adding 'web' either as a top level
> directory or
> > as a subdirectory of doc (I think I would prefer 'web' to be
> separate from
> > 'doc').
>
> tm4j/web would be okay.
>

Great - thats agreed then. I'll update the structure as outlined above and
change the build.xml to work with that ASAP (probably at lunchtime...which
is in about an hour), unless you have time to do it right now ;-)

> > Additionally I would like to keep the test-case topic maps separate
> > from the source, so either tm4j/test or tm4j/etc/test.
>
> We could add a 'resource' directory where to put all examples and
> something
> like that.
>

OK, but I would think keeping examples and test cases (which might be
stress-tests or even invalid TMs) separate would be good so we should keep
tests in resource/test and examples in resource/examples ?

> > > - Also I've got a build.bat and build.sh script that allows on to
> > > compile the
> > > project 'out-of-the-box'.
> >
> > That would be good. One of the problems with TMNav is that the
> license for
> > TheBrain does not allow redistribution of the JAR file, so it
> would not be
> > possible to build that 'out-of-the-box'. However I did discover a cool
> > feature of Ant which enables you to conditionally compile if a class is
> > present, so perhaps we could make the 'out-of-the-box' build
> only attempt
> > to compile TMNav if TheBrain SDK is available ? On a related
> point, one of
> > the things I would like to do as quickly as possible is actually remove
> > TheBrain and replace it with a redistributable and uncrippled
> visualisation
> > - do you have any ideas ?
>
> I don't know any free visualisation kit, but I'll look around to find
> something. There is a 2D graphics toolkit called Jazz, which is
> also hosted
> at sourceforge. It allows you to draw graphs and something like
> that. Mybe
> this could be the base for an own visualisation.
>

I've played a little with Jazz and it looks quite nice, so it would probably
be a good starting point.

> > > - regarding the package of the persistent layer I'm not sure. At
> > > the moment
> > > this is 'org.ozoneDB.topicmap'  but it could also be
> > > 'com.techquila.topicmap.ozone'. Any ideas on this ?
> >
> > That would be a good approach with minimal disruption to the
> existing code.
> > I don't have any problem with having both com.techquila.topicmap and
> > org.ozoneDB.topicmap packages in the source tree, but it might
> be nicer to
> > combine the two in some way.
> >
> > The other would be to restructure it as:
> >
> > com.techquila.topicmap.framework
> > com.techquila.topicmap.impl.mem
> > com.techquila.topicmap.impl.ozone
>
> I wouldn't make to deep package structures. What about:
>
> com.techquila.topicmap               - the interfaces
> com.techquila.topicmap.mem        - the mem impl
> com.techquila.topicmap.ozone      - the ozone impl
>

Works for me.

> > Which would be a little more logical and less cluttered than the current
> > com.techquila.topicmap tree.
> >
> > So, in summary three options:
> >
> > 1) Don't alter either of the package names, simply maintain both in the
> > same CVS tree
> > 2) Rename org.ozoneDB.topicmap to com.techquila.topicmap.ozone
> > 3) Completely restructure the tm4j packages in some way.
>
> I vote for the structure described above ;-)
>

+1...that makes it unanimous I guess! ;-)

> > On a related note, I would like to work out some way in which the same
> > application (such as the command-line utilities for example)
> can use either
> > the in-memory implementation or the ozone implementation transparently.
> > I'll have a think about this and start a separate thread when I have an
> > idea ;-)
>
> At the moment it is quite transparently. You simple have to
> choose the right
> factory. I've already used TMNav with ozone as backend. We could
> do something
> like as they did in JAXP and control the factory via a Java
> system property.
> The only problem with the ozone impl is that you have to connect to the
> database what you don't need with the mem version.
>

What kind of parameters are needed for that ? Could it be encoded in a URI -
I'm thinking along the lines of JDBC, but perhaps the JAXP way of doing
things is a bit more flexible.

> > > - for the documentation we could use either stylebook or some in
> > > the ozone
> > > mailing list made a docbook package. stylebook is pretty easy to
> > > use, I don't
> > > now docbook.
> >
> > And I've not used stylebook but I have done work with docbook before!
> > However, I think that if stylebook is easier to write to than
> docbook then
> > there will be less reason not to write docs - and thats a good
> thing - so
> > I'm happy to use stylebook. Can we keep a stylebook DTD and
> stylesheet as
> > part of the 'doc' subtree so that everyone uses the same versions ?
>
> I'll try to take a look into docbook first. It may happen that stylebook
> isn't supported anymore, since the Apache guys wan't replace it
> by Cocoon2.

OK - the nice thing about docbook is its completeness - there should be
pretty much everything we need there. And Norm Walsh's stylesheets for HTML
are pretty good (I haven't tried the FO stylesheets for PDF generation
though).

Cheers,

Kal