|
»
»
»
Code layout
|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
 |
Code layout
by Taylor Gautier-2
::
Rate this Message:
There have been a number of utility like and pattern like
implementations going into forge/labs. I have been thinking about how
best to organize these things. Here's my thinking to date, I'm open to
suggestions or just voting for one of the options below.
At the moment I know of:
1) All in one package. On the one extreme, this makes using any TC based util class (or pattern) really easy. Until there is too much in one package, this what I prefer, except it tends to have version creep that doesn't correspond to relevant features - in other words a developer uses it only for JMX, but the version bumps because of a fix for annotations 2) A Balanced set of packages. I would propose
3) Lots of little packages - basically everything in its own package. This is my least favorite option. Thoughts? _______________________________________________ tc-users mailing list tc-users@... http://lists.terracotta.org/mailman/listinfo/tc-users |
|
|
Re: Code layout
by Geert Bevin
::
Rate this Message:
The "All in one package" option takes my preference.
On 2/12/08, Taylor Gautier <tgautier@...> wrote: > > There have been a number of utility like and pattern like implementations > going into forge/labs. I have been thinking about how best to organize > these things. Here's my thinking to date, I'm open to suggestions or just > voting for one of the options below. > > At the moment I know of: > > > > ResourceManager - a pair of classes that level a shared resource across a > cluster (relies on JMX util) > Pipes/Channels - refactoring of the pipe/channel idea in m/w > Master/Worker - work load balancer > > JMX Util - JMX event util classes > > Annotations - annotations > > SplitHashMap - rough equivalent of concurrenthashmap > > TimeSeriesMap - to expire items in a map based on time entries So, I am not > sure, I can argue a few different layouts: > > 1) All in one package. On the one extreme, this makes using any TC based > util class (or pattern) really easy. Until there is too much in one > package, this what I prefer, except it tends to have version creep that > doesn't correspond to relevant features - in other words a developer uses it > only for JMX, but the version bumps because of a fix for annotations > > 2) A Balanced set of packages. I would propose > > > tc-util - contains pipe/channel, resourcemanager, jmxutil, splithashmap, > timeseriesmap > > annotations - annotations only > > master/woker - m/w only, but needs tc-util for both pipe/channel and jmx > 3) Lots of little packages - basically everything in its own package. This > is my least favorite option. > > > > Thoughts? > -- Geert Bevin Terracotta - http://www.terracotta.org Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com _______________________________________________ tc-users mailing list tc-users@... http://lists.terracotta.org/mailman/listinfo/tc-users |
|
|
Re: [tc-dev] Code layout
by sharrissf
::
Rate this Message:
I like the small packages and then bigger packages that can be built that hold batches of them. Maybe split and time series map could be together
in the collections one. Cheers, Steve On Feb 12, 2008, at 2:54 PM, Taylor Gautier wrote:
_______________________________________________ tc-users mailing list tc-users@... http://lists.terracotta.org/mailman/listinfo/tc-users |
|
|
Re: Code layout
by Alex Miller-8
::
Rate this Message:
I'd vote for the balanced set #2.
----- Original Message ----- From: "Taylor Gautier" <tgautier@...> To: "Jonas Bonér" <jonas@...>, "Geert Bevin" <gbevin@...>, "Alex Miller" <amiller@...>, "Kunal Bhasin" <kbhasin@...>, "Juris Galang" <jgalang@...>, "Jason Voegele" <jvoegele@...>, tc-dev@..., tc-users@... Sent: Tuesday, February 12, 2008 4:54:56 PM (GMT-0600) America/Chicago Subject: Code layout There have been a number of utility like and pattern like implementations going into forge/labs. I have been thinking about how best to organize these things. Here's my thinking to date, I'm open to suggestions or just voting for one of the options below. At the moment I know of: • ResourceManager - a pair of classes that level a shared resource across a cluster (relies on JMX util) • Pipes/Channels - refactoring of the pipe/channel idea in m/w • Master/Worker - work load balancer • JMX Util - JMX event util classes • Annotations - annotations • SplitHashMap - rough equivalent of concurrenthashmap • TimeSeriesMap - to expire items in a map based on time entries So, I am not sure, I can argue a few different layouts: 1) All in one package. On the one extreme, this makes using any TC based util class (or pattern) really easy. Until there is too much in one package, this what I prefer, except it tends to have version creep that doesn't correspond to relevant features - in other words a developer uses it only for JMX, but the version bumps because of a fix for annotations 2) A Balanced set of packages. I would propose • tc-util - contains pipe/channel, resourcemanager, jmxutil, splithashmap, timeseriesmap • annotations - annotations only • master/woker - m/w only, but needs tc-util for both pipe/channel and jmx 3) Lots of little packages - basically everything in its own package. This is my least favorite option. Thoughts? _______________________________________________ tc-users mailing list tc-users@... http://lists.terracotta.org/mailman/listinfo/tc-users |
|
|
Re: [tc-dev] Code layout
by sharrissf
::
Rate this Message:
What does jmx utils have to do with split hashmap? Why would they be
packaged together? On Feb 12, 2008, at 3:19 PM, Alex Miller wrote: > I'd vote for the balanced set #2. > > ----- Original Message ----- > From: "Taylor Gautier" <tgautier@...> > To: "Jonas Bonér" <jonas@...>, "Geert Bevin" <gbevin@... > >, "Alex Miller" <amiller@...>, "Kunal Bhasin" <kbhasin@... > >, "Juris Galang" <jgalang@...>, "Jason Voegele" <jvoegele@... > >, tc-dev@..., tc-users@... > Sent: Tuesday, February 12, 2008 4:54:56 PM (GMT-0600) America/Chicago > Subject: Code layout > > > There have been a number of utility like and pattern like > implementations going into forge/labs. I have been thinking about > how best to organize these things. Here's my thinking to date, I'm > open to suggestions or just voting for one of the options below. > > At the moment I know of: > > > > • ResourceManager - a pair of classes that level a shared > resource across a cluster (relies on JMX util) > • Pipes/Channels - refactoring of the pipe/channel idea in m/w > • Master/Worker - work load balancer > • JMX Util - JMX event util classes > • Annotations - annotations > • SplitHashMap - rough equivalent of concurrenthashmap > • TimeSeriesMap - to expire items in a map based on time entries > So, I am not sure, I can argue a few different layouts: > > 1) All in one package. On the one extreme, this makes using any TC > based util class (or pattern) really easy. Until there is too much > in one package, this what I prefer, except it tends to have version > creep that doesn't correspond to relevant features - in other words > a developer uses it only for JMX, but the version bumps because of a > fix for annotations > > 2) A Balanced set of packages. I would propose > > > • tc-util - contains pipe/channel, resourcemanager, jmxutil, > splithashmap, timeseriesmap > • annotations - annotations only > • master/woker - m/w only, but needs tc-util for both pipe/ > channel and jmx > > 3) Lots of little packages - basically everything in its own > package. This is my least favorite option. > > > > Thoughts? > > _______________________________________________ > tc-dev mailing list > tc-dev@... > http://lists.terracotta.org/mailman/listinfo/tc-dev _______________________________________________ tc-users mailing list tc-users@... http://lists.terracotta.org/mailman/listinfo/tc-users |
|
|
Re: [tc-dev] Code layout
by Kunal Bhasin
::
Rate this Message:
I actually checked in the Split and TimeSeries map in the collections
tim as it seemed like the logical thing to do at the time. I agree that we should package modules together according to some guidelines so we know where to put a new module and users don't end up with lots of different modules (#3). As long as we have the discipline of updating the documentation around usage of these components, which package they go in is just matter of some logical commonality. On a high level, I would recommend three buckets for now: 1. Util: JMX util, ResourceManager, Annotations etc. 2. Patterns: Master/Worker, Listener, JobScheduler etc. 3. Collections: TC optimized collections i.e. TimeSeriesMap, SplitMap etc. and maybe some generalized evictor implementations. Any frameworks can be self-contained tims i.e. caches, loaders etc. till we feel the need to have a framework bucket as well. Kunal. On Feb 12, 2008, at 3:21 PM, Steven Harris wrote: > What does jmx utils have to do with split hashmap? Why would they be > packaged together? > > On Feb 12, 2008, at 3:19 PM, Alex Miller wrote: > >> I'd vote for the balanced set #2. >> >> ----- Original Message ----- >> From: "Taylor Gautier" <tgautier@...> >> To: "Jonas Bonér" <jonas@...>, "Geert Bevin" <gbevin@... >> >, "Alex Miller" <amiller@...>, "Kunal Bhasin" <kbhasin@... >> >, "Juris Galang" <jgalang@...>, "Jason Voegele" <jvoegele@... >> >, tc-dev@..., tc-users@... >> Sent: Tuesday, February 12, 2008 4:54:56 PM (GMT-0600) America/ >> Chicago >> Subject: Code layout >> >> >> There have been a number of utility like and pattern like >> implementations going into forge/labs. I have been thinking about >> how best to organize these things. Here's my thinking to date, I'm >> open to suggestions or just voting for one of the options below. >> >> At the moment I know of: >> >> >> >> • ResourceManager - a pair of classes that level a shared >> resource across a cluster (relies on JMX util) >> • Pipes/Channels - refactoring of the pipe/channel idea in m/w >> • Master/Worker - work load balancer >> • JMX Util - JMX event util classes >> • Annotations - annotations >> • SplitHashMap - rough equivalent of concurrenthashmap >> • TimeSeriesMap - to expire items in a map based on time entries >> So, I am not sure, I can argue a few different layouts: >> >> 1) All in one package. On the one extreme, this makes using any TC >> based util class (or pattern) really easy. Until there is too much >> in one package, this what I prefer, except it tends to have version >> creep that doesn't correspond to relevant features - in other words >> a developer uses it only for JMX, but the version bumps because of >> a fix for annotations >> >> 2) A Balanced set of packages. I would propose >> >> >> • tc-util - contains pipe/channel, resourcemanager, jmxutil, >> splithashmap, timeseriesmap >> • annotations - annotations only >> • master/woker - m/w only, but needs tc-util for both pipe/ >> channel and jmx >> >> 3) Lots of little packages - basically everything in its own >> package. This is my least favorite option. >> >> >> >> Thoughts? >> >> _______________________________________________ >> tc-dev mailing list >> tc-dev@... >> http://lists.terracotta.org/mailman/listinfo/tc-dev > _______________________________________________ tc-users mailing list tc-users@... http://lists.terracotta.org/mailman/listinfo/tc-users |
|
|
Re: Code layout
by Eugene Kuleshov-6
::
Rate this Message:
Geert Bevin wrote:
> The "All in one package" option takes my preference. > He he. That is because you don't dig the dependency management tools. :-) Anyways, I'd say that at least annotations should be in its on separate TIM project. Everything else might be simply reusable components that could be split between few packages based on their own dependencies like dependency on JMX API. regards, Eugene _______________________________________________ tc-users mailing list tc-users@... http://lists.terracotta.org/mailman/listinfo/tc-users |
|
|
Re: [tc-dev] Code layout
by Alex Miller-8
::
Rate this Message:
I'm voting more for the idea of putting like things together than any particular arrangement. I think jmx utils does not make sense with split hashamp - would make more sense to put collections together.
----- Original Message ----- From: "Steven Harris" <steve@...> To: tc-dev@... Cc: tc-users@..., "Kunal Bhasin" <kbhasin@...>, "Jonas Bonér" <jonas@...>, "Geert Bevin" <gbevin@...> Sent: Tuesday, February 12, 2008 5:21:17 PM (GMT-0600) America/Chicago Subject: Re: [tc-dev] Code layout What does jmx utils have to do with split hashmap? Why would they be packaged together? On Feb 12, 2008, at 3:19 PM, Alex Miller wrote: > I'd vote for the balanced set #2. > > ----- Original Message ----- > From: "Taylor Gautier" <tgautier@...> > To: "Jonas Bonér" <jonas@...>, "Geert Bevin" <gbevin@... > >, "Alex Miller" <amiller@...>, "Kunal Bhasin" <kbhasin@... > >, "Juris Galang" <jgalang@...>, "Jason Voegele" <jvoegele@... > >, tc-dev@..., tc-users@... > Sent: Tuesday, February 12, 2008 4:54:56 PM (GMT-0600) America/Chicago > Subject: Code layout > > > There have been a number of utility like and pattern like > implementations going into forge/labs. I have been thinking about > how best to organize these things. Here's my thinking to date, I'm > open to suggestions or just voting for one of the options below. > > At the moment I know of: > > > > • ResourceManager - a pair of classes that level a shared > resource across a cluster (relies on JMX util) > • Pipes/Channels - refactoring of the pipe/channel idea in m/w > • Master/Worker - work load balancer > • JMX Util - JMX event util classes > • Annotations - annotations > • SplitHashMap - rough equivalent of concurrenthashmap > • TimeSeriesMap - to expire items in a map based on time entries > So, I am not sure, I can argue a few different layouts: > > 1) All in one package. On the one extreme, this makes using any TC > based util class (or pattern) really easy. Until there is too much > in one package, this what I prefer, except it tends to have version > creep that doesn't correspond to relevant features - in other words > a developer uses it only for JMX, but the version bumps because of a > fix for annotations > > 2) A Balanced set of packages. I would propose > > > • tc-util - contains pipe/channel, resourcemanager, jmxutil, > splithashmap, timeseriesmap > • annotations - annotations only > • master/woker - m/w only, but needs tc-util for both pipe/ > channel and jmx > > 3) Lots of little packages - basically everything in its own > package. This is my least favorite option. > > > > Thoughts? > > _______________________________________________ > tc-dev mailing list > tc-dev@... > http://lists.terracotta.org/mailman/listinfo/tc-dev _______________________________________________ tc-dev mailing list tc-dev@... http://lists.terracotta.org/mailman/listinfo/tc-dev _______________________________________________ tc-users mailing list tc-users@... http://lists.terracotta.org/mailman/listinfo/tc-users |
|
|
Re: Code layout
by Geert Bevin
::
Rate this Message:
I have nothing against Ivy.
I just don't think it makes much sense to micro-manage features into separate packages, it's more pain than it's worth. Nobody cares that they only use 1% of what's in a package, and nowadays the size overhead is neglactable. That just leaves one point, which is that a jar needs to be upgraded if something else changed that's not related to what you use. Imho that is far less trouble than newcomers (and even veterans) trying to figure out how everything is related, which jars depend on which others and making sure that all the versions are correct. A large part of the developer world doesn't use Ivy or Maven, they might not even be allowed to do so by their employer. On 2/13/08, Eugene Kuleshov <eu@...> wrote: > Geert Bevin wrote: > > The "All in one package" option takes my preference. > > > He he. That is because you don't dig the dependency management tools. :-) > > Anyways, I'd say that at least annotations should be in its on > separate TIM project. Everything else might be simply reusable > components that could be split between few packages based on their own > dependencies like dependency on JMX API. > > regards, > Eugene > > > _______________________________________________ > tc-users mailing list > tc-users@... > http://lists.terracotta.org/mailman/listinfo/tc-users > -- Geert Bevin Terracotta - http://www.terracotta.org Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com _______________________________________________ tc-users mailing list tc-users@... http://lists.terracotta.org/mailman/listinfo/tc-users |
| Free Forum Powered by Nabble | Forum Help |