Menu
▾
▴
tm4j-developers
|
From:
<xua...@ba...> - 2008-01-26 15:35:21
|
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). 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/MercurialOnSourcefo=
rge
.
* 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.
It would be nice if you could give your comments or you "amen" (or
"ramen" if you believe in FSM) to these changes within the next days or
weeks and if anybody else could comment on it.
ciao,
Xu=E2n.
P.S.: Who is the "operational" project admin of TM4J (is there any?). It
looks like the developer of the Ruby Topic Maps engine (
http://rtm.rubyforge.org/ ) is going to need commit rights at some
future point in time, and it would be nice to know who to ask. We are
currently planning a bridge between Ruby and Java such that RTM may be
able to use TM4J as a backend. Furthermore, we are currently playing
around with automatic generation of Java topicmap engines using Ruby
domain specific languages (thus vastly improving development speed, as
many codings once done for one TopicMapConstruct have to be repeated
very similarily for all the other TopicMapConstructs). It also possible
to generate topic map engines with different properties (e.g. engines
where locators are represented internally not as Locator objects, but as
plain UTF-16 sequences or as plain UTF-8 sequences, improving memory
usage, or engines where different ways of indexing are used). At some
point of time, it may be good for TM4J engines to be generatable in this
way.
|
|
From: Kal A. <ka...@ne...> - 2008-01-28 08:49:47
|
Hi Xu=E2n, =20 Right now, Conal Tuohy and Ichiro Furusato are the main development = leads for TM4J since I took a back seat to concentrate on Networked = Planet work. So I will defer to them in questions of the development = environment. My concern with Mercurial would be about the level at which = it is supported by the SourceForge team. While it is nice to have the = latest shiny toys to play with, it is also nice to have a system that = someone else looks after ;-) =20 With regards to generating topic map engines and the such like - domain = specific languages certainly hold out a lot of hope for generating the = basic structure, but I would imagine that the logic (e.g. the logic of = merging) would still have to be hand coded, so I don't know how much of = a real saving they would provide. We (NetworkedPlanet) used MS's DSL = tools to generate a topic map ontology editor and that worked quite = nicely but even that relatively simple domain-specific language required = a fair amount of hand-written code to work properly. =20 Finally on Locators, the logic behind the Locator structure in the = original TM4J was that it should be possible to support a wider range of = locator syntaxes than URI/URL syntax. In practice, URIs (or maybe IRIs) = have won and the Locator class is probably something of an anachronism - = a simple Unicode character sequence (backed up with the library = functions for parsing and handling those strings as URIs) should work = for a "new" topic map engine. =20 Cheers =20 Kal =20 From: Xu=E2n Baldauf = [mailto:xuan--2008.01.27--tm4j-developers--lists.sourceforge.net@baldauf.= org]=20 Sent: 26 January 2008 15:33 To: Kal Ahmed Cc: tm4...@li... Subject: Improving development environment for TM4J =20 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). 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 . * 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. It would be nice if you could give your comments or you "amen" (or = "ramen" if you believe in FSM) to these changes within the next days or = weeks and if anybody else could comment on it. ciao, Xu=E2n. P.S.: Who is the "operational" project admin of TM4J (is there any?). It = looks like the developer of the Ruby Topic Maps engine ( = http://rtm.rubyforge.org/ ) is going to need commit rights at some = future point in time, and it would be nice to know who to ask. We are = currently planning a bridge between Ruby and Java such that RTM may be = able to use TM4J as a backend. Furthermore, we are currently playing = around with automatic generation of Java topicmap engines using Ruby = domain specific languages (thus vastly improving development speed, as = many codings once done for one TopicMapConstruct have to be repeated = very similarily for all the other TopicMapConstructs). It also possible = to generate topic map engines with different properties (e.g. engines = where locators are represented internally not as Locator objects, but as = plain UTF-16 sequences or as plain UTF-8 sequences, improving memory = usage, or engines where different ways of indexing are used). At some = point of time, it may be good for TM4J engines to be generatable in this = way. |
|
From: Lars M. G. <la...@ga...> - 2008-01-28 14:21:04
|
* Kal Ahmed > > Finally on Locators, the logic behind the Locator structure in the =20 > original TM4J was that it should be possible to support a wider =20 > range of locator syntaxes than URI/URL syntax. In practice, URIs (or =20= > maybe IRIs) have won and the Locator class is probably something of =20= > an anachronism =96 a simple Unicode character sequence (backed up with = =20 > the library functions for parsing and handling those strings as =20 > URIs) should work for a =93new=94 topic map engine. A word of caution here: URI processing is quite complex, and in Topic =20= Maps import it's also performance-critical. Small changes to how URIs =20= are processed can mean a huge difference in the time needed to load an =20= XTM file. This may sound strange until you stop to consider just how =20 many URIs there are in an XTM file. The built-in Java classes for URIs have quite a few issues in this =20 regard, and so you may want to consider keeping some sort of interface =20= in front here in order to give yourself latitude to make this efficient. --Lars M.= |
|
From: Conal T. <con...@vu...> - 2008-01-28 22:41:23
|
On Mon, 2008-01-28 at 15:21 +0100, Lars Marius Garshol wrote: > * Kal Ahmed > > > > Finally on Locators, the logic behind the Locator structure in the =20 > > original TM4J was that it should be possible to support a wider =20 > > range of locator syntaxes than URI/URL syntax. In practice, URIs (or =20 > > maybe IRIs) have won and the Locator class is probably something of =20 > > an anachronism =E2=80=93 a simple Unicode character sequence (backed up= with =20 > > the library functions for parsing and handling those strings as =20 > > URIs) should work for a =E2=80=9Cnew=E2=80=9D topic map engine. >=20 > A word of caution here: URI processing is quite complex, and in Topic =20 > Maps import it's also performance-critical. Small changes to how URIs =20 > are processed can mean a huge difference in the time needed to load an =20 > XTM file. This may sound strange until you stop to consider just how =20 > many URIs there are in an XTM file. >=20 > The built-in Java classes for URIs have quite a few issues in this =20 > regard, and so you may want to consider keeping some sort of interface =20 > in front here in order to give yourself latitude to make this efficient. Personally I've never used Locators of any other type than URI, since I've been using XTM for input, but I agree with Lars that the API needs a "Locator" abstraction. I don't think there's anything in the Locator interface which imposes a heavy memory footprint is there? --=20 Conal Tuohy New Zealand Electronic Text Centre www.nzetc.org |
|
From: Conal T. <con...@vu...> - 2008-03-10 05:51:20
|
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 |
|
From: Xuân B. <xua...@ba...> - 2008-03-11 09:08:05
|
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. |
×
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