Re: [Tm4j-developers] Improving development environment for TM4J

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

Hi Xu=E2n,

=20

Right now, Conal Tuohy and Ichiro Furusato are the main development =
leads for TM4J since I took a back seat to concentrate on Networked =
Planet work. So I will defer to them in questions of the development =
environment. My concern with Mercurial would be about the level at which =
it is supported by the SourceForge team. While it is nice to have the =
latest shiny toys to play with, it is also nice to have a system that =
someone else looks after ;-)

=20

With regards to generating topic map engines and the such like - domain =
specific languages certainly hold out a lot of hope for generating the =
basic structure, but I would imagine that the logic (e.g. the logic of =
merging) would still have to be hand coded, so I don't know how much of =
a real saving they would provide. We (NetworkedPlanet) used MS's DSL =
tools to generate a topic map ontology editor and that worked quite =
nicely but even that relatively simple domain-specific language required =
a fair amount of hand-written code to work properly.

=20

Finally on Locators, the logic behind the Locator structure in the =
original TM4J was that it should be possible to support a wider range of =
locator syntaxes than URI/URL syntax. In practice, URIs (or maybe IRIs) =
have won and the Locator class is probably something of an anachronism - =
a simple Unicode character sequence (backed up with the library =
functions for parsing and handling those strings as URIs) should work =
for a "new" topic map engine.

=20

Cheers

=20

Kal

=20

From: Xu=E2n Baldauf =
[mailto:xuan--2008.01.27--tm4j-developers--lists.sourceforge.net@baldauf.=
org]=20
Sent: 26 January 2008 15:33
To: Kal Ahmed
Cc: tm4...@li...
Subject: Improving development environment for TM4J

=20

Hi Kal,

I have submitted a larger chunk of changes to TM4J in anticipation of a =
TM4J2 (with a compatibility layer to TM4J 0.9.x), but there is still a =
lot to do (and the changes are incomplete so far). However, the =
development environment itself has become somewhat anachronistic and I'd =
like to introduce some changes to the environment:

*	Change from CVS to Mercurial: Mercurial allows for a much smoother and =
more network-independent (read: faster) development of changes than CVS. =
The repository is still to be hosted on sourceforge, in a manner like =
http://www.selenic.com/mercurial/wiki/index.cgi/MercurialOnSourceforge .
*	Change from Ant to Maven2: In the Java world, Maven2 is gaining quite =
momentum. There are more than 600 projects listed on =
http://repo1.maven.org/maven2/ which are known be some form of a maven2 =
project. Maven has the advantage that all dependencies (and its =
transitive dependencies) for a project to compile and run are not needed =
to be copied into the project. Rather than that, dependencies are are =
just specified and, at the first build time, downloaded on demand. One =
major advantage is the relief of the burden to maintain a coherent set =
of dependencies (and its transitive dependencies), and a very simple way =
to change dependencies. (Example: I upgraded the CVS copy of ant =
recently by a version which is 4 years newer, which created a lot of =
noise in the logs.) Another advantage is that TM4J being a Maven2 =
project makes itself very easily usable by other Java projects =
(especially those which use Maven2), without a hassle to configure =
classpaths and such. A further advantage is that TM4J may optionally =
depend on GPL code (like DB4O for a persistent backend), which is not =
possible when including GPL software in the repository directly.

It would be nice if you could give your comments or you "amen" (or =
"ramen" if you believe in FSM) to these changes within the next days or =
weeks and if anybody else could comment on it.

ciao,
Xu=E2n.

P.S.: Who is the "operational" project admin of TM4J (is there any?). It =
looks like the developer of the Ruby Topic Maps engine ( =
http://rtm.rubyforge.org/ ) is going to need commit rights at some =
future point in time, and it would be nice to know who to ask. We are =
currently planning a bridge between Ruby and Java such that RTM may be =
able to use TM4J as a backend. Furthermore, we are currently playing =
around with automatic generation of Java topicmap engines using Ruby =
domain specific languages (thus vastly improving development speed, as =
many codings once done for one TopicMapConstruct have to be repeated =
very similarily for all the other TopicMapConstructs). It also possible =
to generate topic map engines with different properties (e.g. engines =
where locators are represented internally not as Locator objects, but as =
plain UTF-16 sequences or as plain UTF-8 sequences, improving memory =
usage, or engines where different ways of indexing are used). At some =
point of time, it may be good for TM4J engines to be generatable in this =
way.