When annotations get supported this (location of tc-config) is a non-issue.
Also typically in production - the tc-config is on the Terracotta server with Terracotta clients pulling it off the Terracotta server, whereas its checked into the source repository by developers, since it is "code". So whether the tc-config lives at some random location on the file-system or is a "resource" (that could potentially be pulled off the classpath?) - at some point one has to move this file to the server after building out your application on your application-server boxes - maybe we can automate that by allowing an env variable to be specified which dictates where the config file is and having that file automatically pushed to some suitable-Terracotta-install-sub-directory on the server or something like that ? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Taylor Gautier Sent: Tuesday, June 26, 2007 9:28 PM To: Nathaniel Harward Cc: [email protected] Subject: Re: [tc-dev] Request for feature feedback from developers I've been thinking about the deployment process of applications using Terracotta, which is slightly tangential to this discussion, however one thing I noticed is that the tc-config.xml lives outside the normal process - i.e. we require that it live on the filesystem, while a lot of work has been done in Java to abstract away from the filesystem itself, and put resources on the classpath. So is there a possibility of allowing the tc-config file to be loaded from the classpath instead of a hard file resource? This seems like a simple first step for smoothing a lot of deployments including the plugin deployments. If there is already this option, then I am just dumb. Nathaniel Harward wrote: > A large part of the next Terracotta release (2.5) will be integration > work and tools to make using Terracotta with other software easier. > This includes building a) a plugin for Geronimo and b) a plugin for > Maven 2 -- the question before us now is exactly how and what to do on > each of these. I would like to outline the high level goals and lines > of thought for each subproject and get feedback so that we build them in > a way that will be useful to people. > > > Geronimo > > > The goal here is to create a Terracotta plugin for Geronimo such > that Geronimo users can install it in the normal plugin fashion (a > few clicks from the console as I understand it) and at a minimum > immediately start using Terracotta session clustering. This should > be a completely automated process: the user should *not* have to > separately download the Terracotta distribution, and ideally not do > anything else outside of the Geronimo console/environment to get > things going -- this needs to be a very streamlined process. > > Things we need to investigate: > > 1. How do users configure Terracotta once the plugin is installed? > 2. Do we have two plugins - one each for the Terracotta client > and server with a shared core as a dependency? If not where > does the Terracotta server go? > 3. How/what do we plug in to the Geronimo console for management? > > > Maven 2 > > > The goal here is to create a Maven 2 plugin for people to use > Terracotta while building and testing their applications; it should > support the following use cases: > > 1. Application level user: user wants to run their tests with > Terracotta enabled by running 'mvn test' and specifying the > Terracotta plugin as a test dependency > 2. Integrator: framework developer wants to create a Terracotta > configuration module for their framework; need to run tests > with it (as above) as well as package/publish the module when > ready. This will require making ManagerUtil and potentially > other classes available to integrators at compile time as well > 3. Both types of users should be equipped with Terracotta > archetypes if they are starting from scratch > > Our own configuration modules should be the first victi- er... users > of our Maven 2 plugin, and they will most likely be pulled out of > the existing source tree and put on their own. If done we will also > likely pull binary versions of these published configuration modules > when making an official distribution. > > One goal of this effort is to [when possible] have the maintainers > of a framework/appserver/etc. maintain the Terracotta configuration > module for their framework/app as they develop and change it, since > they know it best and are in the best position to do so. For this > to happen the maintainence/build/test/publish process must be easy > for them to do and fit into their normal dev/release processes. > > Things we need to investigate, and in particular what I think could > use some feedback: > > 1. How is the Terracotta configuration going to be done? Do we > go with a detached tc-config.xml file, or should we make it so > locks/roots/etc. are defined in the plugin configuration in > pom.xml? Does the pom.xml configuration just point to a > detached tc-config.xml? > 2. The POM already describes dependencies like spring, libraries, > whether or not it's a web application, app. servers, etc. - > can we use this to auto-generate a tc-config.xml for 1) above? > 3. Is support for JUnit testing enough initially? TestNG? Others? > > > I realize this is very high level and a lot of details need to be sorted > out, but hopefully this gives some kind of coherent overview of where we > are trying to go. Please reply if you have feedback or ideas on the > matter so we can take them into consideration as we try to hammer this > out over the next week. > > Thanks, > Nat > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev > _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
