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
