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

[Xuân B. <xua...@ba...>]

Conal Tuohy wrote:
> 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.
>   
Yes,

as in the previous e-mail, I do not intend to do any changes on the 
org.tm4j.topicmap interfaces in the future.
>   
>> 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. 
>   
This page 
http://www.selenic.com/mercurial/wiki/index.cgi/HgWebDirStepByStep#head-2db756a7f816958aab4c7e7e26e28a9f909fdf99 
("By default, pushes are allowed only over https.") seems to imply that 
Mercurial HTTPS repositories are indeed possible.
> 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?
>   
Yes, but also with its drawbacks. One of the drawbacks is not being able 
to commit a change while being offline (this may sound odd to people who 
are not used to distributed SCMs). Others are cases where developers 
want to produce multiple changes against a project while they do not 
(yet) have write access (which, arguably, is also a specific form of 
being "offline"). With Subversion, they cannot, with Mercurial, they 
can. Because Mercurial allows every action (like committing multiple 
changes) to be done by everybody, it does encourages third party 
contributions (which are discouraged if a third party has to first ask 
for, argue for and wait for write access before having a prospect that 
playing around with the code in a manner useful for them and others can 
actually benefit the community). You'll find also very positive reports 
regarding Mercurial when searching for Subversion vs. Mercurial, like

    * "For a long time, I thought Subversion
      <http://subversion.tigris.org/> was the answer. That was until I
      tried Mercurial <http://www.selenic.com/mercurial/>. Subversion
      offers only incremental improvements on CVS, while Mercurial and
      similar tools offer new ways of working that have made me more
      productive." from
      http://theryanking.com/entries/2007/08/26/mercurial/ or
    *

Many projects now use Mercurial, including Java itself, Mozilla, Xen, 
OpenSolaris, RPM, ScientificPython, wget, Xine, ...  so Mercurial is 
definitely as mature, stable, scalable and feature-rich as needed for 
those projects.
> 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. 
>   
Given the amount of projects switching to Mercurial or already having 
switched, it may sound bold, but chances are good that you have to learn 
Mercurial anyways. ;-)
> 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?
>   
For the overall organization, moving some directories around (and 
sticking to standard Maven2 layout) would be quite beneficial. While it 
is possible to configure maven2 for a given directory layout, it is more 
a hassle than other way around (configuring a given directory layout to 
match the standard Maven2 layout). However, for moving files and 
directories, one should use a SCM which actually allows for moving (and 
thus renaming) directories and files, so doing this should be started 
only after the step away from CVS has been completed.


ciao,
Xuân.