Menu
▾
▴
tm4j-developers
|
From:
<xua...@ba...> - 2006-04-15 11:45:17
|
Hello, 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. 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.) Regards, Xuân Baldauf. |
|
From: Kal A. <ka...@te...> - 2006-04-21 06:42:54
|
Hi Xu=E2n, When I tried to migrate TM4J from JDK 1.3 to 1.4, a lot of people=20 complained that they were not able to upgrade their environment to 1.4.=20 I'm not doing a lot of Java development these days, so I don't really=20 have a good feel for how widely used JDK 1.5 is. I would be interested to hear from the other developers on this list to=20 know what their opinion is. Best regards Kal Xu=E2n Baldauf wrote: > Hello, >=20 > I'd like to create a project which uses tm4j (and ozone). However, tm4j= =20 > is still not converted to use Java 1.5 generics (see=20 > http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf ). Thus, I'd lik= e=20 > to change tm4j to use Java 1.5 generics. However, after this conversion= ,=20 > using a generics-capable Java compiler (Java 1.5 javac or special Java=20 > 1.4 javac) is required to compile the changed tm4j. >=20 > Would the current tm4j community accept such changes to the development= =20 > tree of tm4j? (If not, I would not put work into doing these changes.) >=20 > Regards, >=20 > Xu=E2n Baldauf. >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting lang= uage > that extends applications into web and mobile media. Attend the live=20 > webcast > and join the prime developer group breaking into this new coding territ= ory! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat= =3D121642 > _______________________________________________ > Tm4j-developers mailing list > Tm4...@li... > https://lists.sourceforge.net/lists/listinfo/tm4j-developers >=20 >=20 |
|
From: Lars M. G. <la...@on...> - 2006-04-21 07:03:24
|
* Kal Ahmed > > When I tried to migrate TM4J from JDK 1.3 to 1.4, a lot of people > complained that they were not able to upgrade their environment to > 1.4. I'm not doing a lot of Java development these days, so I don't > really have a good feel for how widely used JDK 1.5 is. > > I would be interested to hear from the other developers on this > list to know what their opinion is. For what it's worth, Ontopia's experience is that there are still organizations whose server environments are standardized on JDK 1.3, mainly because they've standardized on early WebSphere or WebLogic versions. -- Lars Marius Garshol, Ontopian http://www.ontopia.net +47 98 21 55 50 http://www.garshol.priv.no |
|
From:
<xua...@ba...> - 2007-04-06 12:51:17
|
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=
=2E
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=
=2E
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:
> Hello,
>
> 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.
>
> 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.)
>
> Regards,
>
> Xu=E2n Baldauf.
>
|
|
From:
<xua...@ba...> - 2007-04-08 02:31:08
Attachments:
tm4j.xtm2.rudimentarySupport.v3.patch
|
Hi! As a start, I have written is some rudimentary XTM 2.0 support for the current TM4J. The patch is attached. ciao, Xuân. Xuân Baldauf wrote: > 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ân. > > > > > P.S.: About one year ago, I asked this: > > Xuân Baldauf wrote: >> Hello, >> >> 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. >> >> 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.) >> >> Regards, >> >> Xuân Baldauf. >> |
|
From: Kal A. <ka...@ne...> - 2007-04-10 07:50:24
|
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 |
|
From:
<xua...@ba...> - 2007-04-10 09:59:45
|
Kal Ahmed wrote:
>
> As I=E2=80=99m not really one of the active developers on this anymore,=
I=E2=80=99ll
> 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).
>
> [...]
>
> 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.
>
In the course of writing the XTM-2.0-reading-support-patch, I found that
it not that hard to remain compatible than I expected. The union of the
semantics of XTM 1.0 and XTM 2.0/TMDM are basically:
* multiple role players per role (removed in TMDM)
* occurence type mandatory (added in TMDM, can be simulated by a
"default" occurence type)
* association type mandatory (added in TMDM, can be simulated by a
"default" association type)
* role type mandatory (added in TMDM, can be simulated by a
"default" role type)
* name type optional (added in TMDM, is simulated by a "default"
name type)
That basically means that a TM4J 2.0 just needs to support TMDM plus
multiple role players per role to both support TMDM and support XTM 1.0
in a fully backward compatible manner. As TM4J 0.9 already supports
multiple role players per role, that support just might be kept in TM4J
2.0. (In case one wants to export into a TMDM data format (XTM 2.0,
upcoming CTM), these "special roles with multiple players" can be
"normalized" into multiple roles with single players each.)
Thus, I think now that caring for compatibility outweighs faster
development of new features, as it is no point in developing an open
source project which has no user base (and thus a very thin developer
base). Also, this way, old applications can benefit from new features
(like XTM 2.0 and CTM import|export support). Thus, I would want to try
to keep TM4J 2 as compatible as possible.
Thus, I would prefer option 1. (Change the current TM4J CVS version to
include these features.) This also would lessen the load on project
admins, as there would not be two competing but understaffed TM4J
development versions.
>
> =20
>
> Cheers
>
> =20
>
> Kal
>
ciao,
Xu=C3=A2n.
>
> =20
>
> *From:* tm4...@li...
> [mailto:tm4...@li...] *On Behalf Of
> *Xu=C3=A2n 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=
=2E
>
> 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=C3=A2n.
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X