Re: [Tm4j-developers] Forking a new development branch (anticipatingTM4J 2.0)

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

As I'm not really one of the active developers on this anymore, I'll =
just put in my 2p worth and then shut up J

=20

A TM4J 2 (or TM4J-NG ;-) that supports the features you mention would =
make sense. However, IMO there is still a very large topic maps =
user-base that neither need nor want the new ISO standards so TM4J 2 =
would have to sit in parallel with TM4J for a very long time (possibly =
forever).

=20

The licensing of TM4J essentially allows anyone to fork externally at =
any time - I don't have a problem with that, although they wouldn't be =
allowed to call it TM4J (or TM4J 2...TM4J-NG might be a bit dodgy too). =
The question, as you say is whether this is desirable. It would be nice =
to see work on support for TMDM/XTM2.0 and all the following ISO =
standards coming out of the tm4j team, but it does depend largely on the =
development support and the management support required to do that. In =
my experience the task of being an admin is a little more onerous and =
thankless than most people are prepared for, and so we need to be =
sensitive to that. I think that if the current dev admins are happy =
either to bring on a third person to be TM4J2 admin or to take on the =
task of admin for TM4J2 then it would be great to fork internally and =
provide the Java community with XTM2.0/TMDM support and XTM 1.0 support, =
otherwise I say you should take a source dump you are happy with and =
fork externally.

=20

One other thing: to my mind the changes from XTM 1.0 to XTM 2.0 are =
significant enough that I would not be too worried about binary/source =
compatibility issues if it makes development easier.

=20

Cheers

=20

Kal

=20

From: tm4...@li... =
[mailto:tm4...@li...] On Behalf Of =
Xu=E2n Baldauf
Sent: 06 April 2007 13:51
To: tm4...@li...
Subject: [Tm4j-developers] Forking a new development branch =
(anticipatingTM4J 2.0)

=20

Hello,

the current TM4J is becoming increasingly outdated. Much work needs to =
be done:

1.      support the current TMDM ( =
http://www.isotopicmaps.org/sam/sam-model/2006-06-18/ )

2.      support the current XTM 2.0 ( =
http://www.isotopicmaps.org/sam/sam-xtm/2006-06-19/ )

3.      support Java 1.5 style (at least, Java 1.6 is already released =
now)

To do this, significant changes are necessary, which probably are not =
backwards compatible. As I do not expect every old TM4J-application to =
be adapted, I suggest opening a new development branch. The old branch =
can be advanced to a version 1.0 (probably without the above features), =
but the new branch should result in a TM4J 2.0 with the above features. =
I think that it is possible to keep a TM4J 2.0 binary compatible and =
source compatible (albeit with compiler warnings) with TM4J =
0.9.8-applicatons, however, for my part of development, compatibility =
would not be a major concern.

For me, there seem to be 3 options:

1.      Change the current TM4J CVS version to include these features.

2.      Fork a new branch of the current TM4J CVS version within the =
current CVS repository to include these features in this new branch.

3.      Fork a new branch of the current TM4J CVS version outside of the =
current CVS repository to include these features in this new branch.

I really do not like option 3 (as this would decrease the already low =
(at least quiet) userbase and the probability of other people =
cooperatively improving on it as well). However, for option 1 or 2, I =
need your approval.

What do you think?

ciao,
Xu=E2n.




P.S.: About one year ago, I asked this:

Xu=E2n Baldauf wrote:=20

Hello,=20

I'd like to create a project which uses tm4j (and ozone). However, tm4j =
is still not converted to use Java 1.5 generics (see =
http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf ). Thus, I'd like =
to change tm4j to use Java 1.5 generics. However, after this conversion, =
using a generics-capable Java compiler (Java 1.5 javac or special Java =
1.4 javac) is required to compile the changed tm4j.=20

Would the current tm4j community accept such changes to the development =
tree of tm4j? (If not, I would not put work into doing these changes.)=20

Regards,=20

Xu=E2n Baldauf.=20

=20