tmapi-discuss — Discussions regarding TMAPI developments

Re: [Tmapi-discuss] Proposal: clear method for TopicMap

[Lars H. <he...@se...>]

Hi Hannes,

[...]
> One real use case are unit tests. I need to create a topic map, fill
> it with some constructs and after some asserts want to clear the topic
> map before filling it again.

If unit tests are the only use case I'd be against it. You could
create / delete topic maps during setUp() / tearDown() (or use the
JUnit 4.x annotations).

Other opinions?

> My proposal is to add a clear method which removes all constructs from
> the topic map and results in an unreified topic map with its base
> locator and item identifier.

a) Topic maps do not have any base locator, I assume you're referring
   to storage address of the topic map (tm.getLocator())
b) I don't see a reason why .clear() should keep the item identifiers
   of the topic map. I understood .clear() as short-cut for
       final Locator loc = tm.getLocator();
       tm.remove();
       tm = tmSys.createTopicMap(loc);

Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine

[Tmapi-discuss] Proposal: clear method for TopicMap

[Hannes N. <h.n...@go...>]

Hi,

sometimes it is necessary to clear a topic map without deleting it.
With clear I mean the removal of every construct inside the topic map.
While memory backends can easily free the memory and recreate a topic
map it is more complicated for database backends.

One real use case are unit tests. I need to create a topic map, fill
it with some constructs and after some asserts want to clear the topic
map before filling it again.

My proposal is to add a clear method which removes all constructs from
the topic map and results in an unreified topic map with its base
locator and item identifier.

BTW: MaJorToM and Ontopia already have this method.

best regards
Hannes

-- 
Onotoa - Simply create your Topic Maps schemas.
Web:             http://onotoa.topicmapslab.de
User Group: http://groups.google.com/group/onotoa
Code:           http://code.google.com/p/onotoa/

http://www.topicmapslab.de/people/Hannes_Niederhausen

 ======================================
  Topic Maps Lab
  http://www.topicmapslab.de
  ======================================

  ======================================
  TMRA - International Conferences on
  Topic Maps Research and Applications

  TMRA 2010
  "Information wants to be a topic map"
  29.Sep - 01.Oct 2010, Leipzig, Germany

  http://www.tmra.de/2010/
  ======================================

Re: [Tmapi-discuss] Fwd: Re: OSGi support?

[johannes p. <joh...@ev...>]

To whom it may concern,

> Sorry, I've overseen your patch and I am afraid that I won't find
> the time to look at it this week. But I'll look at it next week.

> Dear other TMAPI members, the patch is here
> <http://sourceforge.net/tracker/?func=detail&aid=3053550&group_id=39237&atid=424688>

i am on holiday until the 13th of september, so i will only be able to
partake in the discussion again after that date...

best regards,
johannes

Re: [Tmapi-discuss] Fwd: Re: OSGi support?

[Lars H. <he...@se...>]

Hi Johannes,

[...]
> as i suppose you have seen, i submitted a patch to the tracker on
> sourceforge yesterday, which gives developers this choice, and i would
> appreciate it greatly if it would find it's way into the next TMAPI
> release...

Sorry, I've overseen your patch and I am afraid that I won't find
the time to look at it this week. But I'll look at it next week.

Dear other TMAPI members, the patch is here
<http://sourceforge.net/tracker/?func=detail&aid=3053550&group_id=39237&atid=424688>

Thanks for your work :)

Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine

Re: [Tmapi-discuss] Fwd: Re: OSGi support?

[johannes p. <joh...@ev...>]

> The reason for this question: TMAPI evaluates
> 'META-INF/services/TopicMapSystemFactory' but it has nothing in
> coommon with SPI.

aha.. well, that explains some things ;-). however as you probably know
this is not really a standard OSGi-approach (and thus devs probably
won't expect it to work unless this is stated explicitly).

i understand that it is convenient for porting existing applications to
OSGi, but i think that developers who are producing new applications for
OSGi might prefer to be able to choose the "standard" approach, which
involves providing services which implement interfaces.

as i suppose you have seen, i submitted a patch to the tracker on
sourceforge yesterday, which gives developers this choice, and i would
appreciate it greatly if it would find it's way into the next TMAPI
release...

best regards,
johannes

Re: [Tmapi-discuss] Fwd: Re: OSGi support?

[Lars H. <he...@se...>]

[...]
>> you cannot provide services via META-INF/services in OSGi - that is, the
>> lookup works inside the bundles, but not from another bundle.
>
> Hmm... Did you try it with TMAPI? Your explanation sounds like "I have
> a fuzzy feeling that it does not work, but I didn't try it".

The reason for this question: TMAPI evaluates
'META-INF/services/TopicMapSystemFactory' but it has nothing in
coommon with SPI.

Best regards,
Lars
-- 
Semagia
<http://www.semagia.com/>

Re: [Tmapi-discuss] Fwd: Re: OSGi support?

[Lars H. <he...@se...>]

Hi Johannes,

[...]
> the current approach works fine outside of OSGi. our experience was that
> you cannot provide services via META-INF/services in OSGi - that is, the
> lookup works inside the bundles, but not from another bundle.

Hmm... Did you try it with TMAPI? Your explanation sounds like "I have
a fuzzy feeling that it does not work, but I didn't try it".

[...]
> my solution satisfies all goals, it only requires TMAPI to also provide
> an interface for TopicMapSystemFactory, that's all. this does not
> influence any existing projects or approaches, but allows more choices
> for implementations.

Sounds good. :)

> i'll provide a patch in the course of the day, and if you want i can
> also provide an example blueprint configuration, to explain my point.

Please do. :)

Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine

Re: [Tmapi-discuss] Fwd: Re: OSGi support?

[johannes p. <joh...@ev...>]

Hi Lars,

> What does not work with the current approach? Can you provide some
> details?

the current approach works fine outside of OSGi. our experience was that
you cannot provide services via META-INF/services in OSGi - that is, the
lookup works inside the bundles, but not from another bundle.

> 
> The rationale behind the SPI approach was
> 
...
> 
> I'm aware of more OSGish solutions but they were difficult to
> implement given the goals mentioned above.

my solution satisfies all goals, it only requires TMAPI to also provide
an interface for TopicMapSystemFactory, that's all. this does not
influence any existing projects or approaches, but allows more choices
for implementations.

i'll provide a patch in the course of the day, and if you want i can
also provide an example blueprint configuration, to explain my point.

best regards,
johannes


>   
> [TopicMapSystemFactory as OSGi service]
>> the advantage of this approach is that bundles providing the service
>> propagates it in the OSGi container, which makes it easier to
>> administrate. i can gladly provide a patch for this.
> 
> Yes, that would be the cleanest solution within an OSGi environment.
> You may add your patch to our bug tracker. Do you think it fulfills
> the mentioned goals? Maybe we can ignore point (1), given that we'd
> create a new TMAPI release.
> 
>> i will - just for clarification, i suppose you mean the one at sourceforge?
> 
> Yes.
> 
> 
> Best regards,
> Lars

Re: [Tmapi-discuss] Fwd: Re: OSGi support?

[Lars H. <he...@se...>]

Hi Johannes,

[...]
>> All TMAPI implementations should provide a
>> "META-INF/services/org.tmapi.TopicMapSystemFactory" file which points
>> to the engine specific TopicMapSystemFactory.
>> In an OSGi environment, the TopicMapSystemFactory uses only the SPI
>> file to lookup TMAPI implementations.

> we have found the SPI approach not to work reliably under OSGi. setting
> a system property works, but is not transparent.

What does not work with the current approach? Can you provide some
details?

The rationale behind the SPI approach was

  1) Existing TMAPI implementations should work without taking care
     about OSGi
  2) Provide just one lookup mechanism in TMAPI
  3) Apps which use TMAPI shouldn't care if they are running within
     an OSGi environment or not (affects (2) as well)

I'm aware of more OSGish solutions but they were difficult to
implement given the goals mentioned above.
  
[TopicMapSystemFactory as OSGi service]
> the advantage of this approach is that bundles providing the service
> propagates it in the OSGi container, which makes it easier to
> administrate. i can gladly provide a patch for this.

Yes, that would be the cleanest solution within an OSGi environment.
You may add your patch to our bug tracker. Do you think it fulfills
the mentioned goals? Maybe we can ignore point (1), given that we'd
create a new TMAPI release.

> i will - just for clarification, i suppose you mean the one at sourceforge?

Yes.


Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine

[Tmapi-discuss] Fwd: Re: OSGi support?

[Lars H. <he...@se...>]

This is a forwarded message

From: johannes payr
To: Lars Heuer
Date: Thursday, August 26, 2010 11:41:06 AM
Subject: [Tmapi-discuss] OSGi support?

===8<==============Original message text===============

Hi Lars,

thanks for your quick reply...

> All TMAPI implementations should provide a
> "META-INF/services/org.tmapi.TopicMapSystemFactory" file which points
> to the engine specific TopicMapSystemFactory.
> In an OSGi environment, the TopicMapSystemFactory uses only the SPI
> file to lookup TMAPI implementations.

we have found the SPI approach not to work reliably under OSGi. setting
a system property works, but is not transparent.
if TMAPI would provide an interface for the TopicMapSystemFactory, other
bundles could just propagate a service using that interface (for example
using apache aries blueprint [1]). this would also be useful for
projects using spring, for example...
the advantage of this approach is that bundles providing the service
propagates it in the OSGi container, which makes it easier to
administrate. i can gladly provide a patch for this.

> Thanks for your comments, please add them to the bug tracker.

i will - just for clarification, i suppose you mean the one at sourceforge?

best regards,
johannes


[1] http://incubator.apache.org/aries/blueprint.html

> 
> The docs do not cover it, though.
> 
> [...]
>> as a side-note, it would seem that the OSGi-related classes are located
>> in a package which is not documented in the javaDoc [2], which makes
> 
> Yes, this was made intentionally. But I can change the build file to
> include the .internal package as well. Maybe we should add an
> "INTERNAL" remark at each class to make it clear that they do not
> belong to the published API.
> 
> Thanks for your comments, please add them to the bug tracker.
> 
> Best regards,
> Lars




===8<===========End of original message text===========

Re: [Tmapi-discuss] OSGi support?

[Lars H. <he...@se...>]

Hi Johannes,

[...]
> this would be especially important as i could find no documentation or
> style-guides on how to deploy tmapi-implementations as OSGi-bundles so
> that the TopicMapSystemFactory.newInstance() method actually takes hold

All TMAPI implementations should provide a
"META-INF/services/org.tmapi.TopicMapSystemFactory" file which points
to the engine specific TopicMapSystemFactory.
In an OSGi environment, the TopicMapSystemFactory uses only the SPI
file to lookup TMAPI implementations.

The docs do not cover it, though.

[...]
> as a side-note, it would seem that the OSGi-related classes are located
> in a package which is not documented in the javaDoc [2], which makes

Yes, this was made intentionally. But I can change the build file to
include the .internal package as well. Maybe we should add an
"INTERNAL" remark at each class to make it clear that they do not
belong to the published API.

Thanks for your comments, please add them to the bug tracker.

Best regards,
Lars
-- 
Semagia
<http://www.semagia.com/>

[Tmapi-discuss] OSGi support?

[johannes p. <joh...@ev...>]

dear all,

i just noticed by browsing the TMAPI source files i downloaded from
sourceforge, that TMAPI seems to be OSGi-compatible. while i am very
happy about this, because it essentially could (have) save(d) me some
work (if i had known about it earlier), i must say that as a developer
trying to use the API in a production environment i would truly
appreciate some publicly accessible documentation/anouncement on this,
for example on the official website [1].
this would be especially important as i could find no documentation or
style-guides on how to deploy tmapi-implementations as OSGi-bundles so
that the TopicMapSystemFactory.newInstance() method actually takes hold
(which would be really grand, because it would save my
application-bundle from having a dependency on my tm2jdbc-bundle and
would make it truly implementation-independent). The javaDoc for
TopicMapSystemFactory.newInstance() suggests using a system property,
however it might be useful to note that or if this is the recommended
way to register an implementation in an OSGi-environment (for example).
personally i would prefer TMAPI also to provide an interface for
TopicMapSystemFactory, so that bundles can provide it as a service, but
arguably that is a question of taste.

as a side-note, it would seem that the OSGi-related classes are located
in a package which is not documented in the javaDoc [2], which makes
reading the associated documentation comments a little cumbersome and
leaves me in the dark on whether the OSGi-features are actually
officially considered a part of the TMAPI, although i assume it is as
the release-notes for version 2.0.1 indicate this (which i found after
googling for a while).

just some notes from a user...

best regards,
johannes


[1] http://www.tmapi.org/2.0
[2] http://www.tmapi.org/2.0/api

Re: [Tmapi-discuss] TMAPI coding tip of the day

[Lars H. <he...@se...>]

[...]
>> That's ugly and unnecessary.

> And slow, since it creates a new array for each invocation.

Yes. If users want to keep that bad style, they should define a
constant like

    public static final Topic[] UCS = new Topic[0];


    Name name = topic.createName(type, "value", UCS);

Although it would be much better if they don't use the scope array at
all if names, occurrences and variants are in the unconstrained scope.

And the next coding tip "Do not create a topic array at all".

"scope" is a variable argument, so Java takes care of creating the
array for you.

Simply use

    Name name = topic.createName(type, "value", theme1, theme2);

instead of

    Name name = topic.createName(type, "value", new Topic[] {theme1, theme2});


Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine

Re: [Tmapi-discuss] TMAPI coding tip of the day

[Lars M. G. <la...@ga...>]

* Lars Heuer
> 
> That's ugly and unnecessary.

And slow, since it creates a new array for each invocation.

--Lars M.
http://www.garshol.priv.no/tmphoto/
http://www.garshol.priv.no/blog/

[Tmapi-discuss] TMAPI coding tip of the day

[Lars H. <he...@se...>]

Hi there,

From time to time I see something like

   Name name = topic.createName(type, "Value", new Topic[0]);

in Java code.

That's ugly and unnecessary. Correct usage:

   Name name = topic.createName(type, "Value");


Do not pass an empty scope array to the factory method. That applies
to the factory methods of occurrences and variants, too.

Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine

Re: [Tmapi-discuss] Duplicate roles

[Lars H. <he...@se...>]

Hi Sven,

[...]
> I expect that both roles are merged and the topic is playing only one 
> role of the given type.

I changed the test to avoid merging. I still think it's a bad idea to
merge the roles, but if the Topic Maps Lab is happy, I am happy too ;)

The snapshot was updated as well.

Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine

Re: [Tmapi-discuss] conflict with FEATURE_TYPE_INSTANCE_ASSOCIATIONS

[Lars H. <he...@se...>]

Hi Sven,

> I have attached the patch file at [1].

Thank you very much. Applied it to trunk with minor modifications
(white spaces and a checked exception wasn't handled).

The TMAPI 2.0.3 snapshots (tests and the API) are also up-to-date.

<http://www.tmapi.org/maven-repository/snapshots/>

Thanks again and best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine

Re: [Tmapi-discuss] conflict with FEATURE_TYPE_INSTANCE_ASSOCIATIONS

[Sven K. <kr...@in...>]

Hi Lars,

I have attached the patch file at [1].

Best regards,

Sven

[1] 
http://sourceforge.net/tracker/?func=detail&aid=3031577&group_id=39237&atid=424686

Am 19.07.2010 12:58, schrieb Lars Heuer:
> Hi Sven,
>
>    
>> I think there are different interpretations for the feature
>> FEATURE_TYPE_INSTANCE_ASSOCIATIONS in the context of the addType method
>> of a topic.
>>      
> [...]
>    
>> If the feature FEATURE_TYPE_INSTANCE_ASSOCIATIONS is not set, all works
>> fine, otherwise at least one of the tests failed. I think the second
>> test has to check, too, if the feature is set, right?
>>      
> Sounds like a bug. Would you provide a patch?
>
> Best regards,
> Lars
>    


-- 
Sven Krosse M. Sc.
Abteilung Automatische Sprachverarbeitung
Institut für Informatik | Universität Leipzig
Johannisgasse 26 | 04103 Leipzig

mail: kr...@in...

http://www.topicmapslab.de/
http://tmql.topicmapslab.de/

    ======================================
    TMRA - International Conferences on
    Topic Maps Research and Applications

    TMRA 2010
    "Information wants to be a topic map"
    29.Sep - 01.Oct 2010, Leipzig, Germany

    http://www.tmra.de/2010/
    ======================================

Re: [Tmapi-discuss] conflict with FEATURE_TYPE_INSTANCE_ASSOCIATIONS

[Lars H. <he...@se...>]

Hi Sven,

> I think there are different interpretations for the feature
> FEATURE_TYPE_INSTANCE_ASSOCIATIONS in the context of the addType method
> of a topic.
[...]
> If the feature FEATURE_TYPE_INSTANCE_ASSOCIATIONS is not set, all works
> fine, otherwise at least one of the tests failed. I think the second 
> test has to check, too, if the feature is set, right?

Sounds like a bug. Would you provide a patch?

Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine

Re: [Tmapi-discuss] Duplicate roles

[Lars H. <he...@se...>]

[...]
>     final Role role1 = assoc.createRole(roleType1, player);
>     final Role role2 = assoc.createRole(roleType1, player);

Should be:

      final Role role2 = assoc.createRole(roleType2, player);

Sorry.



Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine

Re: [Tmapi-discuss] Duplicate roles

[Lars H. <he...@se...>]

Hi Sven,

[...]
> final Role role1 = assoc.createRole(roleType1, player);
> final Role role2 = assoc.createRole(roleType2, player);
> role2.setType(roleType1);
> assertEquals(2, player.getRolesPlayed(roleType1, assocType1).size()); <<
> FAILURE
> the test fails because the second role was merged with role1 beause of
> the TMDM equality rule.
[...]

Yes, but IMO it's wrong to merge the roles even if TMDM mandates it.
How would you handle this use case:

    final Role role1 = assoc.createRole(roleType1, player);
    final Role role2 = assoc.createRole(roleType1, player);
    role2.setType(roleType1);

    // Attention, role2 is going to be unequal to role1 again
    role2.setPlayer(player2);

Without a proper transaction implementation the engine can never know
when an application has finished the modifications.

See also this discussion which fits to your problem:
<http://logs.subjektzentrisch.de/topicmaps/archive/%23topicmaps20100717.html#2010-07-17T22:08:37+02:00>


I think the test is okay, at least it is not wrong. We could remove
the test from the test suite, though. But it doesn't change the fact
that merging constructs is a suboptimal idea without txns.

Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine

[Tmapi-discuss] Duplicate roles

[Sven K. <kr...@in...>]

Dear all,

I think the TestTopic.testRoleAssociationFilter does not work as expected.

@"TestTopic.testRoleAssociationFilter"

final Role role1 = assoc.createRole(roleType1, player);
final Role role2 = assoc.createRole(roleType2, player);
role2.setType(roleType1);
assertEquals(2, player.getRolesPlayed(roleType1, assocType1).size()); << 
FAILURE

the test fails because the second role was merged with role1 beause of 
the TMDM equality rule.
"*Equality rule:* Association role items are equal if the values of 
their [type], [player], and [parent] properties are equal."

I expect that both roles are merged and the topic is playing only one 
role of the given type.

Thanks for help.

Sven

-- 
Sven Krosse M. Sc.
Abteilung Automatische Sprachverarbeitung
Institut für Informatik | Universität Leipzig
Johannisgasse 26 | 04103 Leipzig

mail: kr...@in...

http://www.topicmapslab.de/
http://tmql.topicmapslab.de/

    ======================================
    TMRA - International Conferences on
    Topic Maps Research and Applications

    TMRA 2010
    "Information wants to be a topic map"
    29.Sep - 01.Oct 2010, Leipzig, Germany

    http://www.tmra.de/2010/
    ======================================

[Tmapi-discuss] conflict with FEATURE_TYPE_INSTANCE_ASSOCIATIONS

[Sven K. <kr...@in...>]

Dear all,

I think there are different interpretations for the feature 
FEATURE_TYPE_INSTANCE_ASSOCIATIONS in the context of the addType method 
of a topic.

@"TestTypeInstanceIndex.testTopic" and 
"TestTopicRemovableConstraint."testUsedAsTopicType"

The first test checks if the type-instance association was created after 
calling addType ( topic number increases by 3 because of association and 
role types)
      assertEquals(5, _typeInstanceIdx.getTopics(null).size());

The other test does not check this and expects that the topics are not 
created.

If the feature FEATURE_TYPE_INSTANCE_ASSOCIATIONS is not set, all works 
fine, otherwise at least one of the tests failed. I think the second 
test has to check, too, if the feature is set, right?

Thanks for help.

Sven

-- 
Sven Krosse M. Sc.
Abteilung Automatische Sprachverarbeitung
Institut für Informatik | Universität Leipzig
Johannisgasse 26 | 04103 Leipzig

mail: kr...@in...

http://www.topicmapslab.de/
http://tmql.topicmapslab.de/

    ======================================
    TMRA - International Conferences on
    Topic Maps Research and Applications

    TMRA 2010
    "Information wants to be a topic map"
    29.Sep - 01.Oct 2010, Leipzig, Germany

    http://www.tmra.de/2010/
    ======================================

[Tmapi-discuss] New TMAPI impl

[Lars H. <he...@se...>]

Hi all,

In case you missed it, the TMAPI implementation family has a new
child:

      SesameTM
      http://sesametm.googlecode.com/
      Open Source Topic Maps engine that utilizes the Sesame RDF store
      and supports different persistent and non-persistent backends.

It was added to TMAPI's homepage already.

Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine

[Tmapi-discuss] ANN: TMAPI 2.0.2 release

[Lars H. <he...@se...>]

Hi all,

The TMAPI project [1] published a new TMAPI release [2]. The release
is *not* backwards compatible to TMAPI 2.0.1 / 2.0 since it contains
an API change (you need a TMAPI 2.0.2 compatible engine to use the new
release).

Changes as follows:
* Added TopicMap.getLocator() to return the storage address of
  the topic map within a TopicMapSystem

You may want to update your Maven / Ant Ivy depencencies:

  <dependencies>
    <dependency>
      <groupId>org.tmapi</groupId>
      <artifactId>tmapi</artifactId>
      <version>2.0.2</version>
    </dependency>
  </dependencies>

  <repositories>
    <repository>
      <id>org.tmapi</id>
      <url>http://www.tmapi.org/maven-repository/</url>
    </repository>
  </repositories>

[1] <http://www.tmapi.org/2.0/>
[2] <https://sourceforge.net/projects/tmapi/files/>

Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine