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
