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

[Conal T. <con...@vu...>]

Sorry to respond to this late, Xuân.

On Sun, 2008-01-27 at 04:33 +1300, Xuân Baldauf wrote:
> 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). 

Remember to consult with the developer and user lists, though, before
you make any changes to the public API (e.g. to org.tm4j.topicmap
interfaces). These interfaces are the most abstract parts of the system
and stability (and minimality) is important.

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

Is it possible to use Mercurial via HTTPS? The page you cited seems to
imply not. 

I know CVS is old and doggy, but we are all familiar with it which is
itself a big help.

If we were to change, I would prefer Subversion, because I have used it
every day for years and I know it pretty well. I also very much like
Subversion's reliance on HTTP and WebDAV, which makes it easy to use
behind web proxies, and with web tools in general. Are you familiar with
Subversion?

By contrast I'ave never used Mercurial (or even heard of it until now)
and I would really prefer not to have to learn a new revision control
system. 

What do the other developers think?

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

I think this is an interesting suggestion ... there are quite a few
build files which would need rewriting, but it could certainly be done. 

What sort of changes would be required to the overall organisation of
the source, do you think?

-- 
Conal Tuohy
New Zealand Electronic Text Centre
www.nzetc.org