This works: % make-boot-jar.sh -f resource:///com/tc/object/tools/default-config.xml
The resource should be specified absolutely because the lookup is done by, and relative to, type com.tc.config.schema.setup.StandardXMLFileConfigurationCreator. ----- Original Message ----- From: "Taylor Gautier" <[EMAIL PROTECTED]> To: "Nathaniel Harward" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Tuesday, June 26, 2007 9:28 PM 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
