Menu
▾
▴
tm4j-developers — Forum for issues related to development of TM4J.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(9) |
Jun
(26) |
Jul
(22) |
Aug
(31) |
Sep
(25) |
Oct
(9) |
Nov
(7) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(50) |
Feb
(51) |
Mar
(6) |
Apr
(10) |
May
(4) |
Jun
(9) |
Jul
(9) |
Aug
(1) |
Sep
(2) |
Oct
(1) |
Nov
(2) |
Dec
(11) |
| 2003 |
Jan
(8) |
Feb
(21) |
Mar
(2) |
Apr
(29) |
May
(9) |
Jun
(1) |
Jul
(4) |
Aug
(8) |
Sep
(3) |
Oct
(21) |
Nov
(40) |
Dec
(14) |
| 2004 |
Jan
(32) |
Feb
(30) |
Mar
(24) |
Apr
(13) |
May
(25) |
Jun
(14) |
Jul
(9) |
Aug
(21) |
Sep
(52) |
Oct
(9) |
Nov
(12) |
Dec
(6) |
| 2005 |
Jan
(2) |
Feb
(2) |
Mar
(3) |
Apr
|
May
(6) |
Jun
(2) |
Jul
(2) |
Aug
(1) |
Sep
(14) |
Oct
(1) |
Nov
|
Dec
(4) |
| 2006 |
Jan
|
Feb
(16) |
Mar
(7) |
Apr
(7) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
(2) |
Nov
(9) |
Dec
(2) |
| 2007 |
Jan
(2) |
Feb
(9) |
Mar
(1) |
Apr
(38) |
May
(7) |
Jun
(7) |
Jul
(12) |
Aug
(10) |
Sep
(10) |
Oct
(3) |
Nov
(7) |
Dec
(7) |
| 2008 |
Jan
(13) |
Feb
(12) |
Mar
(53) |
Apr
(14) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From:
<xua...@ba...> - 2007-04-13 02:12:33
|
Lars Heuer wrote: > Hi Xu=C3=A2n, > > [...] > =20 >> as I'd like to enhance TM4J with new features (which might imply >> significant changes) and as I assume that there is a significant >> userbase building on the last current release (which is TM4J 0.9.7 fro= m >> more than 2=C2=BD years ago), it is time to create a "stable" branch p= arallel >> to the unstable branch. My understanding is as follows: >> =20 > > I prepared a 0.9.x release with which fixes several bugs. > C.f. <http://tm4j.cvs.sourceforge.net/tm4j/tm4j/RELEASE.txt?view=3Dmark= up> > =20 I'm sorry, you are right. I judged from the "News" page ( http://sourceforge.net/news/?group_id=3D27895 ) which currently shows "TM4J 0.9.7 Released" as the latest announcement. <http://sourceforge.net/forum/forum.php?forum_id=3D412950> > Someone with admin rights (Murray?) should prepare a release IMO. > > The last official release sucks. > > [...] > =20 >> * unstable branch "MAIN": >> o No hard requirement to keep compatibility (although >> API-level compatibility should be kept as well as possible= ). >> =20 > > IMO very difficult if you want to support TMDM. > =20 My current idea is to support a superset of TMDM and the current TM4J as laid out in http://tm4j.cvs.sourceforge.net/*checkout*/tm4j/tm4j/docs/TMDM-support.ht= ml?revision=3D1.1 =2E Maybe this proves to be infeasible, maybe not. I'm still somewhat optimistic. :-) But maybe the additional effort is worth it because applications using TM4J may get a smooth transition (increasing development efforts here to decrease development efforts at the applications). > Best regards, > Lars > =20 ciao, Xu=C3=A2n. |
|
From: Lars H. <he...@se...> - 2007-04-12 15:38:14
|
Hi Xuân, [...] > as I'd like to enhance TM4J with new features (which might imply > significant changes) and as I assume that there is a significant > userbase building on the last current release (which is TM4J 0.9.7 from > more than 2½ years ago), it is time to create a "stable" branch parallel > to the unstable branch. My understanding is as follows: I prepared a 0.9.x release with which fixes several bugs. C.f. <http://tm4j.cvs.sourceforge.net/tm4j/tm4j/RELEASE.txt?view=markup> Someone with admin rights (Murray?) should prepare a release IMO. The last official release sucks. [...] > * unstable branch "MAIN": > o No hard requirement to keep compatibility (although > API-level compatibility should be kept as well as possible). IMO very difficult if you want to support TMDM. Best regards, Lars -- http://www.semagia.com |
|
From:
<xua...@ba...> - 2007-04-12 14:44:43
|
Hello developers,
as I'd like to enhance TM4J with new features (which might imply
significant changes) and as I assume that there is a significant
userbase building on the last current release (which is TM4J 0.9.7 from
more than 2=C2=BD years ago), it is time to create a "stable" branch para=
llel
to the unstable branch. My understanding is as follows:
* stable branch "TM4J_1_x":
o Polishing goes on here.
o Keep source-level compatibility, binary-level compatibility
to TM4J 0.9.7.
o Keep requirements-level compatibility to TM4J 0.9.7. (For
example, do not require a new Java version.)
o Fix bugs in a compatible way.
o Get really stable.
o Be comparably conservative.
* unstable branch "MAIN":
o Development goes on here.
o No hard requirement to keep compatibility (although
API-level compatibility should be kept as well as possible).
o New requirements: Java 1.5
o Fix bugs "the right way"=E2=84=A2.
o No need to be stable.
o Be innovative, not conservative.
Having said that, I hope that most of the current TM4J 0.9.7 users will
switch to the unstable branch in the long term, when the features of the
unstable branch at some day outweigh the risks and efforts attached to
switching.
As a little goodie, the rudimentary XTM 2.0 reading support goes into
both branches.
ciao,
Xu=C3=A2n.
|
|
From: SourceForge.net <no...@so...> - 2007-04-12 10:44:26
|
Feature Requests item #1699114, was opened at 2007-04-12 12:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=1699114&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface Improvements (example) Group: None Status: Open Priority: 5 Private: No Submitted By: Xuan Baldauf (mediumnet) Assigned to: Nobody/Anonymous (nobody) Summary: Update browserLauncher.jar Initial Comment: The "current" browserLauncher.jar distributed with tmnav is from the year 2003 and thus very outdated (and also buggy). Use a new copy of browserLauncher from http://browserlaunch2.sourceforge.net/ . It straightly works as a drop-in-replacement on my machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=1699114&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2007-04-12 08:02:12
|
Bugs item #1698885, was opened at 2007-04-12 03:59 Message generated for change (Comment added) made by mediumnet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1698885&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Import/Export Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Xuan Baldauf (mediumnet) Assigned to: Nobody/Anonymous (nobody) Summary: org.tm4j.topicmap.cmd.Merge crashes Initial Comment: call "java org.tm4j.topicmap.cmd.Merge -c test.xtm", where "test.xtm" is this file: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE topicMap PUBLIC "-//TopicMaps.Org//DTD XML Topic Map (XTM) 1.0//EN" "http://www.topicmaps.org/xtm/1.0/xtm1.dtd"> <topicMap id="x1nnj36ct9-0" xmlns="http://www.topicmaps.org/xtm/1.0/" xmlns:xlink="http://www.w3.org/1999/xlink"> <topic id="id129"> <instanceOf> <topicRef xlink:href="#x1nnj36d5b-7"/> </instanceOf> </topic> <topic id="x1nnj36d5b-7"> <subjectIdentity> <subjectIndicatorRef xlink:href="http://psi.somewhere/#something"/> </subjectIdentity> </topic> </topicMap> And you will get something like: 2 [main] FATAL org.tm4j.topicmap.cmd.Merge - Unexpected exception. java.lang.NullPointerException at java.util.Collections$UnmodifiableCollection.<init>(Collections.java:994) at java.util.Collections$UnmodifiableSet.<init>(Collections.java:1066) at java.util.Collections.unmodifiableSet(Collections.java:1056) at org.tm4j.topicmap.memory.TopicMapObjectImpl.getSourceLocators(TopicMapObjectImpl.java:175) at org.tm4j.topicmap.memory.TopicImpl.getSourceLocators(TopicImpl.java:1673) at org.tm4j.topicmap.memory.TopicImpl.getSourceLocators(TopicImpl.java:1662) at org.tm4j.topicmap.utils.XTMWriter.getResourceID(XTMWriter.java:857) at org.tm4j.topicmap.utils.XTMWriter.getID(XTMWriter.java:927) at org.tm4j.topicmap.utils.XTMWriter.topicRef(XTMWriter.java:703) at org.tm4j.topicmap.utils.XTMWriter.onType(XTMWriter.java:605) at org.tm4j.topicmap.utils.TopicMapWalker.walk(TopicMapWalker.java:119) at org.tm4j.topicmap.utils.TopicMapWalker.walk(TopicMapWalker.java:86) at org.tm4j.topicmap.utils.TopicMapSerializer.serialize(TopicMapSerializer.java:373) at org.tm4j.topicmap.cmd.Merge.run(Merge.java:99) at org.tm4j.topicmap.cmd.AppBase.initialise(AppBase.java:190) at org.tm4j.topicmap.cmd.Merge.<init>(Merge.java:62) at org.tm4j.topicmap.cmd.Merge.main(Merge.java:117) ---------------------------------------------------------------------- >Comment By: Xuan Baldauf (mediumnet) Date: 2007-04-12 10:02 Message: Logged In: YES user_id=506885 Originator: YES This patch fixes the bug (at least makes the testcase succeed). File Added: removeMergedTopic.partialSupport.patch ---------------------------------------------------------------------- Comment By: Xuan Baldauf (mediumnet) Date: 2007-04-12 09:54 Message: Logged In: YES user_id=506885 Originator: YES The cause seems to be in unmerging topics not being properly supported. XTMUtils.flattenTopicRefs destroys some topics. However, these destroyed topics may be merged with other topics. Thus, the destroyed topic needs to be properly unmerged from its merging partners. This seems to be not implemented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1698885&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2007-04-12 07:54:41
|
Bugs item #1698885, was opened at 2007-04-12 03:59 Message generated for change (Comment added) made by mediumnet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1698885&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Import/Export Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Xuan Baldauf (mediumnet) Assigned to: Nobody/Anonymous (nobody) Summary: org.tm4j.topicmap.cmd.Merge crashes Initial Comment: call "java org.tm4j.topicmap.cmd.Merge -c test.xtm", where "test.xtm" is this file: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE topicMap PUBLIC "-//TopicMaps.Org//DTD XML Topic Map (XTM) 1.0//EN" "http://www.topicmaps.org/xtm/1.0/xtm1.dtd"> <topicMap id="x1nnj36ct9-0" xmlns="http://www.topicmaps.org/xtm/1.0/" xmlns:xlink="http://www.w3.org/1999/xlink"> <topic id="id129"> <instanceOf> <topicRef xlink:href="#x1nnj36d5b-7"/> </instanceOf> </topic> <topic id="x1nnj36d5b-7"> <subjectIdentity> <subjectIndicatorRef xlink:href="http://psi.somewhere/#something"/> </subjectIdentity> </topic> </topicMap> And you will get something like: 2 [main] FATAL org.tm4j.topicmap.cmd.Merge - Unexpected exception. java.lang.NullPointerException at java.util.Collections$UnmodifiableCollection.<init>(Collections.java:994) at java.util.Collections$UnmodifiableSet.<init>(Collections.java:1066) at java.util.Collections.unmodifiableSet(Collections.java:1056) at org.tm4j.topicmap.memory.TopicMapObjectImpl.getSourceLocators(TopicMapObjectImpl.java:175) at org.tm4j.topicmap.memory.TopicImpl.getSourceLocators(TopicImpl.java:1673) at org.tm4j.topicmap.memory.TopicImpl.getSourceLocators(TopicImpl.java:1662) at org.tm4j.topicmap.utils.XTMWriter.getResourceID(XTMWriter.java:857) at org.tm4j.topicmap.utils.XTMWriter.getID(XTMWriter.java:927) at org.tm4j.topicmap.utils.XTMWriter.topicRef(XTMWriter.java:703) at org.tm4j.topicmap.utils.XTMWriter.onType(XTMWriter.java:605) at org.tm4j.topicmap.utils.TopicMapWalker.walk(TopicMapWalker.java:119) at org.tm4j.topicmap.utils.TopicMapWalker.walk(TopicMapWalker.java:86) at org.tm4j.topicmap.utils.TopicMapSerializer.serialize(TopicMapSerializer.java:373) at org.tm4j.topicmap.cmd.Merge.run(Merge.java:99) at org.tm4j.topicmap.cmd.AppBase.initialise(AppBase.java:190) at org.tm4j.topicmap.cmd.Merge.<init>(Merge.java:62) at org.tm4j.topicmap.cmd.Merge.main(Merge.java:117) ---------------------------------------------------------------------- >Comment By: Xuan Baldauf (mediumnet) Date: 2007-04-12 09:54 Message: Logged In: YES user_id=506885 Originator: YES The cause seems to be in unmerging topics not being properly supported. XTMUtils.flattenTopicRefs destroys some topics. However, these destroyed topics may be merged with other topics. Thus, the destroyed topic needs to be properly unmerged from its merging partners. This seems to be not implemented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1698885&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2007-04-12 01:59:36
|
Bugs item #1698885, was opened at 2007-04-12 03:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1698885&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Import/Export Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Xuan Baldauf (mediumnet) Assigned to: Nobody/Anonymous (nobody) Summary: org.tm4j.topicmap.cmd.Merge crashes Initial Comment: call "java org.tm4j.topicmap.cmd.Merge -c test.xtm", where "test.xtm" is this file: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE topicMap PUBLIC "-//TopicMaps.Org//DTD XML Topic Map (XTM) 1.0//EN" "http://www.topicmaps.org/xtm/1.0/xtm1.dtd"> <topicMap id="x1nnj36ct9-0" xmlns="http://www.topicmaps.org/xtm/1.0/" xmlns:xlink="http://www.w3.org/1999/xlink"> <topic id="id129"> <instanceOf> <topicRef xlink:href="#x1nnj36d5b-7"/> </instanceOf> </topic> <topic id="x1nnj36d5b-7"> <subjectIdentity> <subjectIndicatorRef xlink:href="http://psi.somewhere/#something"/> </subjectIdentity> </topic> </topicMap> And you will get something like: 2 [main] FATAL org.tm4j.topicmap.cmd.Merge - Unexpected exception. java.lang.NullPointerException at java.util.Collections$UnmodifiableCollection.<init>(Collections.java:994) at java.util.Collections$UnmodifiableSet.<init>(Collections.java:1066) at java.util.Collections.unmodifiableSet(Collections.java:1056) at org.tm4j.topicmap.memory.TopicMapObjectImpl.getSourceLocators(TopicMapObjectImpl.java:175) at org.tm4j.topicmap.memory.TopicImpl.getSourceLocators(TopicImpl.java:1673) at org.tm4j.topicmap.memory.TopicImpl.getSourceLocators(TopicImpl.java:1662) at org.tm4j.topicmap.utils.XTMWriter.getResourceID(XTMWriter.java:857) at org.tm4j.topicmap.utils.XTMWriter.getID(XTMWriter.java:927) at org.tm4j.topicmap.utils.XTMWriter.topicRef(XTMWriter.java:703) at org.tm4j.topicmap.utils.XTMWriter.onType(XTMWriter.java:605) at org.tm4j.topicmap.utils.TopicMapWalker.walk(TopicMapWalker.java:119) at org.tm4j.topicmap.utils.TopicMapWalker.walk(TopicMapWalker.java:86) at org.tm4j.topicmap.utils.TopicMapSerializer.serialize(TopicMapSerializer.java:373) at org.tm4j.topicmap.cmd.Merge.run(Merge.java:99) at org.tm4j.topicmap.cmd.AppBase.initialise(AppBase.java:190) at org.tm4j.topicmap.cmd.Merge.<init>(Merge.java:62) at org.tm4j.topicmap.cmd.Merge.main(Merge.java:117) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1698885&group_id=27895 |
|
From: Peri <per...@gm...> - 2007-04-11 21:20:29
|
Hi,
I am trying to perform a copy from a TopicMap generated from in memory
provider and populate my topicmap stored in the database.
While copying the scope bounded basenames, the copy operations errors out
with a class cast exception...
TopicMap:
topicmaps/kings_and_queens.xtm # Sample provided in the examples
Code Snippet:
TopicMapProvider provider_m = tmpf_m.newTopicMapProvider(providerProps);
Locator baseLocator_m = provider_m.getLocatorFactory().createLocator("URI",
getInputURI());
TopicMapSource src_m = new SerializedTopicMapSource(getInputStream(),
baseLocator_m);
// Parse the topic map
TopicMap tm_m = provider_m.addTopicMap(src_m);
TopicMapProvider provider_h = tmpf_h.newTopicMapProvider(providerProps);
Locator baseLocator_h = provider_h.getLocatorFactory().createLocator("URI",
getInputURI());
TopicMap tm_h = provider_h.getTopicMap(baseLocator_h);
provider_h.removeTopicMap(tm_h);
tm_h = provider_h.createTopicMap(baseLocator_h);
// Perform a copy
tm_h.getFactory().copy(tm_m);
Stack trace:
Exception in thread "main" org.tm4j.topicmap.TopicMapRuntimeException:
Cause: java.lang.ClassCastException:
org.tm4j.topicmap.memory.TopicImplcannot be cast to
org.tm4j.topicmap.hibernate.TopicImpl
Cause:org.tm4j.topicmap.memory.TopicImpl cannot be cast to
org.tm4j.topicmap.hibernate.TopicImpl
at org.tm4j.topicmap.hibernate.ScopedObjectImpl.setScope(Unknown Source)
at org.tm4j.topicmap.TopicMapFactoryBase.copyScopedObject(
TopicMapFactoryBase.java:741)
at org.tm4j.topicmap.TopicMapFactoryBase.copy(TopicMapFactoryBase.java
:507)
at org.tm4j.topicmap.TopicMapFactoryBase.copy(TopicMapFactoryBase.java
:259)
at org.tm4j.topicmap.TopicMapFactoryBase.copy(TopicMapFactoryBase.java
:212)
at org.tm4j.topicmap.TopicMapFactoryBase.copy(TopicMapFactoryBase.java
:203)
at org.tm4j.topicmap.TopicMapFactoryBase.copy(TopicMapFactoryBase.java
:96)
at com.krl.examples.HibernateProviderTest.setUp(
HibernateProviderTest.java:97)
at com.krl.examples.HibernateProviderTest.main(
HibernateProviderTest.java:108)
Caused by: java.lang.ClassCastException:
org.tm4j.topicmap.memory.TopicImplcannot be cast to
org.tm4j.topicmap.hibernate.TopicImpl
at org.tm4j.topicmap.hibernate.ScopedObjectImpl.setScope(Unknown Source)
... 9 more
Am I missing anything here...
Any help would me much appreciated!!!
--
warm regards
Peri
The best way out of difficulty is through it. :)
|
|
From: SourceForge.net <no...@so...> - 2007-04-11 14:22:39
|
Bugs item #1698489, was opened at 2007-04-11 16:20 Message generated for change (Comment added) made by mediumnet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1698489&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Import/Export Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Xuan Baldauf (mediumnet) Assigned to: Nobody/Anonymous (nobody) Summary: Bursting of filedescriptor usage in org.tm4j.topicmap.cmd.* Initial Comment: When merging a large amount of small XTM files, the number of filedescriptors run out. The reason is that, currently, all files are opened before the first file is processed. This practically makes processing of a certain amount of files in one run impossible. ---------------------------------------------------------------------- >Comment By: Xuan Baldauf (mediumnet) Date: 2007-04-11 16:22 Message: Logged In: YES user_id=506885 Originator: YES The solution works by delaying the actual opening of the underlying FileInputStream or URLInputStream up to the point the files are actually read and by hurrying up closing the underlying InputStream by closing directly after the last byte was read. File Added: onDemandInputStreams.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1698489&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2007-04-11 14:20:23
|
Bugs item #1698489, was opened at 2007-04-11 16:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1698489&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Import/Export Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Xuan Baldauf (mediumnet) Assigned to: Nobody/Anonymous (nobody) Summary: Bursting of filedescriptor usage in org.tm4j.topicmap.cmd.* Initial Comment: When merging a large amount of small XTM files, the number of filedescriptors run out. The reason is that, currently, all files are opened before the first file is processed. This practically makes processing of a certain amount of files in one run impossible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1698489&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2007-04-11 14:14:17
|
Feature Requests item #1698486, was opened at 2007-04-11 16:10 Message generated for change (Comment added) made by mediumnet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=1698486&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: command line apps Group: None Status: Open Priority: 5 Private: No Submitted By: Xuan Baldauf (mediumnet) Assigned to: Nobody/Anonymous (nobody) Summary: Support arguments file Initial Comment: Each platform the Java VM runs on has only a limited amount of arguments. If one wants to merge a massive amount of small XTM files, one may run out of arguments. Thus, the TM4J command line applications should support an "arguments file". That is a file which contains all the arguments without a limit on the number of arguments. ---------------------------------------------------------------------- >Comment By: Xuan Baldauf (mediumnet) Date: 2007-04-11 16:14 Message: Logged In: YES user_id=506885 Originator: YES File Added: argumentsFile.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=1698486&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2007-04-11 14:10:38
|
Feature Requests item #1698486, was opened at 2007-04-11 16:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=1698486&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: command line apps Group: None Status: Open Priority: 5 Private: No Submitted By: Xuan Baldauf (mediumnet) Assigned to: Nobody/Anonymous (nobody) Summary: Support arguments file Initial Comment: Each platform the Java VM runs on has only a limited amount of arguments. If one wants to merge a massive amount of small XTM files, one may run out of arguments. Thus, the TM4J command line applications should support an "arguments file". That is a file which contains all the arguments without a limit on the number of arguments. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=1698486&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2007-04-10 13:11:18
|
Bugs item #1697599, was opened at 2007-04-10 15:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1697599&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Xuan Baldauf (mediumnet) Assigned to: Nobody/Anonymous (nobody) Summary: Topic names are not merged Initial Comment: Be this "input.xtm": <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE topicMap PUBLIC "-//TopicMaps.Org//DTD XML Topic Map (XTM) 1.0//EN" "http://www.topicmaps.org/xtm/1.0/xtm1.dtd"> <topicMap id="x1nndk8s1c-0" xml:base="file:/some/directory/input.xtm" xmlns="http://www.topicmaps.org/xtm/1.0/" xmlns:xlink="http://www.w3.org/1999/xlink"> <topic id="x1nndk8spk-107af"> <baseName id="x1nndk8spk-107b1"> <baseNameString>Guest</baseNameString> </baseName> <baseName id="x1nndk8spk-bc24"> <baseNameString>Guest</baseNameString> </baseName> </topic> </topicMap> If you call "java org.tm4j.topicmap.cmd.Merge -o output.xtm input.xtm", then these two basenames should merge. However, they are not merged, as "output.xtm" will be something like (actual): <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE topicMap PUBLIC "-//TopicMaps.Org//DTD XML Topic Map (XTM) 1.0//EN" "http://www.topicmaps.org/xtm/1.0/xtm1.dtd"> <topicMap id="x1nndk8s1c-0" xml:base="file:/some/directory/output.xtm" xmlns="http://www.topicmaps.org/xtm/1.0/" xmlns:xlink="http://www.w3.org/1999/xlink"> <topic id="x1nndk8spk-107af"> <baseName id="x1nndk8spk-107b1"> <baseNameString>Guest</baseNameString> </baseName> <baseName id="x1nndk8spk-bc24"> <baseNameString>Guest</baseNameString> </baseName> </topic> </topicMap> and not something like (expected): <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE topicMap PUBLIC "-//TopicMaps.Org//DTD XML Topic Map (XTM) 1.0//EN" "http://www.topicmaps.org/xtm/1.0/xtm1.dtd"> <topicMap id="x1nndk8s1c-0" xml:base="file:/some/directory/output.correct.xtm" xmlns="http://www.topicmaps.org/xtm/1.0/" xmlns:xlink="http://www.w3.org/1999/xlink"> <topic id="x1nndk8spk-107af"> <baseName id="x1nndk8spk-485"> <baseNameString>Guest</baseNameString> </baseName> </topic> </topicMap> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1697599&group_id=27895 |
|
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.
>
|
|
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: SourceForge.net <no...@so...> - 2007-04-10 06:06:56
|
Bugs item #1697355, was opened at 2007-04-10 08:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1697355&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Xuan Baldauf (mediumnet) Assigned to: Nobody/Anonymous (nobody) Summary: TMNav deadlocks Initial Comment: I got the current CVS HEAD TM4Nav to deadlock by simply loading an XTM file. (My machine is running in SMP mode.) This is what Ctrl-'\' returns: Found one Java-level deadlock: ============================= "Thread-5": waiting to lock monitor 0x08106dac (object 0x52d208a8, a java.awt.Component$AWTTreeLock), which is held by "AWT-EventQueue-0" "AWT-EventQueue-0": waiting to lock monitor 0x08106eec (object 0x531fa3f0, a com.touchgraph.graphlayout.TGPanel), which is held by "Thread-5" Java stack information for the threads listed above: =================================================== "Thread-5": at java.awt.Component.reshape(Component.java:1858) - waiting to lock <0x52d208a8> (a java.awt.Component$AWTTreeLock) at javax.swing.JComponent.reshape(JComponent.java:3940) at java.awt.Component.setBounds(Component.java:1847) at javax.swing.plaf.basic.BasicScrollBarUI.layoutHScrollbar(BasicScrollBarUI.java:732) at javax.swing.plaf.basic.BasicScrollBarUI.layoutContainer(BasicScrollBarUI.java:775) at javax.swing.plaf.basic.BasicScrollBarUI$ModelListener.stateChanged(BasicScrollBarUI.java:935) at javax.swing.DefaultBoundedRangeModel.fireStateChanged(DefaultBoundedRangeModel.java:348) at javax.swing.DefaultBoundedRangeModel.setRangeProperties(DefaultBoundedRangeModel.java:285) at javax.swing.DefaultBoundedRangeModel.setValue(DefaultBoundedRangeModel.java:151) at javax.swing.JScrollBar.setValue(JScrollBar.java:441) at com.touchgraph.graphlayout.interaction.HVScroll$DScrollbar.setIValue(HVScroll.java:189) at com.touchgraph.graphlayout.interaction.HVScroll$DScrollbar.setDValue(HVScroll.java:192) at com.touchgraph.graphlayout.interaction.HVScroll.graphMoved(HVScroll.java:161) at com.touchgraph.graphlayout.TGPanel.fireMovedEvent(TGPanel.java:407) at com.touchgraph.graphlayout.TGPanel.repaintAfterMove(TGPanel.java:755) - locked <0x531fa3f0> (a com.touchgraph.graphlayout.TGPanel) at com.touchgraph.graphlayout.TGLayout.relax(TGLayout.java:321) - locked <0x52e6f1f0> (a com.touchgraph.graphlayout.TGLayout) at com.touchgraph.graphlayout.TGLayout.run(TGLayout.java:336) at java.lang.Thread.run(Thread.java:595) "AWT-EventQueue-0": at com.touchgraph.graphlayout.TGPanel.paint(TGPanel.java:793) - waiting to lock <0x531fa3f0> (a com.touchgraph.graphlayout.TGPanel) at javax.swing.JComponent.paintChildren(JComponent.java:842) - locked <0x52d208a8> (a java.awt.Component$AWTTreeLock) at javax.swing.JComponent.paint(JComponent.java:1014) at javax.swing.JComponent.paintChildren(JComponent.java:842) - locked <0x52d208a8> (a java.awt.Component$AWTTreeLock) at javax.swing.JComponent.paint(JComponent.java:1014) at javax.swing.JComponent.paintChildren(JComponent.java:842) - locked <0x52d208a8> (a java.awt.Component$AWTTreeLock) at javax.swing.JSplitPane.paintChildren(JSplitPane.java:1021) at javax.swing.JComponent.paint(JComponent.java:1014) at javax.swing.JComponent.paintWithOffscreenBuffer(JComponent.java:4963) at javax.swing.JComponent.paintDoubleBuffered(JComponent.java:4916) at javax.swing.JComponent._paintImmediately(JComponent.java:4859) at javax.swing.JComponent.paintImmediately(JComponent.java:4666) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:451) at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:114) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209) at java.awt.EventQueue.dispatchEvent(EventQueue.java:461) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) Found 1 deadlock. It seems that TGLayout (1) either runs separately of the event dispatch thread while it should not (2) or effectively calls Swing methods while it should not (because calling Swing methods is only safe within the event dispatch thread). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1697355&group_id=27895 |
|
From:
<xua...@ba...> - 2007-04-08 02:31:08
|
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:
<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: SourceForge.net <no...@so...> - 2007-02-15 14:57:55
|
Bugs item #1501213, was opened at 2006-06-05 22:23 Message generated for change (Comment added) made by lheuer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1501213&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: In-Memory Impl Group: CVS >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Xuan Baldauf (mediumnet) Assigned to: Nobody/Anonymous (nobody) Summary: MemberImpl.hashCode() is not consistent with equals() Initial Comment: When the constructor org.tm4j.topicmap.memory.MemberImpl( AssociationImpl parent, String id, Locator resourceLoc, Topic roleSpec, Collection players) is used, the to-be-constructed MemberImpl adds itself to each m_rolesPlayed field of every TopicImpl of the players collection. This field is a HashSet, and thus, hashCode() of the MemberImpl object is called. The method hashCode() (defined in org.tm4j.topicmap.memory.TopicMapObjectImpl) itself depends on the id of the MemberImpl object. However, the id is currently set ("setID(id);") _after_ the to-be-constructed MemberImpl adds itself to each m_rolesPlayed field of every TopicImpl of the players collection. Thus, hashCode() returns different values at different times (with a very high probability). In particular, hashCode() returns a different value before the call to setID(id) than after the call to setID(id). This, in turn, makes the call "m_rolesPlayed.contains(member)" in org.tm4j.topicmap.memory.TopicImpl.removeRolePlayed(Member member) return false, while it should return true. >From this on, the topic map data structure is inconsistent (and messed up). ---------------------------------------------------------------------- >Comment By: Lars Heuer (lheuer) Date: 2007-02-15 15:57 Message: Logged In: YES user_id=399396 Originator: NO Fixed in CVS. Thanks ---------------------------------------------------------------------- Comment By: Xuan Baldauf (mediumnet) Date: 2006-06-05 22:25 Message: Logged In: YES user_id=506885 This patch should fix the problem: Index: tm4j/src/org/tm4j/topicmap/memory/MemberImpl.java =================================================================== RCS file: /cvsroot/tm4j/tm4j/src/org/tm4j/topicmap/memory/MemberImpl.java,v retrieving revision 1.24 diff -u -r1.24 MemberImpl.java --- tm4j/src/org/tm4j/topicmap/memory/MemberImpl.java 7 Mar 2006 15:36:35 -0000 1.24 +++ tm4j/src/org/tm4j/topicmap/memory/MemberImpl.java 5 Jun 2006 20:08:49 -0000 @@ -56,14 +56,14 @@ m_roleSpec = roleSpec; m_players = new ArrayList(players); + if (resourceLoc != null) addSourceLocator(resourceLoc); + setID(id); for (Iterator it = m_players.iterator(); it.hasNext();) { TopicImpl t = (TopicImpl) it.next(); // TODO: Avoid the access of the Topic.m_rolesPlayed field t.m_rolesPlayed.add(this); } - if (resourceLoc != null) addSourceLocator(resourceLoc); - setID(id); parent.addMember(this); } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1501213&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2006-11-15 08:50:04
|
Feature Requests item #1596758, was opened at 2006-11-15 03:10 Message generated for change (Comment added) made by kal_ahmed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=1596758&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface Improvements (example) Group: Next Release (example) Status: Open Priority: 3 Private: No Submitted By: Ichiro Furusato (ifurusato) Assigned to: Nobody/Anonymous (nobody) Summary: support subjectIndicatorRef in parameters Initial Comment: currently the Variant interface includes an addParameter(Topic) method, but XTM 1.0 also permits <subjectIndicatorRef> elements as children of <parameters>, so there should probably be an addParameter(Locator) method in the API as well. Calls to this method would add a Locator instead of a Topic. When one doesn't want to reify the subject of the parameter (such as XTM 'Display') as a Topic, this would be welcome. ---------------------------------------------------------------------- >Comment By: Kal Ahmed (kal_ahmed) Date: 2006-11-15 08:50 Message: Logged In: YES user_id=176992 Originator: NO My feeling is that the underlying data model should keep all parameters as topics, otherwise it gets messy for a programmer calling getParameters to have to deal with a list of Topic and Locator objects. However, a convenience method addParameter(Locator l) could operate as follows: 1) Find a topic with subject identifier l. If found add that topic as a parameter otherwise, 2) Find a topic with source locator l. If found add that topic as a parameter otherwise, 3) Create a new topic and add l as a subject identifier then add that topic as a parameter. (Note that step (2) is required because a topic T with subject identifier L will merge with a topic T with source locator L under topic map merging rules, so if you didn't do that step then step (3) would create a topic which would instantly get merged). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=1596758&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2006-11-15 03:10:04
|
Feature Requests item #1596758, was opened at 2006-11-15 03:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=1596758&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface Improvements (example) Group: Next Release (example) Status: Open Priority: 3 Private: No Submitted By: Ichiro Furusato (ifurusato) Assigned to: Nobody/Anonymous (nobody) Summary: support subjectIndicatorRef in parameters Initial Comment: currently the Variant interface includes an addParameter(Topic) method, but XTM 1.0 also permits <subjectIndicatorRef> elements as children of <parameters>, so there should probably be an addParameter(Locator) method in the API as well. Calls to this method would add a Locator instead of a Topic. When one doesn't want to reify the subject of the parameter (such as XTM 'Display') as a Topic, this would be welcome. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=1596758&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2006-11-15 02:51:26
|
Bugs item #1596060, was opened at 2006-11-14 04:19 Message generated for change (Comment added) made by ifurusato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1596060&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Utilities Group: TM4J 0.9.7 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ichiro Furusato (ifurusato) Assigned to: Nobody/Anonymous (nobody) Summary: XTMWriter writes invalid baseName markup Initial Comment: The content model in XTM 1.0 for <baseName> is (scope?,baseNameString,variant*), but the current XTMWriter code is putting the baseNameString after the variants, not before them. This is a simple fix in XTMWriter of moving the writeBaseNameString() method call from endBaseName() to the end of the startBaseName() method. ---------------------------------------------------------------------- >Comment By: Ichiro Furusato (ifurusato) Date: 2006-11-15 02:51 Message: Logged In: YES user_id=1641765 Originator: YES Not such a simple fix after all. It seems that rather than closing off an open <baseName> upon receiving the event for a variant, it's creating a new <baseName> and putting the <variant> in that. Because the latter doesn't have a <baseNameString> of its own, the element is invalid. This might be happening in the tree walker. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1596060&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2006-11-15 02:30:04
|
Bugs item #1596744, was opened at 2006-11-15 02:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1596744&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: In-Memory Impl Group: TM4J 0.9.7 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ichiro Furusato (ifurusato) Assigned to: Nobody/Anonymous (nobody) Summary: CME on removeMergedTopics() Initial Comment: The memory.TopicImpl#removeMergedTopics() method uses an Iterator, which causes a ConcurrentModificationException when the Collection it is operating upon is modified. Changing to a for loop over an array solves this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1596744&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2006-11-14 04:19:48
|
Bugs item #1596060, was opened at 2006-11-14 04:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1596060&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Utilities Group: TM4J 0.9.7 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ichiro Furusato (ifurusato) Assigned to: Nobody/Anonymous (nobody) Summary: XTMWriter writes invalid baseName markup Initial Comment: The content model in XTM 1.0 for <baseName> is (scope?,baseNameString,variant*), but the current XTMWriter code is putting the baseNameString after the variants, not before them. This is a simple fix in XTMWriter of moving the writeBaseNameString() method call from endBaseName() to the end of the startBaseName() method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1596060&group_id=27895 |
|
From: Gerasimos R. <hag...@11...> - 2006-10-23 15:46:57
|
Hi, GREAT VlbAGRA http://www.ladesikderionpadeiasa.com =20 turned back and spread his arms wide. Gotta keep going, what can I do? |
153 messages has been excluded from this view by a project administrator.
