tm4j-developers — Forum for issues related to development of TM4J.

[Tm4j-developers] Checking in

[Gerd M. <ge...@sm...>]

Hi,

I'm about to check in the ozone stuff. Before I'll do this some
remarks/questions:

1. My build script seems to be obsolete since the bin/ant does everything
   that is needed.

2. The XTMBuilder had two small bugs: somewhere the *Impl objects
   where created directly with 'new' instead with the factory.

3. I had to make the constructors of TopicNotFoundException and
   DuplicateTopicException public since otherwise I can't use 
   them.

4. To make the ozone implementation work I had to make TopicMapObjectImpl
   'Serializable'. This is needed since method arguments of ozone
   object methods are serialized and there are some util methods that
   get a transient TopicMapObjectImpl, e.g. the search methods.

If you don't mind I would check in the whole stuff.

Best Regards,
Gerd

--
________________________________________________________________
Gerd Mueller                                    ge...@sm...     
SMB GmbH                                  http://www.smb-tec.com

[Tm4j-developers] CVS notification list created.

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

The CVS notifications are now set up. Subscribe to the list
tm4...@li... to get checkin notices.

Cheers,

Kal

Re: [Tm4j-developers] Re: TM4J

[Gerd M. <ge...@sm...>]

Just two things regarding the Sourceforge config:

- Would you please configure the mailing lists in a way that the reply 
address is the list itself ? AFAIK, there is somewhere a switch for this.

- Also it would be cool to have a CVS mailing list. This way you'll know if 
someone checked in something.

> > > 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 ?

+1

Best Regards,
Gerd

-- 
______________________________________________________________________
Gerd Mueller                                   mailto:ge...@sm...
SMB GmbH                                        http://www.smb-tec.com

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

[Tm4j-developers] Re: TM4J

[Gerd M. <ge...@sm...>]

> 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.

> 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. 

> > - 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.

> > - 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

> 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 ;-)

> 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.

> > - 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.

Best Regards,
Gerd
-- 
______________________________________________________________________
Gerd Mueller                                   mailto:ge...@sm...
SMB GmbH                                        http://www.smb-tec.com

[Tm4j-developers] RE: TM4J

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

Hi Gerd,

I'm cc'ing one of the lists (which should be active now). There are three
lists:

tm4...@li...
tm4...@li...
tm4...@li...

You should be able to subscribe with a message to
<listname>-re...@li... or through the project page on
sourceforge.

>
> I'd like to do some improvements of the project structure of tm4j:
>

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'). Additionally I would like to keep the test-case topic maps separate
from the source, so either tm4j/test or tm4j/etc/test.

> - 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 ?

> - 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

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.

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 ;-)

> - 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 ?

>
> Finally a question: Are there any mailing lists about topicmaps
> and similar
> topics that you would recommend ? At the moment I'm subscribed at
> xml-dev,
> but this is of course more xml related.
>

Yeah, there are two lists for topicmaps. topicmapmail is more general - a
lot of the debates there at the moment are very philosophical, but starting
a techy revolution there might not be a bad thing ;-). You can subscribe to
that list from the Infoloom website: www.infoloom.com. The other list is the
XTM working group list, which despite the name is an open forum (it has also
gone all philosophical recently...this seems to be a tendency for
discussions on the Semantic Web). That list is a yahoo groups list, so you
need to register with Yahoo to get access. The group name is: xtm-wg and
Yahoo Groups are at www.yahoogroups.com. I also firmly believe that anyone
interested in topicmaps should keep a close eye on RDF - so the W3C's
rdf-interest group is a good one to join (it tends to be pretty low
traffic).

Cheers,

Kal

[Tm4j-developers] test

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

test tm4j-developers