Menu
▾
▴
tinytim-discuss
|
From: Lars H. <he...@se...> - 2009-08-13 11:53:19
|
Hi all, I wonder if it makes sense to add another tinyTiM distribution (especially for mio). While I like the current distribution (just pick the mio libs you're actually using, and update the mio libs independently of tinytim-mio), I think it might be nice to have one jar with batteries included. That lib would include all semagia-mio dependencies, so the user needs only the slf4j-libs and (if validation is necessary), the jing lib. I could also include the slf4j-libs, if that's worth. Maybe I could also add another (meta) distribution which includes the engine and the tinytim-mio package. The disadvantage would be, that releasing tinytim-mio and tinytim wouldn't be independent anymore. What do you think? Would a) tinytim-mio-batteries-included b) meta-tinytim (the engine and mio) be a good addition to the current distribution model? Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Markus U. <mar...@gm...> - 2009-08-13 13:47:21
|
Hi Lars, Lars Heuer schrieb: > [...] What do you think? Would > a) tinytim-mio-batteries-included > b) meta-tinytim (the engine and mio) > be a good addition to the current distribution model? ad a) Maybe it would make life at tiny litte bit easier for those who want to try out tinytim _fast_ (e.g., after reading a short TM(API) intro with code fragments), but personally I'd never use it (cf. the Ontopia repository discussion regarding (rather well-known) third party libraries like slf4j -- they could either be automatically retrieved or at least a short description where to obtain them by means of 2-3 mouse clicks should IMHO be enough). ad b) Why should this mean that tinytim and tinytim-mio releases wouldn't be independent anymore? Wouldn't the meta-release simply include/reference the respective latest official releases? Ad astra, Markus |
|
From: Lars H. <he...@se...> - 2009-08-13 13:57:43
|
Hi Markus, >> [...] What do you think? Would >> a) tinytim-mio-batteries-included >> b) meta-tinytim (the engine and mio) >> be a good addition to the current distribution model? > ad a) Maybe it would make life at tiny litte bit easier for those who > want to try out tinytim _fast_ (e.g., after reading a short TM(API) [...] Yes, I have that kind of users in mind. And those who want to use tinyTiM in Applets. I am not sure if I'd use that distribution, it would just be an offer for users who want to place two libs in the CP and start with TMAPI, as you stated above. > ad b) Why should this mean that tinytim and tinytim-mio releases > wouldn't be independent anymore? Wouldn't the meta-release simply > include/reference the respective latest official releases? You're right. Although the meta distribution would either be outdated if we release tinytim-mio (without a new release of tinytim) or the meta distribution has to be updated at each release of tinytim-mio and tinytim. I think, I'll offer (a) first and maybe (b) later. Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Lars H. <he...@se...> - 2009-08-13 14:34:49
|
Hi Hannes,
>> For the record:
>> +1 for a "v.(tinytim)/v.(tinytim-mio)" meta distribution which gets
>> updated with each respective release from me ;)
> and +1 from me.
> Question is how would the version looklike for this distribution ?
:) Good question. For (a) could be something like
tinytim-mio-all-{version}.jar where {version} represents the current
tinytim-mio version.
For (b) this could be more difficult. Maybe the engine version number
should rule and for each -mio release a patch level is added?
tinytim-complete-{version}.sp1.jar
Hmmm.... better ideas? :)
The goal of the additional distributions should be to ease the start
with tinyTiM and not to confuse users... ;)
Best regards,
Lars
--
Semagia
<http://www.semagia.com>
|
|
From: Lars H. <he...@se...> - 2009-08-13 14:51:48
|
Hi Markus, [...] > I'd simply concatenate the versions as follows: > "tinytim-meta-2.0.0a5-0.9.5.jar" (I prefer "meta" over "complete" here, > because there's also tinytim-console, tinytim-schema etc.) Thanks for the hint that these sub projects have to be maintained. ;) > This way, the engine version 'dominates' and it also shouldn't confuse > users, because it would still mean that a 'larger' combined version Okay, but the scheme would look like: tinytim-meta-2.0.0a5-2.0.0a5.jar which implies the tinytim version 2.0.0a5 and tinytim-mio 2.0.0a5. If tinytim-mio a6 is released, we get: tinytim-meta-2.0.0a5-2.0.0a6.jar > (the stituation where a newer engine version > requires an older mio version shouldn't be likely to happen, right?) Unlikely. :) Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Markus U. <mar...@gm...> - 2009-08-13 14:16:23
|
Hi Lars, >> ad b) Why should this mean that tinytim and tinytim-mio releases >> wouldn't be independent anymore? Wouldn't the meta-release simply >> include/reference the respective latest official releases? >> > You're right. Although the meta distribution would either be outdated > if we release tinytim-mio (without a new release of tinytim) or the > meta distribution has to be updated at each release of tinytim-mio and > tinytim. > I think, I'll offer (a) first and maybe (b) later. > For the record: +1 for a "v.(tinytim)/v.(tinytim-mio)" meta distribution which gets updated with each respective release from me ;) Ad astra, Markus |
|
From: Hannes N. <h.n...@go...> - 2009-08-13 14:26:31
|
> For the record: > +1 for a "v.(tinytim)/v.(tinytim-mio)" meta distribution which gets > updated with each respective release from me ;) and +1 from me. Question is how would the version looklike for this distribution ? regards Hannes -- Onotoa - Simply create your Topic Maps schemas. http://onotoa.topicmapslab.de http://www.topicmapslab.de/people/Hannes_Niederhausen |
|
From: Markus U. <mar...@gm...> - 2009-08-13 14:45:35
|
Hi all,
> For (b) this could be more difficult. Maybe the engine version number
> should rule and for each -mio release a patch level is added?
>
> tinytim-complete-{version}.sp1.jar
>
> Hmmm.... better ideas? :)
>
> The goal of the additional distributions should be to ease the start
> with tinyTiM and not to confuse users... ;)
>
I'd simply concatenate the versions as follows:
"tinytim-meta-2.0.0a5-0.9.5.jar" (I prefer "meta" over "complete" here,
because there's also tinytim-console, tinytim-schema etc.)
This way, the engine version 'dominates' and it also shouldn't confuse
users, because it would still mean that a 'larger' combined version
refers to a newer archive (the stituation where a newer engine version
requires an older mio version shouldn't be likely to happen, right?)
Ad astra, Markus
|
|
From: Markus U. <mar...@gm...> - 2009-08-13 15:02:36
|
Hi Lars, >> I'd simply concatenate the versions as follows: >> "tinytim-meta-2.0.0a5-0.9.5.jar" (I prefer "meta" over "complete" here, >> because there's also tinytim-console, tinytim-schema etc.) >> > Okay, but the scheme would look like: > > tinytim-meta-2.0.0a5-2.0.0a5.jar You're right, I mixed up the versions of tinytim-mio and semagia-mio. Still, this doesn't look too bad. Then, another possibility would be "tinytim-2.0.0a5-mio-2.0.0a5.jar" (in which case we maybe could even omit the 'meta' prefix). Ad astra, Markus |
|
From: Lars H. <he...@se...> - 2009-08-13 15:12:58
|
Hi Markus,
[...]
> Then, another possibility would be
> "tinytim-2.0.0a5-mio-2.0.0a5.jar" (in
> which case we maybe could even omit the 'meta' prefix).
Good idea, I like it. :) If nobody comes up with a better scheme, I'll
use
tinytim-{engine-version}-mio-{mio-version}.jar
for the "meta" package.
... and once I've finished console and schema, I'll add a meta meta
package
tinytim-{engine-version}-mio-{mio-version}-schema-{schema-version}-console-{console-version}.jar
and all permutations of it. ;)))
Best regards,
Lars
--
Semagia
<http://www.semagia.com>
|
|
From: Lars H. <he...@se...> - 2009-08-14 13:05:15
|
Hi all, [...] > a) tinytim-mio-batteries-included > b) meta-tinytim (the engine and mio) Even if I wrote yesterday, that I'd do (a) first and then (b), I changed my opinion, that I only do (b). :) The reason: I want to avoid that tinytim-mio steals the package names "com.semagia.mio.*" and "org.slf4j.*", so I move these packages into org.tinytim.mio.something and the com.semagia.mio.IMapHandler is then called "org.tinytim.mio.something.IMapHandler". But tinyTiM's IMapHandler implementation belongs to the tinytim.jar and therefor won't find the repackaged interface IMapHandler. Are you still following? ;) To cut the long story short: (b) is easier to achieve than (a), that's all. :) Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Markus U. <mar...@gm...> - 2009-08-14 14:04:43
|
Lars Heuer schrieb: > [...] so I move these packages into > org.tinytim.mio.something I like that naming scheme: - org.tinytim.mio.something.ugly <-- this is where workarounds go - org.tinytim.mio.somethingelse <-- the place for awesome code - org.tinytim.mio.differentthing <-- things the authors don't agree with/grok fully (Sorry, couldn't resist...) Ad astra, Markus |
|
From: Lars H. <he...@se...> - 2009-08-15 13:08:09
|
Hi Markus, [...] > I like that naming scheme: > - org.tinytim.mio.something.ugly <-- this is where workarounds go > - org.tinytim.mio.somethingelse <-- the place for awesome code > - org.tinytim.mio.differentthing <-- things the authors don't agree > with/grok fully Hmm..... I've to think about it... ;) Maybe I should add another distribution: "ueberall-chaos" ... ;) Best regards, Lars -- Semagia <http://www.semagia.com/> |
×
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