Hi Eric,
since you raised the topic - what is the Turbine stuff which overlaps with the ResourceManager Service and how would you suggest an unification. Otherwise my contributions are in limbo state ... :-)
Cheers,
Siegfried Goeschl
-------- Original Message -------- Subject: [fulcrum] RFC for contributing two services .... Date: Mon, 13 Dec 2004 16:10:36 +0100 From: Siegfried Goeschl <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Organization: IT20one GmbH To: Turbine Developers List <[EMAIL PROTECTED]>
Hi folks,
I want to contribute two services for now which can be found at http://84.113.204.124/download/
+) fulcrum-resourcemanager (http://84.113.204.124/download/fulcrum/resourcemanager/target/docs/)
+) fulcrum-groovy (http://84.113.204.124/download/fulcrum/groovy/target/docs/)
1) Ad Fulcrum ResourceManager Service
==================================
I need a way to decouple the Groovy service from the persistence mechanism. This should provide two basic features
1.1) location transparency since the scripts could be stored in a DB as well. Therefore the service
exposes CRUD functionality
1.2) the locator allows to search for a named resource up the directory tree. I use this pattern heavily for my work to add
customization based on a context to look up a resource.
I also have a fulcrum-dom4jxslt-service to be contributed which depends on the ResourceManager as well.
As Eric Pugh pointed out there is an overlap with Turbine and commons-configuration ... any opinions out there?!
2) Ad Fulcrum Groovy Service ==================================
Allows invoking Groovy scripts and provides access to the Avalon infrastructure.
3) Ad "urn:avalon.temp" ==================================
Yes - it is a standard Avalon value. Ceck out http://wiki.apache.org/avalon/AvalonContextSurvey and http://wiki.apache.org/avalon/AvalonStandards - I'm definitely adding urn:avalon:name.
I use "urn:avalon:temp" to dump the stuff which blows up my logfile such as the result of a XSL transformation. As a filename I user <servicename>_state.extension, e.g
DOM4JXSLTService_input.xsl and DOM4JXSLTService_result.xml. In my opinion a single temp directory for all apps is fine since I use the temp directory of Java as default.
Thanks in advance
Siegfried Goeschl
PS: Eric - you could still look if the things integrate nicely with Fulcrum ... :-)
-------- Original Message -------- Subject: RE: RFC before adding two projects to Fulcrum Date: Mon, 13 Dec 2004 14:29:23 -0000 From: Eric Pugh <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>
Sigi,
Can you forward this to the Turbine list? We need to make sure that folks on turbine-dev see all Fulcrum related posts as that IS the mailing list for now. If we feel that the traffic warrants it, then we can talk about doing fulcrum-dev list at some point. Just do [fulcrum] in the subject if we want to setup a pattern for filterning turbine versus fulcrum email.
I like the groovy one, it seems pretty straightforward. I would be interested in hearing more disucssion on ResourceManager. IN some ways it overlaps with with how we might use commons-configuration. Also Turbine has a similar type service, well, not really a service, but has the same type of functinality. It may make sense to unify the two...
Also, is urn:avalon:temp a standard avalon value? Should a temp directory be configured on a service by service level? I am wondering if having just a single temp directory could cause problems?
Looking forward to all the new stuff!
Eric
-----Original Message----- From: Siegfried Goeschl [mailto:[EMAIL PROTECTED] Sent: Monday, December 13, 2004 1:05 PM To: Eric Pugh Subject: RFC before adding two projects to Fulcrum
Hi Eric,
attached you find my two contributions - Fulcrum ResourceManager Service and Fulcrum Groovy Service. Can you have a look to make sure that I do not screw up big before importing to the CVS ... :-) ... would be quite annoying
Sigi
PS: the Fulcrum DOM4JXSLT I can contribute next week ...
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
