[Tm4j-developers] Improving development environment for TM4J

[<xua...@ba...>]

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/MercurialOnSourcefo=
rge
      .
    * 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.